linux-kernel - Re: Non-enumerable devices on USB and other enumerable buses

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130814184643.GL2401@sirena.org.uk>
Date:	Wed, 14 Aug 2013 19:46:43 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Felipe Balbi <balbi@...com>,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:

> > What I'm proposing is that we have a way of telling buses that devices
> > exist via a mechanism other than their actually being visible on the bus
> > at the current time.  If you're doing that the driver can be running
> > prior to the hardware being there, just like it does with all the
> > non-enumerable buses.

> This may work for other buses, but it isn't feasible for USB.  Not only
> do many of the drivers need to communicate with their device during
> their probe routine, the subsystem itself needs to communicate with the
> device before many of the important data structures can be constructed.  
> Without these structures, the device can't be bound to a driver.  We 
> wouldn't even know which driver to bind it to!

The identification information for the device would of course have to be
provided as part of registering that the device was going to appear -
I'd expect to provide the same information that's read out of the
hardware during enumeration, with enumeration checking to see if it
knows about the device already.

> My impression is that much of what you want could be handled by a
> platform callback invoked when a particular bus -- i.e., one whose
> upstream controller is a particular platform device -- is registered.  
> Is that correct?  For example, in the USB case, the on-board hub's
> GPIOs could be set when the USB bus is registered (or perhaps when the
> bus's root hub is registered).

That sort of bodge is probably adequate for basic "power this on" stuff
but it's not going to scale to a general solution, especially where the
driver wants to use some of the information at runtime.  Currently
systems are doing things like bodging callbacks into controller drivers
which is basically what you're talking about here.

> > It means that there are situations where a driver wants to take the
> > hardware offline but still offer services to userspace which will
> > require the hardware to be brought on line again.  The fact that this is
> > a very generic thing is exactly why I'm raising this as a generic issue.

> This is a separate issue, more or less independent of whether the
> platform needs to carry out special actions for the device in question.  
> If you're suggesting these off-line/on-line transitions are appropriate
> places for a platform hook, then yes, that makes sense.

I think in the general case it's the same issue - grab all the resources
and enable them at probe time is the simplest implementation but it's
not the only one by a long stretch.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)