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

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

[Kim Phillips]

Since ucc_geth is being migrated to use the phylib, the existing
(undocumented) 'interface' property is being deprecated in favour
of unconjoined variations 'max-speed' and 'interface-type'.

interface-type is now maintained one-to-one with definitions
in include/linux/phy.h.  If not specified, "mii" is assumed.

max-speed is available for users to override the interface-derived
speed, e.g. rgmii at 100Mbit/s.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
moved to recommended section (from required), removed sgmii, added rgmii-id.

please consider for 2.6.22

 Documentation/powerpc/booting-without-of.txt |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 88cdb59..cb8c6fb 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1562,6 +1562,10 @@ platforms are moved over to use the flattened-device-tree model.
      network device.  This is used by the bootwrapper to interpret
      MAC addresses passed by the firmware when no information other
      than indices is available to associate an address with a device.
+   - interface-type : a string naming the controller/PHY interface type,
+     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi", or "rtbi".
+   - max-speed : The maximum speed supported by the controller (in Mbit/s)
+     this is used if the user wants to override the interface-derived speed.
 
    Example:
 	ucc@2000 {
@@ -1573,6 +1577,7 @@ platforms are moved over to use the flattened-device-tree model.
 		interrupts = <a0 0>;
 		interrupt-parent = <700>;
 		mac-address = [ 00 04 9f 00 23 23 ];
+		interface-type = "rgmii";
 		rx-clock = "none";
 		tx-clock = "clk9";
 		phy-handle = <212000>;
-- 
1.5.0.1

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

[Kumar Gala]

On Apr 13, 2007, at 1:25 AM, Kim Phillips wrote:

> Since ucc_geth is being migrated to use the phylib, the existing
> (undocumented) 'interface' property is being deprecated in favour
> of unconjoined variations 'max-speed' and 'interface-type'.
>
> interface-type is now maintained one-to-one with definitions
> in include/linux/phy.h.  If not specified, "mii" is assumed.
>
> max-speed is available for users to override the interface-derived
> speed, e.g. rgmii at 100Mbit/s.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> moved to recommended section (from required), removed sgmii, added  
> rgmii-id.

any reason to remove sgmii?  What is rgmii-id?

- k

>
> please consider for 2.6.22
>
>  Documentation/powerpc/booting-without-of.txt |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/ 
> Documentation/powerpc/booting-without-of.txt
> index 88cdb59..cb8c6fb 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1562,6 +1562,10 @@ platforms are moved over to use the  
> flattened-device-tree model.
>       network device.  This is used by the bootwrapper to interpret
>       MAC addresses passed by the firmware when no information other
>       than indices is available to associate an address with a device.
> +   - interface-type : a string naming the controller/PHY interface  
> type,
> +     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id",  
> "tbi", or "rtbi".
> +   - max-speed : The maximum speed supported by the controller (in  
> Mbit/s)
> +     this is used if the user wants to override the interface- 
> derived speed.
>
>     Example:
>  	ucc@2000 {
> @@ -1573,6 +1577,7 @@ platforms are moved over to use the flattened- 
> device-tree model.
>  		interrupts = <a0 0>;
>  		interrupt-parent = <700>;
>  		mac-address = [ 00 04 9f 00 23 23 ];
> +		interface-type = "rgmii";
>  		rx-clock = "none";
>  		tx-clock = "clk9";
>  		phy-handle = <212000>;
> -- 
> 1.5.0.1

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

[Kim Phillips]

On Fri, 13 Apr 2007 12:00:32 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Apr 13, 2007, at 1:25 AM, Kim Phillips wrote:
> > > ---
> > moved to recommended section (from required), removed sgmii, added  
> > rgmii-id.
> 
> any reason to remove sgmii?  What is rgmii-id?
> 
UCC doesn't support sgmii.

rgmii-id == RGMII with Internal Delay, see RGMII spec, or http://www.spinics.net/lists/netdev/msg28876.html

Kim

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

[Kumar Gala]

On Apr 13, 2007, at 12:36 PM, Kim Phillips wrote:

> On Fri, 13 Apr 2007 12:00:32 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>
>> On Apr 13, 2007, at 1:25 AM, Kim Phillips wrote:
>>>> ---
>>> moved to recommended section (from required), removed sgmii, added
>>> rgmii-id.
>>
>> any reason to remove sgmii?  What is rgmii-id?
>>
> UCC doesn't support sgmii.

ahh.

> rgmii-id == RGMII with Internal Delay, see RGMII spec, or http:// 
> www.spinics.net/lists/netdev/msg28876.html

can we call this something like rgmii-internal-delay or something a  
bit more descriptive than -id (which makes one think identifier).

- k

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

[Kim Phillips]

On Fri, 13 Apr 2007 12:42:31 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> can we call this something like rgmii-internal-delay or something a  
> bit more descriptive than -id (which makes one think identifier).

it's RGMII specification nomenclature; p. 5 of the rgmii spec specifically states "Devices which implement internal delay shall be referred to as RGMII-ID."

Kim

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

[Kumar Gala]

On Apr 13, 2007, at 12:52 PM, Kim Phillips wrote:

> On Fri, 13 Apr 2007 12:42:31 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>
>> can we call this something like rgmii-internal-delay or something a
>> bit more descriptive than -id (which makes one think identifier).
>
> it's RGMII specification nomenclature; p. 5 of the rgmii spec  
> specifically states "Devices which implement internal delay shall  
> be referred to as RGMII-ID."

ok.

- k

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

[Segher Boessenkool]

> Since ucc_geth is being migrated to use the phylib, the existing
> (undocumented) 'interface' property is being deprecated in favour
> of unconjoined variations 'max-speed' and 'interface-type'.

Again, please explain why this information shouldn't
be in the PHY node instead?


Segher

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

[Kim Phillips]

On Fri, 13 Apr 2007 21:02:25 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> > Since ucc_geth is being migrated to use the phylib, the existing
> > (undocumented) 'interface' property is being deprecated in favour
> > of unconjoined variations 'max-speed' and 'interface-type'.
> 
> Again, please explain why this information shouldn't
> be in the PHY node instead?
> 

Strictly speaking, it should be neither in the UCC node nor the PHY
node, as it describes the connection between the two, but..

the UCC driver utilizes the data itself; the UCC, unlike other network
controllers, does not provide interface data in its programming model.

the phy drivers are not of_ drivers.  Porting phylib drivers to be of_
drivers would break phylib for non-OF arches, e.g. x86.

Kim

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

[Kumar Gala]

On Apr 16, 2007, at 10:25 AM, Kim Phillips wrote:

> On Fri, 13 Apr 2007 21:02:25 +0200
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
>>> Since ucc_geth is being migrated to use the phylib, the existing
>>> (undocumented) 'interface' property is being deprecated in favour
>>> of unconjoined variations 'max-speed' and 'interface-type'.
>>
>> Again, please explain why this information shouldn't
>> be in the PHY node instead?
>>
>
> Strictly speaking, it should be neither in the UCC node nor the PHY
> node, as it describes the connection between the two, but..
>
> the UCC driver utilizes the data itself; the UCC, unlike other network
> controllers, does not provide interface data in its programming model.
>
> the phy drivers are not of_ drivers.  Porting phylib drivers to be of_
> drivers would break phylib for non-OF arches, e.g. x86.

Nothing stops the code in the UCC driver from grabbing the phy device  
node and pulling the information out if it.

I believe the question is about where the information should truly  
live.  It would seem to be more of a property of the phy than of the  
enet controller.

- k

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

[Segher Boessenkool]

>>>> Since ucc_geth is being migrated to use the phylib, the existing
>>>> (undocumented) 'interface' property is being deprecated in favour
>>>> of unconjoined variations 'max-speed' and 'interface-type'.
>>>
>>> Again, please explain why this information shouldn't
>>> be in the PHY node instead?
>>>
>>
>> Strictly speaking, it should be neither in the UCC node nor the PHY
>> node, as it describes the connection between the two, but..

Connections are never described with separate nodes in
the device tree.

>> the UCC driver utilizes the data itself; the UCC, unlike other network
>> controllers, does not provide interface data in its programming model.

I have no idea what this means?

>> the phy drivers are not of_ drivers.  Porting phylib drivers to be of_
>> drivers would break phylib for non-OF arches, e.g. x86.
>
> Nothing stops the code in the UCC driver from grabbing the phy device 
> node and pulling the information out if it.

Quite so.  This isn't "bad style" either, it is a perfectly
normal thing to do.

> I believe the question is about where the information should truly 
> live.

Yeah.

> It would seem to be more of a property of the phy than of the enet 
> controller.

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.


Segher

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

[Kim Phillips]

On Mon, 16 Apr 2007 17:47:18 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> >>>> Since ucc_geth is being migrated to use the phylib, the existing
> >>>> (undocumented) 'interface' property is being deprecated in favour
> >>>> of unconjoined variations 'max-speed' and 'interface-type'.
> >>>
> >>> Again, please explain why this information shouldn't
> >>> be in the PHY node instead?
> >>>
> >>
> >> Strictly speaking, it should be neither in the UCC node nor the PHY
> >> node, as it describes the connection between the two, but..
> 
> Connections are never described with separate nodes in
> the device tree.
> 
> >> the UCC driver utilizes the data itself; the UCC, unlike other network
> >> controllers, does not provide interface data in its programming model.
> 
> I have no idea what this means?

The UCC is a direct consumer of the values of the properties.

> >> the phy drivers are not of_ drivers.  Porting phylib drivers to be of_
> >> drivers would break phylib for non-OF arches, e.g. x86.
> >
> > Nothing stops the code in the UCC driver from grabbing the phy device 
> > node and pulling the information out if it.
> 
> Quite so.  This isn't "bad style" either, it is a perfectly
> normal thing to do.
> 
> > I believe the question is about where the information should truly 
> > live.
> 
> Yeah.
> 
> > It would seem to be more of a property of the phy than of the enet 
> > controller.
> 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.
> 

I don't need to know what type the PHY is, e.g. whether it's m88e11x1
compatible or not, the phylib handles that.

If I were to put the properties in the PHY node, I wouldn't be able to
describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable PHY,
or vice versa.

Kim

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

[Andy Fleming]

On Apr 16, 2007, at 10:47, Segher Boessenkool wrote:

>
>> I believe the question is about where the information should truly
>> live.
>
> Yeah.

Agreed

>
>> It would seem to be more of a property of the phy than of the enet
>> controller.
>
> 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.  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.

Ethernet controllers need to know what the connection is so they can  
establish a data connection with the PHYs

PHYs need to know what the connection is so they can establish a data  
connection with the ethernet controllers.

There is equal flexibility on both sides, and I think the choice of  
where to put this information is fairly arbitrary.  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
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.

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.  One can  
envision scenarios where multiple controllers are hooked up to one  
PHY, and each of the controllers can use different connections.  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.

Andy

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

[Segher Boessenkool]

> I don't need to know what type the PHY is, e.g. whether it's m88e11x1
> compatible or not, the phylib handles that.

You need to tell the phylib what kind of bus the PHY uses.
You can put "rgmii" or whatever in the "compatible" property
as well.

> If I were to put the properties in the PHY node, I wouldn't be able to
> describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable PHY,
> or vice versa.

Of course you can.  The "compatible" in the enet node
implies it can do 1000Mbps; the "compatible" in the
PHY node implies it does 100Mbps.


Segher

Re: [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

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

[Kim Phillips]

On Tue, 17 Apr 2007 01:18:56 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> > I don't need to know what type the PHY is, e.g. whether it's m88e11x1
> > compatible or not, the phylib handles that.
> 
> You need to tell the phylib what kind of bus the PHY uses.

sure, and ucc_geth does just that based on the interface-type property,
in addition to correspondingly programming the UCC.

> You can put "rgmii" or whatever in the "compatible" property
> as well.
> 
I don't understand how intermixing PHY device compatibility with the
UCC connection to the PHY would be a good thing.

> > If I were to put the properties in the PHY node, I wouldn't be able to
> > describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable PHY,
> > or vice versa.
> 
> Of course you can.  The "compatible" in the enet node
> implies it can do 1000Mbps; the "compatible" in the
> PHY node implies it does 100Mbps.

compatible in the UCC node is currently set to "ucc_geth", which does
not necessarily imply that that UCC can do 1000Mbit/s.  Some UCCs can
only do 100Mbit/s.

We currently do not have hardware that connects UCC with max-speed x
with a PHY with max. speed capability of y, where x != y, so there is
currently no need to specify the speed of the PHY.  Not that that would
be needed; the phylib would call ucc_geth's adjust_link with the new
speed.  Note that the max-speed property is used to set registers in the
UCC only.

Kim

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

[Andy Fleming]

On Apr 16, 2007, at 18:25, Segher Boessenkool wrote:

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

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.

>
>> 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*.


This is true to the extent that the device tree can't change on the  
fly.  But the device tree could be used to tell the software which  
one was chosen (by setting it manually, or by detecting it at runtime  
in the firmware), or it can be used to tell the software which one to  
choose.  This is really a side point to my argument, though.


>
>> 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.  PHYs are almost universally controlled  
through an MDIO bus which consists of 2 pins: clock and data.  This  
is not the ethernet packet data, though, it is configuration data.   
The PHYs can all be discovered on this bus, regardless of what  
interface is chosen for the data.


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

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.

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

Same point as above

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


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


Right.  It's exactly like the previous example, except the previous  
example has some PHYs sitting around, inactive.


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

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.  ;)

Andy

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

[Segher Boessenkool]

>> You can put "rgmii" or whatever in the "compatible" property
>> as well.
>>
> I don't understand how intermixing PHY device compatibility with the
> UCC connection to the PHY would be a good thing.

"compatible" means "what kind of device is this", for the
purposes of a client program (i.e., Linux) matching a
driver to it (i.e., it should say what kind of PHY it
is, and phylib should use that info -- in most cases,
it won't need more than the least specific entry in
"compatible", i.e. "rgmii" or whatever.

>>> If I were to put the properties in the PHY node, I wouldn't be able 
>>> to
>>> describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable 
>>> PHY,
>>> or vice versa.
>>
>> Of course you can.  The "compatible" in the enet node
>> implies it can do 1000Mbps; the "compatible" in the
>> PHY node implies it does 100Mbps.
>
> compatible in the UCC node is currently set to "ucc_geth", which does
> not necessarily imply that that UCC can do 1000Mbit/s.  Some UCCs can
> only do 100Mbit/s.

So those UCCs should have a different "compatible" entry.
It's not rocket science.

> We currently do not have hardware that connects UCC with max-speed x
> with a PHY with max. speed capability of y, where x != y, so there is
> currently no need to specify the speed of the PHY.  Not that that would
> be needed; the phylib would call ucc_geth's adjust_link with the new
> speed.  Note that the max-speed property is used to set registers in 
> the
> UCC only.

max-speed of connection = min(max-speed of enet, max-speed
of PHY) -- and both of those are implied by their respective
"compatible" properties.


Segher

Re: [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

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

[Kim Phillips]

On Tue, 17 Apr 2007 12:25:51 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> >> You can put "rgmii" or whatever in the "compatible" property
> >> as well.
> >>
> > I don't understand how intermixing PHY device compatibility with the
> > UCC connection to the PHY would be a good thing.
> 
> "compatible" means "what kind of device is this", for the
> purposes of a client program (i.e., Linux) matching a
> driver to it (i.e., it should say what kind of PHY it
> is, and phylib should use that info -- in most cases,
> it won't need more than the least specific entry in
> "compatible", i.e. "rgmii" or whatever.
> 

sorry, I disagree; for me, a compatible entry in the PHY node would look
something like "marvell" or "m88e11x1".  "rgmii" might indeed be
something that PHY supports, but it tells the driver nothing about how
to enable it (whereas "m88e11x1" would).  The rgmii designation in
question in this thread is not a property of the PHY, but of the board.

> >>> If I were to put the properties in the PHY node, I wouldn't be able 
> >>> to
> >>> describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable 
> >>> PHY,
> >>> or vice versa.
> >>
> >> Of course you can.  The "compatible" in the enet node
> >> implies it can do 1000Mbps; the "compatible" in the
> >> PHY node implies it does 100Mbps.
> >
> > compatible in the UCC node is currently set to "ucc_geth", which does
> > not necessarily imply that that UCC can do 1000Mbit/s.  Some UCCs can
> > only do 100Mbit/s.
> 
> So those UCCs should have a different "compatible" entry.
> It's not rocket science.
> 

It's referring to the name of the driver, as is compatible "gianfar".
other values could be "fsl_atm" or "ucc_uart", or whatever other
communications protocol a UCC can manage (to which, btw, max-speed would
be easily extensible).

> > We currently do not have hardware that connects UCC with max-speed x
> > with a PHY with max. speed capability of y, where x != y, so there is
> > currently no need to specify the speed of the PHY.  Not that that would
> > be needed; the phylib would call ucc_geth's adjust_link with the new
> > speed.  Note that the max-speed property is used to set registers in 
> > the
> > UCC only.
> 
> max-speed of connection = min(max-speed of enet, max-speed
> of PHY) -- and both of those are implied by their respective
> "compatible" properties.
> 

Again, max-speed is exclusively for configuring the UCC itself,
regardless of the connection speed.

Kim

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

[Segher Boessenkool]

>> "compatible" means "what kind of device is this", for the
>> purposes of a client program (i.e., Linux) matching a
>> driver to it (i.e., it should say what kind of PHY it
>> is, and phylib should use that info -- in most cases,
>> it won't need more than the least specific entry in
>> "compatible", i.e. "rgmii" or whatever.
>>
>
> sorry, I disagree; for me, a compatible entry in the PHY node would 
> look
> something like "marvell"

which would be completely wrong

> or "m88e11x1".

It should be something like "m88e11x1\0m88e1xxx\0rgmii" instead.
A "compatible" property can contain many values, ordered from
most exact to least exact.

> "rgmii" might indeed be
> something that PHY supports, but it tells the driver nothing about how
> to enable it (whereas "m88e11x1" would).  The rgmii designation in
> question in this thread is not a property of the PHY, but of the board.

It certainly is a property of the PHY as well.

>> So those UCCs should have a different "compatible" entry.
>> It's not rocket science.
>
> It's referring to the name of the driver,

No, not at all.  No device tree entry name/value has any
direct correspondence with Linux device driver names
(in principle; things can "accidentally" have the same
name, of course).

>> max-speed of connection = min(max-speed of enet, max-speed
>> of PHY) -- and both of those are implied by their respective
>> "compatible" properties.
>>
>
> Again, max-speed is exclusively for configuring the UCC itself,
> regardless of the connection speed.

If that is really true, and the value of that property
has nothing to do with the MAC<->PHY data channel, it should
have a different (not that generic) name.


Segher

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

[Kim Phillips]

On Wed, 18 Apr 2007 01:18:24 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> >> "compatible" means "what kind of device is this", for the
> >> purposes of a client program (i.e., Linux) matching a
> >> driver to it (i.e., it should say what kind of PHY it
> >> is, and phylib should use that info -- in most cases,
> >> it won't need more than the least specific entry in
> >> "compatible", i.e. "rgmii" or whatever.
> >>
> >
> > sorry, I disagree; for me, a compatible entry in the PHY node would 
> > look
> > something like "marvell"
> 
> which would be completely wrong
> 
that depends on what degree the manufacturer's PHYs are compatible.

> > or "m88e11x1".
> 
> It should be something like "m88e11x1\0m88e1xxx\0rgmii" instead.

m88e11x1 implies rgmii, including all the other interfaces the PHY
supports (gmii, mii, tbi, etc.).

..but I'm not interested in specifying what interfaces the PHY supports.

> A "compatible" property can contain many values, ordered from
> most exact to least exact.
> 
> > "rgmii" might indeed be
> > something that PHY supports, but it tells the driver nothing about how
> > to enable it (whereas "m88e11x1" would).  The rgmii designation in
> > question in this thread is not a property of the PHY, but of the board.
> 
> It certainly is a property of the PHY as well.
> 
sure.

> >> So those UCCs should have a different "compatible" entry.
> >> It's not rocket science.
> >
> > It's referring to the name of the driver,
> 
> No, not at all.  No device tree entry name/value has any
> direct correspondence with Linux device driver names
> (in principle; things can "accidentally" have the same
> name, of course).

well that may be the case here then.

> >> max-speed of connection = min(max-speed of enet, max-speed
> >> of PHY) -- and both of those are implied by their respective
> >> "compatible" properties.
> >>
> >
> > Again, max-speed is exclusively for configuring the UCC itself,
> > regardless of the connection speed.
> 
> If that is really true, and the value of that property
> has nothing to do with the MAC<->PHY data channel, it should
> have a different (not that generic) name.
> 

can you elaborate on why, including an example of what you'd think would
be a better one?

Kim

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

[Segher Boessenkool]

>>> sorry, I disagree; for me, a compatible entry in the PHY node would
>>> look
>>> something like "marvell"
>>
>> which would be completely wrong
>>
> that depends on what degree the manufacturer's PHYs are compatible.

No, if all there PHYs are compatible (and you have some
guarantee that all there future PHYs will be as well!)
it should read "marvell-phy" (or better, "MRVL,ethernet-phy"
or something similar).

>>> or "m88e11x1".
>>
>> It should be something like "m88e11x1\0m88e1xxx\0rgmii" instead.
>
> m88e11x1 implies rgmii, including all the other interfaces the PHY
> supports (gmii, mii, tbi, etc.).

If you don't put the less-specific entries there, only clients
(OSes) that know about the exact name can use that PHY.  So if
there is a minor upgrade of you board and it has a m88e11x2
instead, your OS needs an update to work with your new device
tree.  Not an ideal situation.

> ..but I'm not interested in specifying what interfaces the PHY 
> supports.

But you *have* to.  The device tree describes the hardware,
it is not a configuration file for Linux to use as it sees fit.

>>>> max-speed of connection = min(max-speed of enet, max-speed
>>>> of PHY) -- and both of those are implied by their respective
>>>> "compatible" properties.
>>>
>>> Again, max-speed is exclusively for configuring the UCC itself,
>>> regardless of the connection speed.
>>
>> If that is really true, and the value of that property
>> has nothing to do with the MAC<->PHY data channel, it should
>> have a different (not that generic) name.
>
> can you elaborate on why, including an example of what you'd think 
> would
> be a better one?

Very generic names should only be used by very generic bindings.
If a very specific device binding (like yours) uses a property
name like that, there is a high chance it will clash with a more
generic binding it uses (PCI, ethernet, network, ...) -- perhaps
with a *future* version of such a binding.

Also, it isn't a great name /an sich/: "max-speed" -- maximum
speed of what?


Segher

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

[Kim Phillips]

On Wed, 18 Apr 2007 12:34:27 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> >>> sorry, I disagree; for me, a compatible entry in the PHY node would
> >>> look
> >>> something like "marvell"
> >>
> >> which would be completely wrong
> >>
> > that depends on what degree the manufacturer's PHYs are compatible.
> 
> No, if all there PHYs are compatible (and you have some
> guarantee that all there future PHYs will be as well!)
> it should read "marvell-phy" (or better, "MRVL,ethernet-phy"
> or something similar).
> 
> >>> or "m88e11x1".
> >>
> >> It should be something like "m88e11x1\0m88e1xxx\0rgmii" instead.
> >
> > m88e11x1 implies rgmii, including all the other interfaces the PHY
> > supports (gmii, mii, tbi, etc.).
> 
> If you don't put the less-specific entries there, only clients
> (OSes) that know about the exact name can use that PHY.  So if
> there is a minor upgrade of you board and it has a m88e11x2
> instead, your OS needs an update to work with your new device
> tree.  Not an ideal situation.
> 
> > ..but I'm not interested in specifying what interfaces the PHY 
> > supports.
> 
> But you *have* to.  The device tree describes the hardware,
> it is not a configuration file for Linux to use as it sees fit.

not for the purposes of this patch; ucc_geth passes interface_type, a
property of the board describing the connection between the MAC and PHY
(not a list of what connection types the PHY is capable of) to the
phylib, and the phylib is left to probe, identify, and configure the PHY
appropriately.

> 
> >>>> max-speed of connection = min(max-speed of enet, max-speed
> >>>> of PHY) -- and both of those are implied by their respective
> >>>> "compatible" properties.
> >>>
> >>> Again, max-speed is exclusively for configuring the UCC itself,
> >>> regardless of the connection speed.
> >>
> >> If that is really true, and the value of that property
> >> has nothing to do with the MAC<->PHY data channel, it should
> >> have a different (not that generic) name.
> >
> > can you elaborate on why, including an example of what you'd think 
> > would
> > be a better one?
> 
> Very generic names should only be used by very generic bindings.

it's intentionally generic; UCCs are Universal Communications
Controllers and implement many communications protocols.

> If a very specific device binding (like yours) uses a property
> name like that, there is a high chance it will clash with a more
> generic binding it uses (PCI, ethernet, network, ...) -- perhaps
> with a *future* version of such a binding.
> 
I'm sure future versions will be able to adjust accordingly :)

> Also, it isn't a great name /an sich/: "max-speed" -- maximum
> speed of what?
> 

?  it's fine - it's in the context of a communications device.
Can you come up with something better?

Kim

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

[Segher Boessenkool]

>>> ..but I'm not interested in specifying what interfaces the PHY
>>> supports.
>>
>> But you *have* to.  The device tree describes the hardware,
>> it is not a configuration file for Linux to use as it sees fit.
>
> not for the purposes of this patch; ucc_geth passes interface_type,

It doesn't matter what the Linux code does.  The device tree
describes the hardware, it is not a configuration file for
Linux to use as it sees fit.

> a
> property of the board describing the connection between the MAC and PHY
> (not a list of what connection types the PHY is capable of) to the
> phylib, and the phylib is left to probe, identify, and configure the 
> PHY
> appropriately.

Sure there's an argument for describing what type of
interface the PHY is connected on, if it supports more
than one -- but that should be a property in the PHY
node, not the controller node, since you can have multiple
PHYs connected to the same controller, possibly on
different interfaces each.

The m88e11x1 phylib code seems to ignore the "interface"
parameter completely btw.

>>>>> Again, max-speed is exclusively for configuring the UCC itself,
>>>>> regardless of the connection speed.
>>>>
>>>> If that is really true, and the value of that property
>>>> has nothing to do with the MAC<->PHY data channel, it should
>>>> have a different (not that generic) name.
>>>
>>> can you elaborate on why, including an example of what you'd think
>>> would
>>> be a better one?
>>
>> Very generic names should only be used by very generic bindings.
>
> it's intentionally generic; UCCs are Universal Communications
> Controllers and implement many communications protocols.

So?  That doesn't put the UCC device binding on the same
level as, say, PCI or the base OF definition.

>> If a very specific device binding (like yours) uses a property
>> name like that, there is a high chance it will clash with a more
>> generic binding it uses (PCI, ethernet, network, ...) -- perhaps
>> with a *future* version of such a binding.
>>
> I'm sure future versions will be able to adjust accordingly :)

Do you really think that when future changes are made to
base OF, or the PCI binding, or similar, that people will
even stop to consider what you did in your (unofficial)
binding and try to stay compatible to it?  Can I have
some of those pills?

>> Also, it isn't a great name /an sich/: "max-speed" -- maximum
>> speed of what?
>
> ?  it's fine - it's in the context of a communications device.
> Can you come up with something better?

Sure.  "ucc,max-speed" solves one problem; "max-comm-speed"
solves another.  I'm sure there are better names possible,
so please find one.  Giving good names to things is hard,
so good luck.


Segher

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

[Andy Fleming]

On Apr 20, 2007, at 03:34, Segher Boessenkool wrote:

>>>> ..but I'm not interested in specifying what interfaces the PHY
>>>> supports.
>>>
>>> But you *have* to.  The device tree describes the hardware,
>>> it is not a configuration file for Linux to use as it sees fit.
>>
>> not for the purposes of this patch; ucc_geth passes interface_type,
>
> It doesn't matter what the Linux code does.  The device tree
> describes the hardware, it is not a configuration file for
> Linux to use as it sees fit.

Agreed.

>
>> a
>> property of the board describing the connection between the MAC  
>> and PHY
>> (not a list of what connection types the PHY is capable of) to the
>> phylib, and the phylib is left to probe, identify, and configure the
>> PHY
>> appropriately.
>
> Sure there's an argument for describing what type of
> interface the PHY is connected on, if it supports more
> than one -- but that should be a property in the PHY
> node, not the controller node, since you can have multiple
> PHYs connected to the same controller, possibly on
> different interfaces each.


I just want to reiterate that I disagree strongly with this  
statement.  If you have multiple PHYs hooked up to one ethernet  
controller, you're going to need to change the device tree to use a  
different PHY, anyway.  That, or have Linux ignore the phandle that  
points to the connected PHY.

Also, you'd need to do something to the hardware, since the different  
interfaces are not, typically, on different pins.  Just in different  
combinations.

And if you put it in the PHY node, you haven't really helped out the  
people who can change the interface type by flipping a dip switch.  I  
can think of two or three boards off the top of my head that do that  
(though I know of very few people who actually use this functionality).

My point, again, is that the interface type is not strongly tied to  
the PHY.  It is strongly tied to the board configuration.  We *could*  
put the interface type in the PHY node, but I want to disabuse you of  
the notion that it would be any better there.

Andy

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

[Segher Boessenkool]

>> Sure there's an argument for describing what type of
>> interface the PHY is connected on, if it supports more
>> than one -- but that should be a property in the PHY
>> node, not the controller node, since you can have multiple
>> PHYs connected to the same controller, possibly on
>> different interfaces each.
>
> I just want to reiterate that I disagree strongly with this statement. 
>  If you have multiple PHYs hooked up to one ethernet controller, 
> you're going to need to change the device tree to use a different PHY, 
> anyway.  That, or have Linux ignore the phandle that points to the 
> connected PHY.

On some configurations, what PHY to use is a runtime
decision, not a static thing.  No device tree change
is necessary then.

> And if you put it in the PHY node, you haven't really helped out the 
> people who can change the interface type by flipping a dip switch.  I 
> can think of two or three boards off the top of my head that do that 
> (though I know of very few people who actually use this 
> functionality).

Either the firmware can detect the switch setting
and create a proper device tree, or the user will
need to create the right static device tree.

> My point, again, is that the interface type is not strongly tied to 
> the PHY.  It is strongly tied to the board configuration.  We *could* 
> put the interface type in the PHY node, but I want to disabuse you of 
> the notion that it would be any better there.

I still think it's the best place for this information.


Segher

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

[Andy Fleming]

On Apr 21, 2007, at 12:22, Segher Boessenkool wrote:

>>> Sure there's an argument for describing what type of
>>> interface the PHY is connected on, if it supports more
>>> than one -- but that should be a property in the PHY
>>> node, not the controller node, since you can have multiple
>>> PHYs connected to the same controller, possibly on
>>> different interfaces each.
>>
>> I just want to reiterate that I disagree strongly with this  
>> statement.  If you have multiple PHYs hooked up to one ethernet  
>> controller, you're going to need to change the device tree to use  
>> a different PHY, anyway.  That, or have Linux ignore the phandle  
>> that points to the connected PHY.
>
> On some configurations, what PHY to use is a runtime
> decision, not a static thing.  No device tree change
> is necessary then.


1) Could you give me an example?

2) So you'd be having Linux ignore the phandle, then?


>> My point, again, is that the interface type is not strongly tied  
>> to the PHY.  It is strongly tied to the board configuration.  We  
>> *could* put the interface type in the PHY node, but I want to  
>> disabuse you of the notion that it would be any better there.
>
> I still think it's the best place for this information.


I still disagree.  :)

Andy

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

[Segher Boessenkool]

>> On some configurations, what PHY to use is a runtime
>> decision, not a static thing.  No device tree change
>> is necessary then.
>
> 1) Could you give me an example?

Some older (plugin) cards are like that.  I don't have
model numbers handy, sorry.

> 2) So you'd be having Linux ignore the phandle, then?

No, Linux would find all the PHYs connected, via the
device tree, and handle them all within the driver.


Segher