[PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
segher at kernel.crashing.org
Tue Apr 17 09:25:45 EST 2007
>> 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
> 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.
> 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
> 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?
More information about the Linuxppc-dev