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

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Wed, Sep 08, 2010 at 10:12:45AM -0600, Grant Likely wrote:

[reflowed into 80 columns]

> ... 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

Pretty much this, yes - if you might want to turn on your supplies
when you're probed it's rather helpful if the subsystem needed to
control the regulators is available when you probe.

> 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.

That would be much nicer (and this is far from the only case where we
need to deal with it) but it's a substantial change to core kernel
infrastructure so it's being worked around like this.  Given how all the
discussions about sorting and dependencies for suspend and resume went
it might be an uphill struggle to do much more, especially while we are
able to continue to deal with things fairly easily using the current
infrastructure.

Doing dependencies could get pretty complicated, especially once you
handle optional dependencies ("is this missing because it didn't probe
yet or because it's just not there?") so it's not entirely clear to me
that it's worth the hassle.