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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 14 Aug 2013 14:35:07 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Mark Brown <broonie@...nel.org>
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, 14 Aug 2013, Mark Brown wrote:

> On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
> 
> > > Yes, so you'd want callbacks when the device actually appears and
> > > disappears.
> 
> > No, no -- this is exactly the point I was trying to make.  The on-board
> > hub _won't_ appear on the USB bus until the GPIOs are set.  Therefore
> > the callback to set the GPIOs needs to be at a different place, not
> > when the device appears.
> 
> 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!

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).

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

Alan Stern

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