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 20:16:56 +0000
From:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
To:	Alan Stern <stern@...land.harvard.edu>,
	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" <devicetree@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: Non-enumerable devices on USB and other enumerable buses

> From: Alan Stern
> Sent: Wednesday, August 14, 2013 12:39 PM

> Now I'm getting confused.  It seems we're talking about at least three
> very different things here:
> 
>      A: Devising a mechanism for platform code to do things involving
> 	devices that are dynamically registered on discoverable buses.
> 
>      B: Telling the subsystem and driver code for a discoverable bus
> 	that a particular device is present before it has been
> 	detected.
> 
>      C: Implementing a mechanism whereby drivers can take a device
> 	off-line while still pretending to userspace that the device
> 	is still present, by bringing it back on-line as needed.
> 
> I don't see much connection between these things.  Perhaps you can
> explain in more detail.
> 
> (BTW, it's worth mentioning that C has already been done, in the form
> of runtime PM.  The difference may be that you propose to take the
> device so far off-line that it disappears from the bus.  AFAICS, this
> would be purely a private matter to be arranged between the subsystem
> and the driver; it does not need to be handled at the level of the
> device-model or PM core.)

Mark's original complaint about USB was this:

> One example that's bugging me right now is that on the Insignal Arndale
> platform there's a USB hub connected to one of the USB ports on the SoC
> (not as a PHY, it seems we also need the internal PHY running to talk to
> the device).  The hub needs to be "plugged" into the SoC after the SoC
> USB controller has started with some GPIOs so we need to tell the system
> that the hub exists and needs to be synchronised with the USB controller.

This sounds to me like the normal discovery mechanism for USB isn't getting
kicked off because no Connect Status Change is being triggered on the root
port when the hub is brought online using the GPIOs. Maybe the port has
been runtime suspended because no device was attached originally?

So maybe the only thing needed for USB is a way to tell the parent port to
frob its port control bits to try to determine if a device is now present.
(set Wake on Connect Enable? Do a Port Reset? Cycle the Port Power bit if
possible?)

-- 
Paul

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