Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Ming Lei <tom.leiming@gmail.com>]

On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern <stern@rowland.harvard.edu> 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