Hi, On Thu, Nov 22, 2012 at 01:32:25PM -0500, Alan Stern wrote: > On Thu, 22 Nov 2012, Felipe Balbi wrote: > > > Hi, > > Hello. > > > > 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. > > That sounds a little too simple. For example, what if there are two > chips of the same type on the system, attached to two different > regulators and two different host controllers? hehe, good point :-) > > > 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? > > > > 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 wasn't clear enough. I wasn't talking about downstream ports on that > hub, but about where its upstream port is connected. This hub is > permanently wired to one of the root ports on the EHCI controller. In > this case, we know which port it is attached to. In other systems we > may not know, or it may be different on different revisions of the same > board. ok, makes sense now. You're right. > > > 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 ? > > The latter, more or less. For example, maybe we can tell usbcore > somehow that regulator X is in control of a device attached to host > controller Y (not sure how we would express X and Y though). Then when > usb_add_hcd() sees that the host controller being added is Y, it will > know to turn on regulator X. Similarly for usb_remove_hcd(). that'd look very nice indeed. Perhaps we could even take care of such details for the roothub, even. Maybe some systems might show up where roothub need external regulators provided by e.g. PMIC ?!? -- balbi
Attachment:
signature.asc
Description: Digital signature
