Messages in this thread | | | Date | Thu, 22 Sep 2011 14:19:29 -0700 | From | David Daney <> | Subject | Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism |
| |
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@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |