On 11/23/12 01:36, the mail apparently from Alan Stern included:
On Thu, 22 Nov 2012, Felipe Balbi wrote:
Hi -
If you mean change the regulator managing code from living in
omap-hsusb to ehci-hcd, it sounds like a good idea.
I mean that drivers/usb/core/hub.c should manage it, since that's what
actually manages the HUB entity.
This is an interesting problem. How should we handle devices which
live on a discoverable bus but whose power is controlled by an
undiscoverable platform-specific regulator?
Has this sort of thing come up in the past with other types of devices?
A big part of the problem is associating the hub, which is created
dynamically by the USB core code, with the regulator, which is known
from platform data at boot time. The suggestion that the regulator
should really be associated with a port on the hub's parent is
reasonable at first glance. But what if we don't know which port that
is?
Once we can solve this part of the problem, I think the rest of it will
fall into place.
as long as Alan is ok and it comes in the same series, I'd be really,
really glad to see such a patch and would happily review it.
If we can figure out a good way to set up the necessary association, I
won't mind adding the appropriate calls to the USB core. But is the
hub driver the right place? What if a similar power arrangement is
used for a different kind of USB-connected chip (for example, a webcam
or a fingerprint reader)?
About 18 months ago I sent out an RFC for "platform_data for
asynchronously probed devices", aimed at exactly this problem. It got
flamed to death.
The core idea there was matching "device paths" like
"usb1/1-1/1-1.1/1-1.1:1.0" to bind platform data to an
asynchronously-probed device, where the device is on hardwired connection.
I provided an implementation that worked on both SDIO and usb buses on
Panda, for the WLAN module and smsc95xx chip respectively. We have used
this implementation to solve lack of hardware or assigned MAC addresses
for wlan0 and eth0 on Panda in Linaro tilt kernels ever since.
Most of the arguments against it were of the form, "do MAC address
setting in userspace" which I felt did not understand the general use
case outside of setting MAC addresses; such as we're talking about now
with binding regulators for example. Some of the objectors did not seem
to know what "platform_data" was either, others killed it because
platform_data != device tree.
There was one genuine objection that I did not solve, "what about if
people modprobe usb buses in different order", like ehci, xhci etc. So
the "device path" would need to be qualified by the name of the driver
targeted as well as the bus index of that driver we targeted, but that's
easy enough.
Anyway as a generic thing I think its ship has sailed (on a river of
flames), but since you bring up attaching kernel objects to
asynchronously probed devices: there's one way to do it for hardwired
platform devices.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
