[PATCH 1/9] spi/pxa2xx: don't use subys initcall for driver init

[Russell King - ARM Linux]

On Thu, Nov 25, 2010 at 06:14:49PM -0700, Grant Likely wrote:
> On Thu, Nov 25, 2010 at 4:54 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Wed, Nov 24, 2010 at 04:39:05PM +0100, Sebastian Andrzej Siewior wrote:
> >> Mark Brown wrote:
> >>> On Wed, Nov 24, 2010 at 03:09:25PM +0100, Sebastian Andrzej Siewior wrote:
> >>>
> >>>> I've been pointed out to this commit but I don't understand _why_.
> >>>> The part I don't get is "so it can be used with cpufreq". Is it
> >>>> refered to a driver or the subsystem as it?
> >>>
> >>> We need the regulators for the CPU rails to start before the cpufreq
> >>> driver starts so cpufreq can talk to them, and since the regulators may
> >>> be SPI attached this means we also need the SPI controller to start
> >>> before cpufreq.  cpufreq starts at vanilla init time.
> >>
> >> After digging through the code I think I've found it. pxa_cpu_init()
> >> registers a cpufreq client. cpufreq calls init and pxa then
> >> regulator_get() to get the regulator and I guess this is the problem.
> >> So I would suggest to defer pxa_cpu_init() via late_initcall().
> >>
> >> The other way around will force you to hack the init code for various
> >> drivers to make it work.
> >
> > Why should the PXA code change when you haven't explained _why_ you want
> > to change the SPI driver to conform to your idea?
> 
> The idea is to get away from trying to resolve probe order issue by
> messing with the initcall level in spi and i2c bus drivers.  It's
> fragile, and it doesn't work with drivers as modules.  Instead, we're
> investigating making the dependencies explicit in the board support
> code.  However, hacking other initcalls to enable what I want to do on
> the spi bus drivers isn't a solution, it is just moving the problem.

I know that's what _you're_ doing, but that doesn't seem to be what
Sebastian is doing.  My question was targeted towards at Sebastian.