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]

Message-ID: <Pine.LNX.4.44L0.1308112146410.29546-100000@netrider.rowland.org>
Date:	Sun, 11 Aug 2013 21:53:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Mark Brown <broonie@...nel.org>
cc:	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>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	<devicetree@...nel.org>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: Non-enumerable devices on USB and other enumerable buses

On Sun, 11 Aug 2013, Mark Brown wrote:

> Looking at the enumerable buses in the kernel I don't see any which have
> real support for any kind of registration of devices prior to their
> enumeration.  Similarly currently all the DT bindings in the kernel I've
> been able to notice cover only non-enumerable buses.  This generally
> makes sense where enumerable buses are used in standard fashions since
> the binding would be at best redundant and at worst inaccurate.  However
> there are often corner cases in embedded systems where hardware has been
> hooked up outside of the normal enumeration mechanisms, for example with
> software power control or extra signals wired.
> 
> 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.

On the surface, this seems like a particularly simple case.  Why wait 
until the SoC's USB controller has started?  Why not "plug in" the hub 
via the GPIOs right from the beginning?

> Another case that's going to be problematic once it's in mainline is
> Slimbus - this is a bus used in some embedded audio subsystems which is
> enumerable in a similar manner to USB but where the devices on the bus
> are normally powered up only on demand (causing them to hotplug when
> used and unplug when idle) and have at least interrupt lines wired to
> the SoC using a normal interrupt outside the enumerable bus.

That is indeed more difficult, because it requires geniune cooperation 
between the bus and platform subsystems.

> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?

The discussion involved some sort of pattern matching based on the
device name and the bus, but nothing was ever settled.

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/