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

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]

Hi,

On Thu, Nov 22, 2012 at 12:36:43PM -0500, Alan Stern wrote:
> On Thu, 22 Nov 2012, Felipe Balbi wrote:
> 
> > > 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?

a quirk on the hub's product ID/vendor ID pair ? All you need is to put
a requirement on the format of the regulator name. Not the best
solution, I agree, but that's all we can do.

> Has this sort of thing come up in the past with other types of
> devices?

I'm not sure.

> 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

It doesn't matter, IMO, when do we know the regulator exists. As long as
the regulator is registered early enough (or we rely on -EPROBE_DEFER to
synchronize things) and we have a known naming format (perhaps something
like usb_hub_port%d_supply, or something), we should be able to request
the regulator and toggle it at any time.

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

What do you mean ? I'd expect all ports to have a regulator. Either one
for each, or sharing the same supply. It all boils down to how the hub
is integrated.

I'm guessing the the problem here is that this hub can't control the
external Hub when its port gets a PORT_POWER feature cleared or set.
That's what I'm assuming.

> Once we can solve this part of the problem, I think the rest of it
> will fall into place.

I agree with you.

> > 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)?

Then the camera's driver or the fingerprint reader's driver should
manage the regulator, no ? Or do you want to let teach the regulator to
struct usb_device and manage it at usbcore level ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]