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

[Segher Boessenkool]

>> Yep.  The whole reason why any property is wanted here is
>> to say what type the PHY is, as the enet controller can
>> be attached to several kinds.  And what type the PHY is
>> belongs in the PHY node, obviously.  In its "compatible"
>> property to be exact.
>
> 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.

> This is actually a property of the board.  In some cases its a fixed 
> property of the board.  In some cases it's changeable through dip 
> switches, or even through software.

In such a case you cannot describe this with a fixed
flat device tree *at all*.

> 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?

> The reason for choosing the ethernet controller in this case has to do 
> with the flow of information.
>
> 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.

> 2) The ethernet controller is the endpoint of this connection which is 
> accessible by everyone else.  IE data is not sent through PHYs by any 
> means but through the ethernet controller, and data is not received 
> from PHYs by any means but through the ethernet controller.

So?

> 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?

> The truth is, this is a somewhat intractable problem because of the 
> myriad possibilities for how board designers can hook up ethernet 
> controllers to PHYs.  One can envision scenarios where controllers can 
> hook up to multiple PHYs, each of one fixed type.

Yeah, seen that.  Quite a common scenario.

> One can envision scenarios where multiple controllers are hooked up to 
> one PHY, and each of the controllers can use different connections.

How would that work at all, except when only one controller
is active and the rest are shut down?

> If we put the information in the PHY node, we allow for the first 
> scenario, but not the second.  If we put it in the ethernet node, we 
> reverse that situation.  In either case, we'd currently have to modify 
> our dts to specify which PHY we want to use.

Which brings me back to, can't you just probe for it?


Segher