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

[Thierry Reding <thierry.reding@gmail.com>]

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

On Mon, Aug 19, 2013 at 01:49:18PM -0600, Stephen Warren wrote:
> 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.

But that's pretty much a special case of deferred probing, isn't it?

If we make it any more specific than deferred probing we'll end up with
a set of statically defined features that drivers need to check instead
of directly requesting the resources they need. Maintaining that list
will probably be manageable, but how will that handle cases where for
instance two drivers announce the same services and one driver depends
on that service? It'll be difficult to find out if the provider of the
service is the right one.

Thierry

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