Re: [RFC 2/4] driver core: Allow early registration of devices

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/17/2013 04:26 AM, Tomasz Figa wrote:
...
> Please correct me if I'm wrong, but to get to initcalls you need a timer. 
> However a timer driver might need interrupts (to tick) and clocks (to get 
> the frequency).
> 
> At least this is what happens on the platforms I work with. They don't 
> need any special early registration method, though. We just special case 
> those drivers, as Thierry pointed, so they don't use device based APIs.
> 
> However if we consider a more complex setup, let's say that the timer 
> driver needs to access some special registers, which are shared with other 
> drivers as well (again not a completely exotic case, as I already met this 
> when working with timer and PWM drivers for older Samsung platforms and 
> had to hack things a bit). One would suggest using regmap here, but it is 
> a device based API.

To take this even further, I'm not sure there's a particular reason why
the timer has to have an internal clock source driven from the same chip
clock input as the CPU itself. What if there's a separate clock input,
whose source chip has an enable input, which is connected to a GPIO,
which is driven by an I2C-based GPIO expander? Admittedly that's a
pretty crazy HW design, but I doubt it's much other than an accident
that it doesn't exist in practice, given the probable lack of feedback
cycle from Linux SW internals to all board designers.

It seems like the best solution here is to make the generic case fully
capable. Perhaps initcalls shouldn't depend on a timer at all, or should
be split into sets that require certain services, and those services can
appear dynamically, and when they do, the relevant initcalls that were
held off by lack of a certain feature all get triggered.