linux-kernel - Re: [RFC 2/4] driver core: Allow early registration of devices

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, 19 Aug 2013 22:10:43 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/4] driver core: Allow early registration of devices

On Mon, Aug 19, 2013 at 01:43:59PM -0600, Stephen Warren wrote:
> On 08/17/2013 05:17 AM, Thierry Reding wrote:
> ...
> > Well, the most obvious cases where early initialization is needed
> > are interrupt controllers and clocks.
> 
> ... and IOMMUs, which apparently need to initialize before any devices
> whose transactions are routed through the IOMMU, in order to set
> themselves up as the IOMMU for the relevant devices.
> 
> It's possible that the CPU-visible bus structure isn't a strict
> inverse/reverse of the device-visible bus-structure. A device may have
> CPU-visible registers on one bus segment, but inject master
> transactions onto an unrelated bus segment. So it may not be as simple
> as making a bus driver for the bus segment affected by the IOMMU, and
> having that driver trigger instantiation of all its children.

Well, perhaps that can be handled via deferred probing? The only thing
preventing that right now is that drivers aren't actively aware of the
IOMMUs existence. If we can make it a requirement that each driver
needing the services of an IOMMU actively requests that service, then
deferred probing should be able to deal with it.

That doesn't necessarily mean that drivers need to be doing it manually.
It strikes me as the kind of thing that could easily be done by the
core. In fact I've been thinking of doing something similar to resolve
devicetree IRQ references at probe time, rather than at device creation
time to remove the need for interrupt chips to register early.

Thierry

Content of type "application/pgp-signature" skipped