linux-kernel - Re: [RFC PATCH v3] 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: <4E7CB9FF.5020401@gmail.com>
Date:	Fri, 23 Sep 2011 09:55:27 -0700
From:	David Daney <ddaney.cavm@...il.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 03:47 PM, Alan Cox wrote:
>> 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?
>
> I think there are very very few drivers that have this property and don't
> already implicitly cause a probe by creating a new bus or device.
>

These are precisely the drivers of concern.  However it is not 
individual drivers, but whole classes of drivers.  In my case we are 
talking about GPIO drivers.

If there is a dependency on GPIO devices, we don't know which 
device/driver will be providing the GPIO services, so at a minimum *all* 
GPIO drivers would have to add the explicit kick.

> Those drivers that set something up for another device really should
> know what is going on because they are making a guarantee that they are
> ready for the other device to call into them or whatever is going on at
> some point, either explicitly in the kick or implicitly in returning from
> their probe method.

Really the driver framework is there to do all this already.  Once the 
probe method is called, the device is usually presented as 'ready' in 
some sense.

The problem this patch solves is to make it work when there are ad hoc 
relationships between the devices that cannot be represented in a tree 
like structure presented by the bus/driver topology of the driver framework.

If there are no deferred probes necessary, the only overhead is a single 
check to see if work needs to be done.  Since in this case, nothing 
needs to be done...  Nothing is done.

>
> I know which I think is clearer and easier for a 3rd party to see and not
> miss completely when updating code.

?? I don't understand that statement.

A handful of lines of code in the driver core vs. having to wonder, and 
then get it right, for each and every driver if there could be a 
dependency outside of the bus framework.

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