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? 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)? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
