Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

[David Daney]

On 09/22/2011 01:29 PM, Alan Cox wrote:
> Definitely what is needed for some of the x86 SoC stuff and would let us
> rip out some of the special case magic for the SCU discovery.
>
> First thing that strikes me is driver_bound kicks the processing queue
> again. That seems odd - surely this isn't needed because any driver that
> does initialise this time and may allow something else to get going will
> queue the kick itself. Thus this seems to just add overhead.

Do you mean explicitly kick the queue?

How would a given driver know that something else is waiting for it?  Or 
would we add the explicit kick to each and every driver in the tree?


> It all looks a bit O(NÂ) if we don't expect the drivers that might
> trigger something else binding to just say 'hey I'm one of the
> troublemakers'

I think it probably is O(NÂ), but N is small...



> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/