On Tue, Nov 27, 2012 at 10:32 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: >> >> We should have a more generic solution in a more central location, like >> the device core. >> >> For example, each struct platform_device could have a list of resources >> to be enabled when the device is bound to a driver and disabled when >> the device is unbound. Such a list could include regulators, clocks, >> and whatever else people can invent. >> >> In this case, when it is created the ehci-omap.0 platform device could >> get an entry pointing to the LAN95xx's regulator. Then the regulator >> would automatically be turned on when the platform device is bound to >> the ehci-omap driver. >> >> How does this sound? > > That sounds much better, and it might come in handy for other types of > devices than platform devices, so feel free to put this on the core > 'struct device' instead if needed. > Isn't enabling/disabling of clocks and regulators what dev.probe()/remove() of any driver already does? If we mean only board specific setup/teardown, still it would mean having the device core to do an extra 'probe' call when the current probe() is already meant to do whatever it takes to bring the device up. To my untrained eyes, it seem like messing with the probe()/remove()'s semantics. IMHO, if we really must implement something like that, may be we should employ some 'broadcast mechanism' so that anything anywhere in kernel knows which new device has been probed()/removed() successfully. I haven't thought exactly how because I am not sure even that would be the right way to approach PandaBoard's problem. Looking at "Figure 15 – Panda USBB1 Interface Block Diagram" of http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf gives me visions ... 1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So we should have a platform device for USB3320C, the probe() of which should simply a) Enable REFCLK (FREF_CLK3_OUT) b) Reset itself by cycling RESETB (GPIO_62) c) Create one "ehci-omap" platform device (or in appropriate order if the above isn't) That way insmod/rmmod'ing the USB3320C driver would power-up/down the whole subsystem. 2) Just like the user has to manually power-on/off any externally powered hub connected to a PC, maybe we should implement a user controlled 'soft' switch (reacting to UDEV events from ehci-omap?) to emulate LAN9514 power-on/off. I do realize it would be cool to have it automatically toggle in kernel when we (de)power the hub but isn't that outside of scope of Linux USB implementation? The above solution isn't most optimal for Panda but it seems a design more consistent with what we already have. Or so do I think. Cheers. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
