On Wed, 28 Nov 2012, Roger Quadros wrote:
> > board file:
> >
> > static struct regulator myreg = {
> > .name = "mydevice-regulator",
> > };
> >
> > static struct device_asset mydevice_assets[] = {
> > {
> > .name = "mydevice-regulator",
> > .handler = regulator_default_asset_handler,
> > },
> > { }
> > };
> >
> > static struct platform_device mydevice = {
> > ...
> > .dev = {
> > .assets = mydevice_assets,
> > },
> > ...
> > };
> >
>
> From Pandaboard's point of view, is mydevice supposed to be referring to
> ehci-omap, LAN95xx or something else?
ehci-omap.0.
> Strictly speaking, the regulator doesn't belongs neither to ehci-omap
> nor LAN95xx. It belongs to a power domain on the board. And user should
> have control to switch it OFF when required without hampering operation
> of ehci-omap, so that the other USB ports are still usable.
That is the one disadvantage of the approach we are discussing.
But what API would you use to give the user this control? Neither the
GPIO nor the regulator has a struct device, so you can't use sysfs
directly. And even if you could, it would probably be a bad idea
because the user might turn off power to the LAN95xx while the chip was
being used.
The natural answer is to associate the regulator with the USB port that
the LAN95xx is connected to, so that the new port-power mechanism could
provide the control you want. Then how should that association be set
up?
Lei Ming provided a partial answer, but his suggestion is tied to USB.
It would be better to have a more general approach. So far nobody has
come up with a suggestion that everybody approves of.
Alan Stern
--
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
