[PATCH 1/4 v2] powerpc: document max-speed and interface-type properties

[Segher Boessenkool]

>>> It's not saying what type the PHY is, though.  It's describing the 
>>> connection.  The PHY is just as flexible wrt connection type as the 
>>> ethernet controller.
>>
>> Huh, I've never seen that.  I'll take your word for it.
>
> Well, mostly this just means that the PHY has pins, and can be told 
> which pins have what meaning in the same way that the ethernet 
> controller can.

Oh I see.  But the PHY is connected in only one way, so
its node should say which way that is.

>>> Ethernet controllers need to know what the connection is so they can 
>>> establish a data connection with the PHYs
>>
>> Can't you probe for PHYs?
>
> I'm beginning to suspect you are confusing the PHY management bus with 
> the PHY data bus.

No I'm not -- not this time, anyway ;-)

>>> 1) The driver tells the PHY what interface to use
>>
>> The device tree is not structured after how Linux device
>> drivers want to use the information; instead, it describes
>> the hardware.
>
> My point was merely that the location of the information is arbitrary, 
> and so here are three reasons for arbitrarily putting it in the 
> ethernet node, rather than the PHY node.

The max speed of the controller, and the types of MII buses
it supports, belongs in the controller node (perhaps as
implicit information).

The max speed of the PHY, and the types of MII buses it
supports, belongs in the PHY node.

I don't see anything arbitrary here.

>>> 3) The UCC needs to be told the connection type, because it does not 
>>> have logic to detect it on its own.
>>
>> Just try all possible kinds, see if you can see a PHY
>> connected?
>
> To extend on the point above, this is nearly impossible.  As I said, 
> the management bus and the data bus are different.  This interface 
> property describes the pin configuration for the data bus.  It also 
> describes the "rate" at which the data is sent or received (some 
> interfaces double-pump, some use echo cancellation).  The result of a 
> misconfiguration is that you receive gibberish and you send gibberish. 
>  The PHY will happily misunderstand the ethernet controller, and 
> visa-versa.
>
> They *both* need to know how they are wired to the other one.

I was thinking you could put the PHY in loopback mode and see
what works.  This might not be too reliable of course.

> Again, no.  You would have to convince me that the interface is more 
> closely tied to the PHY than to the controller.  I believe it's an 
> equal weighting, and have provided three arguments above for why the 
> ethernet node is more appropriate.  Feel free to do so for the PHY.  
> But you need four or more, or I win.  ;)

It seems you misunderstand me.  I say the controller information
belongs in the controller node, and the PHY information belongs
in the PHY node.  If there are multiple modes possible for a
given controller+PHY combination, that information should be put
in the PHY node, since a controller can have multiple PHYs but
not the other way around (for a given PHY->controller assignment,
which is a configuration option for the firmware to decide on,
so any given device tree will describe only one such assignment).


Segher