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]

Date:	Thu, 15 Aug 2013 13:55:18 -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 Thu, 15 Aug 2013, Mark Brown wrote:

> On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
> > On Thu, 15 Aug 2013, Mark Brown wrote:
> 
> > So why not bring the device to full power as soon as possible during
> > boot, and have it registered on the bus in the usual way?  Once that's
> > done, the ordinary runtime PM mechanism will allow the device to go
> > back off-line.
> 
> That could be done, and is likely to happen anyway as a result of device
> initialisation.  I'm not sure it buys much to force it to happen
> immediately, though.

Not necessarily immediately, then.  Let's say at the time when you
would have wanted to tell the bus about the device's existence, even
though it hadn't yet been detected.

> There's a big difference between random glue outside the drivers and
> something the drivers know about themselves, it's important to be clear
> on this.  Bodges for this often involve writing a bit of board code that
> the drivers don't know anything about.

Of course.  Glue outside of drivers is very significant, whether that 
glue takes the form of code or data.

> > I imagine that teaching a subsystem to know about a device before it 
> > has been detected would require significant changes.  My suggestion -- 
> > powering up the device, detecting it, and then powering it back down -- 
> > fits in very cleanly with existing designs and would require 
> > comparatively little work.  Case B then becomes unnecessary; all the 
> > important stuff will be handled under Case C.
> 
> To be honest I don't see how that helps much if you're going to handle
> the case where platform data is required to enumerate the device.  You
> need to know about the device prior to enumeration in order to get the
> platform data to the driver when it does enumerate and you can't
> enumerate it until you do that anyway.

You're a little imprecise here.  Which driver do you mean?  The driver
that will ultimately bind to the device, or the driver that will
discover and enumerate it (which generally is bound to the device's
upstream parent)?  I'll assume the latter.

Under what circumstances is platform data required to enumerate a
device on a discoverable bus?  We're assuming the platform has already
taken care of everything required to make the device appear on the bus
in the usual manner (such as bringing it to full power).  Can you give
an example where something more is needed?

(Were you thinking of the case where the device's IRQ signal doesn't go
over the bus but uses a different platform mechanism?  I don't quite 
see how this can work.  What about devices on the bus that aren't known 
to the platform beforehand?  How do they send their IRQ signals?)

>  A bus could insist on this if it
> needed the information from enumeration for some reason but really it
> seems like an implementation detail.

It isn't an implementation detail.  The "power-up for initial
detection" scheme is a general solution to the problem of setting up a
complicated communication path between the bus and the platform.  
(I.e., it gives a simple way to avoid the need for this communication,
that can be used on any discoverable bus.)  It also is a general 
solution for avoiding the problem of registering a device on a bus 
before that device has been discovered and enumerated.

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/