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]

Date:	Mon, 4 Jul 2011 10:56:49 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Kay Sievers <kay.sievers@...y.org>,
	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 Mon, Jul 04, 2011 at 10:41:26AM -0700, Greg KH wrote:

> And why would a driver not be able to get all of the proper resources?

If the resources are provided by another driver (for example, a clock,
GPIO or regulator) then the driver doing the providing needs to have
initialized before the resource can be used.  Currently we have no way
of ensuring that this happens.

> Why can't a bus, at a later time, just try to reprobe everything when it
> determines that it is a "later" time now, without having to do this
> added change to the core?

The buses can't do anything to help as they have no visibility of this
and the chances are that devices on several different buses are
involved.

> Why would drivers in modules be an issue?  If a driver depends on
> another driver, making it a module dependancy would solve the problem,
> right?

The general problem here is that the drivers depend on each other in
system-specific fashions that have nothing to do with the control
heirachy the device model uses - for example, a device may depend on
having a clock provided but the specific clock used could come from
essentially any device in a given system with the driver accessing that
clock via the clock API which matches devices up with their providers.
The API indirection means we can share code between systems but means
that the kernel infrastructure has no visibility of the relationships.
--
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/