[PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy

[Heikki Krogerus]

On Wed, Jan 15, 2014 at 07:41:55PM +0530, Kishon Vijay Abraham I wrote:
> The point I'm trying to make is that we won't 'always' know the device names in
> advance.

In which cases do we not know the device names, and please note, cases
where we would need to use the lookup? The normal cases we would use
it are..

1) A driver creating a child device, like dwc3 when it creates the
xhci. There the parent just delivers the phys it has to the child, so
both the device name and the phys are known.

2) Platform code. Hopefully we can get rid of the platform code one
day, but in any case, when we use it, we always know at least how many
users a phy has, and if there is only a singe user, we can rely con_id
to do the matching. Though I still don't really see much risk in using
the controller device name also there. The lookup table should in any
case be made in the place where the phy devices are created, so the
phy name is definitely always known.

3) Phys part of something like mfd. This is in practice the same as
the platform code case. For example, with twl we always know there is
only one user for the phy, which is musb. So we can just use musb's
con_id if it's to scary to use "musb-hdrc.0".

In any other case, you get the phy from DT, and there is no need to
use the lookup when linking the phys and the users.

> Btw how are you planning to differentiate between multiple controllers of the
> same type with con_id?

You don't rely on the con_id alone in those cases. You then use the
device name. The con_id is just one parameter you can use to do the
matching.

> Maybe I'm missing the actual intention of this patch. Do you face problem if
> the PHY's have to know about it's consumers in ACPI?

<snip>

> >> I would rather leave the way it is modelled now.
> > 
> > Do you mean, leave it in the platform code? Why? We would reduce the
> > platform code by moving it to the mfd driver. Or did I misunderstood
> > something?
> 
> In this case, the lookup table will be used only for non-dt boot so don't see
> much use in moving to mfd driver.
> I meant if the new method is not solving any problem then I would prefer the
> way it is modelled now where the PHY's know about it's consumers.

OK, so that's what you meant. Things like that init_data promotes use
of platform data in the drivers, something that we really should get
rid of. Is that not a problem to you?

The phy drivers simply should not need to care about the consumers.
They should not need to care about anything DT, ACPI, platform
specific if it's possible, and here there is nothing preventing it.
Let me clarify..

The plan is that ultimately the drivers (meaning all the drivers, not
just phy) don't need to care about things like DT properties, ACPI
properties or anything DT, ACPI, platform specific. We will have
generic driver properties and capabilities and the upper layers will
take care of delivering the correct values from the source at hand.
The drivers can be made truly platform agnostic.

That is the goal, and we should make everything new by keeping that in
mind. Many existing frameworks are being converted to that direction,
like the gpio framework and DMA Engine API. The way you force the phy
drivers the deliver the consumers is taking a step backwards.

> Btw where does device gets created in ACPI boot?

drivers/acpi/acpi_platform.c

Thanks,

-- 
heikki