Re: [PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

[Grant Likely <grant.likely@secretlab.ca>]

On Wed, Sep 08, 2010 at 06:37:59PM +0900, Jassi Brar wrote:
> On Wed, Sep 8, 2010 at 6:12 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
> >> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
> >> <broonie@opensource.wolfsonmicro.com> wrote:
> >> > Allow the use of the S3C64xx SPI controller with things like PMICs by
> >> > moving the init up to subsys_initcall().
> >
> >> Couldn't any user ever need to load it as a module?
> >> If no, we might as well drop the s3c64xx_spi_exit and s3c64xx_spi_remove
> >
> > This doesn't prevent building as a module - when built as a module
> > subsys_initcall() is identical to module_init(), the change will only
> > affect the order in which things are done when the code is built into
> > the kernel otherwise it's a noop.
> I didn't know that, thanks for the info.
> 
> Acked-by: Jassi Brar <jassi.brar@samsung.com>

Applied, thanks.

... but it seems to me that there is a systemic problem in the way the driver model is being used if SPI (and I2C) bus drivers need to be 'special' in this regard.  What are the ordering requirements on things like PMICs?  (My uneducated assumption is that other devices depend on them being enabled before being probed.)  Would it be better to have a mechanism to defer probing on certain devices until other devices are probed?  Then the relationships could be made explicit instead of the rather coarse-grained (and potentially fragile) approach of changing the init order.

g.