[PATCH v2 4/8] initcall: add of_populate_initcall

[Marco Felsch]

On 20-10-20 18:50, Ahmad Fatoum wrote:
> Hi,
> 
> On 10/20/20 6:18 PM, Marco Felsch wrote:
> > Hi Ahmad,
> > 
> > On 20-10-02 07:53, Ahmad Fatoum wrote:
> >>
> >>
> >> On 9/30/20 10:47 AM, Marco Felsch wrote:
> > 
> > ...
> > 
> >>> @@ -61,9 +64,10 @@ typedef void (*exitcall_t)(void);
> >>>  #define fs_initcall(fn)			__define_initcall("9",fn,9)
> >>>  #define device_initcall(fn)		__define_initcall("10",fn,10)
> >>>  #define crypto_initcall(fn)		__define_initcall("11",fn,11)
> >>> -#define late_initcall(fn)		__define_initcall("12",fn,12)
> >>> -#define environment_initcall(fn)	__define_initcall("13",fn,13)
> >>> -#define postenvironment_initcall(fn)	__define_initcall("14",fn,14)
> >>> +#define of_populate_initcall(fn)	__define_initcall("12",fn,15)
> >>
> >> s/15/12/ ? (Likewise below)
> > 
> > I would like to keep it before late_initcall() due to the impact of that
> > initcall and following environment_initcall(). At least the
> > environment_initcall() assumes that devices are available to setup the
> > /env correctly. Therefore I added it before late_initcall(). I can give
> > it a try to move it behind the late_inicall if you want.
> 
> Case in point! s/15/12/ doesn't change the initcall order, it only ensures
> that you don't expand to __initcall_##fn##15 __section(.initcall.12) which
> is confusing. Apparently it confused you to think I mean changing the
> actual init level too :-)

Arg.. damn now I see. Of course I will align it. Didn't saw the 15 on
the end.. Thanks :)

Regards,
  Marco