[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E7BA661.7070903@cavium.com>
Date: Thu, 22 Sep 2011 14:19:29 -0700
From: David Daney <david.daney@...ium.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Grant Likely <grant.likely@...retlab.ca>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Greg Kroah-Hartman <greg@...ah.com>,
Dilan Lee <dilee@...dia.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Manjunath GKondaiah <manjunath.gkondaiah@...aro.org>,
Arnd Bergmann <arnd@...db.de>
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@...r.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists