Hey,

On Tue, Jul 08, 2014 at 07:49:00PM +0200, Antoine T?nart wrote:

quoted

So, yeah, it's being used both as input and output and we also have
the arguments which affect port_map, right?  It does seem confusing.

I do see priv->port_map as being automatically set and then restricted
if needed by the port_map input here. I don't see how that's confusing.
The only modification is we restrict the port_map parameter to the set
of available ports. The port_map argument affected priv->port_map before
this patch.

It is confusing.  If you wanna pass around available ports in hpriv,
please add a separate field and replace the arguments to
save_initial_config().

quoted

Well, so does clk.  Let's say clk is more restricted and phy can be
one or more per port and thus needs to be dynamic.  If so, shouldn't
we at least have some correlation between phys and ports?  It bothers
me that now libahci is carrying random number of resources that it has
no idea how to associate with the ports it manages.  What if later we
want to involve phy driver in power managing unoccupied ports?

I see. This is a first (working) attempt to have a one node per port. I
agree that would be nice to have a correlation between ports and PHYs.
This can definitively be added when needed without changing the dt
bindings as only the internal representation changes. This would also
require to get all phys from the port nodes, which is again internal
stuff.

Don't you think we can go by steps, and have a following up series for
this when needed (like in a power managing series for unoccupied ports)?

I don't know.  It isn't exactly difficult to make it per-port, is it?
We already have ahci_port_priv and wouldn't the code actually be
simpler that way?

Thanks.

-- 
tejun