On 05/14/2014 08:51 PM, Arnd Bergmann wrote:

On Wednesday 14 May 2014 20:42:16 Sebastian Hesselbarth wrote:

quoted

quoted

quoted

For the driver, Antoine then would have to squeeze all PHY register
mangling in phy-berlin2.c and see how to make ahci-platform aware of
individual port nodes (I haven't looked up if it already exists, sorry)
and announce only enabled port child nodes, right?

I've been thinking some more about this aspect. I don't actually have
a strong opinion on whether it's better to use the generic ahci-platform
driver, or to keep the multi-phy support as a special variant for
berlin. If we do the latter, it would however be good to define the
binding in a way that lets us later merge things into the generic phy
driver in case we get more of the same.

Hmm, IMHO multi-phy support is orthogonal to ahci-platform, isn't it?
ahci-platform needs to know about the phy property and calls some
helper that deals with the phy-specifier?

About a generic _phy_ driver, I am not so sure if berlin is the best
template right now 

So, my call would be:
- make ahci-platform aware of port sub-nodes and phy properties
- have a berlin specific PHY driver

I'm not sure if we need sub-nodes per port, it should be enough
to have an array of phys, plus a way to match them up with the
ports.

Actually, I'd love to see sub-nodes per port as it will allow to
disabled unused ports on a per-board basis.

I have this in mind for a long time for Kirkwood's SATA node already:
Consider a board where you have the one available SATA plug connected
to port 1. How would that work out with status = "disabled"/"okay" that
doesn't allow array of strings obviously?

Sebastian