On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 27 Nov 2012, Ming Lei wrote: > >> IMO, all matches mean the devices are inside the ehci-omap bus, so >> the direct/simple way is to enable/disable the regulators in the probe() and >> remove() of ehci-omap controller driver. > > When this discussion started, Felipe argued against such an approach. > He pointed out that the same chip could be used in other platforms, and > then the code added to ehci-omap.c would have to be duplicated in > several other places. >From Andy's implementation, the 'general' code is to enable/disable the regulators(patch 3/5), I am wondering if it is general enough, so the 'duplicated' code are just several lines of regulator_enable/regulator_disable, which should be implemented in many platform drivers. Also from my intuition, power domain should be involved in the problem, because these hard-wired and self-powered USB devices should have its own power domains, and the ehci-omap driver may enable/disable these power domains before adding the bus. > > 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. The LAN95xx's regulator is still platform dependent(even for same LAN95xx USB devices on different platforms(omap, tegra, ..)) , so I am wondering why we don't enable it directly in probe() of ehci-omap.0 platform device? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
