Re: [PATCH 1/4] driver core: introduce helper macro initcall_driver()

Re: [PATCH 1/4] driver core: introduce helper macro initcall_driver()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

On Mon, Sep 30, 2013 at 01:13:52PM +0800, Hanjun Guo wrote:
> For some devices especially on platform/I2C/SPI bus, they want to
> be initialized earlier than other devices, so the driver use initcall
> such as subsys_initcall to make this device initialize earlier.

We're trying to move away from needing to do this and to using deferred
probing to resolve init ordering issues.  Should we not be able to
convert the drivers to module_X_driver()?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] driver core: introduce helper macro initcall_driver()

[Hanjun Guo]

On 2013年09月30日 17:16, Mark Brown wrote:
> On Mon, Sep 30, 2013 at 01:13:52PM +0800, Hanjun Guo wrote:
>> For some devices especially on platform/I2C/SPI bus, they want to
>> be initialized earlier than other devices, so the driver use initcall
>> such as subsys_initcall to make this device initialize earlier.
> We're trying to move away from needing to do this and to using deferred
> probing to resolve init ordering issues.  Should we not be able to
> convert the drivers to module_X_driver()?
Hi Mark,

Thanks for your comments.

That would be great to move away *_initcall in module driver, and
this patch set is not necessary if we can use deferred probe to solve
all the init order issues.

Thanks
Hanjun

Re: [PATCH 1/4] driver core: introduce helper macro initcall_driver()

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Mon, Sep 30, 2013 at 01:13:52PM +0800, Hanjun Guo wrote:
> For some devices especially on platform/I2C/SPI bus, they want to
> be initialized earlier than other devices, so the driver use initcall
> such as subsys_initcall to make this device initialize earlier.

And this is something we want to get rid of in favor of deferred
probing.

> 
> But for those drivers, lots of them just do nothing special in
> xxx_initcall/exit, so introduce a helper macro initcall_driver() to
> eliminate lots of boilerplate just like module_driver() did.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

So, NACK because using some *_initcall in drivers should not be
encouraged.

Thanks,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] driver core: introduce helper macro initcall_driver()

[Hanjun Guo]

On 2013年09月30日 18:15, Wolfram Sang wrote:
> On Mon, Sep 30, 2013 at 01:13:52PM +0800, Hanjun Guo wrote:
>> For some devices especially on platform/I2C/SPI bus, they want to
>> be initialized earlier than other devices, so the driver use initcall
>> such as subsys_initcall to make this device initialize earlier.
> And this is something we want to get rid of in favor of deferred
> probing.
>
>> But for those drivers, lots of them just do nothing special in
>> xxx_initcall/exit, so introduce a helper macro initcall_driver() to
>> eliminate lots of boilerplate just like module_driver() did.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> So, NACK because using some *_initcall in drivers should not be
> encouraged.

Ok, got it. I agree with you, *_initcall in module driver is really
confusing people :)

Thanks
Hanjun
>
> Thanks,
>
>     Wolfram
>