linux-kernel - Re: [PATCH] drivercore: Add driver probe deferral mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACxGe6v_HVWcci2cPDyNALWST0E3_iXWZzrhi49e_cUX1VCt+Q@mail.gmail.com>
Date:	Tue, 5 Jul 2011 11:17:46 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg KH <gregkh@...e.de>
Cc:	Kay Sievers <kay.sievers@...y.org>, Arnd Bergmann <arnd@...db.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism

On Tue, Jul 5, 2011 at 10:36 AM, Greg KH <gregkh@...e.de> wrote:
> On Tue, Jul 05, 2011 at 10:28:37AM -0600, Grant Likely wrote:
>> On Tue, Jul 5, 2011 at 10:11 AM, Kay Sievers <kay.sievers@...y.org> wrote:
>> > On Tue, Jul 5, 2011 at 17:50, Greg KH <gregkh@...e.de> wrote:
>> >
>> >> I wonder if doing this all from a workqueue in the first place is going
>> >> to cause problems as probe isn't normally done this way at all.
>> >
>> > Yeah, I would expect unforeseen problems with the async thread too.
>> > It's probably all solvable, but it sounds troublesome to find out if
>> > things go wrong.
>> >
>> > We have sync hooks (BUS_NOTIFY_*) where any kind of code can subscribe
>> > to when devices get added or get bound to a driver. Can't the code
>> > that relies on later hookups to already existing devices/bindings not
>> > just plug into that?
>>
>> I tried that.  It resulted in a lot of complexity that each driver
>> needs to implement correctly which is why I started looking for a
>> different way to go about it.
>
> No, the bus that wants this just has to do it, not the drivers
> themselves, right?

It's not about the bus_type, and there is nothing that the bus can do
to solve this problem because it the dependencies are completely
orthogonal to the bus.  ie. what does an i2c bus know about the audio
path to a codec?  The problem must be solved at the driver scope.

g.
--
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/