Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html