Fixed PHY Device Tree usage?

Hello,

We have a case of an hardware platform that uses the mvneta network driver, but instead of the SoC being connected to a PHY, it's connected directly to a switch, so my understanding is that there's no MDIO bus, and we should have a kind of a "fake PHY" to make the mvneta driver believe that the link is up, at a given speed.

Looking at this problem, I stumbled across the "fixed PHY" driver in drivers/net/phy/fixed.c, which registers a fake "Fixed MDIO bus", and then provides a fixed_phy_add() API to add one "fake" PHY. This seems to fit my need, except that my ARM platform is obviously Device Tree based, so I'm wondering what I should do. One option is to implement a Device Tree binding for the fixed PHY driver (the exact DT binding would have to be discussed), but I'm wondering whether describing a fixed PHY in the DT is actually correct, because describing a fixed PHy is not really describing the hardware, the hardware is actually a switch.

Do you have some thoughts about this situation? Maybe there's already some solutions that I'm not aware of?

Thanks,

Hello Thomas,

2013/7/9 Thomas Petazzoni <[email protected]>:

Quoted 7 lines

Hello,

We have a case of an hardware platform that uses the mvneta network driver, but instead of the SoC being connected to a PHY, it's connected directly to a switch, so my understanding is that there's no MDIO bus, and we should have a kind of a "fake PHY" to make the mvneta driver believe that the link is up, at a given speed.

Good timing, I was about to post questions/suggestions about how we should represent fixed PHYs in device tree.

Quoted 10 lines

Looking at this problem, I stumbled across the "fixed PHY" driver in drivers/net/phy/fixed.c, which registers a fake "Fixed MDIO bus", and then provides a fixed_phy_add() API to add one "fake" PHY. This seems to fit my need, except that my ARM platform is obviously Device Tree based, so I'm wondering what I should do. One option is to implement a Device Tree binding for the fixed PHY driver (the exact DT binding would have to be discussed), but I'm wondering whether describing a fixed PHY in the DT is actually correct, because describing a fixed PHy is not really describing the hardware, the hardware is actually a switch.

Well, it does not seem to be too far from the "hardware" reality to describe a link between a switch CPU port and an Ethernet MAC as a fixed PHY because that is what it really is in fact. Once you have a drivers for your switch you can start using this PHY along with its corresponding driver.

There is a helper: of_phy_connect_fixed_link() in drivers/of/of_mdio.c is flagged as being a
temporary solution for Freescale Ethernet drivers to move to something else, so I would like to discuss what the "something else should be".

Here what I would like to see the new "fixed-link" phy node look like:

ethernet-phy@0 {
     reg = <0>;
     id = "deadbeef";
     speed = <1000>;
     full-duplex;
     pause;
     asym-pause;
};

It has the same properties as the binding described in:
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt but expressed in a more explicit way instead of using an array of integers.

Quoted 4 lines

Do you have some thoughts about this situation? Maybe there's already some solutions that I'm not aware of?

Thanks,

--
Florian

Quoted 8 lines

Quoted 5 lines

We have a case of an hardware platform that uses the mvneta network driver, but instead of the SoC being connected to a PHY, it's connected directly to a switch, so my understanding is that there's no MDIO bus, and we should have a kind of a "fake PHY" to make the mvneta driver believe that the link is up, at a given speed.

Good timing, I was about to post questions/suggestions about how we should represent fixed PHYs in device tree.

Quoted 5 lines

Well, it does not seem to be too far from the "hardware" reality to describe a link between a switch CPU port and an Ethernet MAC as a fixed PHY because that is what it really is in fact. Once you have a drivers for your switch you can start using this PHY along with its corresponding driver.

Quoted 4 lines

There is a helper: of_phy_connect_fixed_link() in drivers/of/of_mdio.c is flagged as being a
temporary solution for Freescale Ethernet drivers to move to something else, so I would like to discuss what the "something else should be".

Quoted 11 lines

Here what I would like to see the new "fixed-link" phy node look like:

ethernet-phy@0 {
     reg = <0>;
     id = "deadbeef";
     speed = <1000>;
     full-duplex;
     pause;
     asym-pause;
};

Quoted 3 lines

It has the same properties as the binding described in:
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt but expressed in a more explicit way instead of using an array of integers.

Quoted 4 lines

Quoted 4 lines

It has the same properties as the binding described in:
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt but expressed in a more explicit way instead of using an array of integers.

And so the fixed-phy driver would look for what exactly in the Device Tree to find which fixed PHYs to create?

Should we have something like:

mdio-fixed {
compatible = "generic,mdio-fixed";
phy0: ethernet-phy@0 {
... all the properties you listed ... ... maybe the "id" property is not needed
because of the phandle ...

                };

                phy1: ethernet-phy@1 {
                        ... all the properties you listed ...
                        ... maybe the "id" property is not needed
                            because of the phandle ...
                };
        };

        soc {
                ethernet@0 {
                        phy = <&phy0>;
                        ...
                };

                ethernet@1 {
                        phy = <&phy1>;
                        ...
                };
        };

or do you have in mind another representation?

Quoted 8 lines

Should we have something like:

mdio-fixed {
compatible = "generic,mdio-fixed";
phy0: ethernet-phy@0 {
... all the properties you listed ... ... maybe the "id" property is not needed
because of the phandle ...

In the "fixed-phy" terminology "id" is unfortunately ambiguous, the driver internally uses "phy_id" which is nothing more than a PHY address, but it also supports being assigned an "id" as in Identification register 2 & 3. I was refering to the identification register by "id".

Quoted 21 lines

                };

                phy1: ethernet-phy@1 {
                        ... all the properties you listed ...
                        ... maybe the "id" property is not needed
                            because of the phandle ...
                };
        };

        soc {
                ethernet@0 {
                        phy = <&phy0>;
                        ...
                };

                ethernet@1 {
                        phy = <&phy1>;
                        ...
                };
        };

Quoted 1 line

or do you have in mind another representation?

Not really this is more or less what I had in mind. I am wondering whether we should really declare the "mdio-fixed" node, or if we should not rather make the following:

- declare all PHY nodes in the system as sub nodes of their belonging real hardware MDIO bus node
- flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
- if we see that flag, make that specific PHY node bind to the fixed-phy driver instead

What do you think? I suspect someone might rightfully say that the "fixed-mdio" is not a real piece of hardware and is just a software concept. A PHY in the real world may very well have a fixed link speed/duplex/pause settings on the other end.

Dear Florian Fainelli,

On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:

Quoted 28 lines

Quoted 22 lines

                };

                phy1: ethernet-phy@1 {
                        ... all the properties you listed ...
                        ... maybe the "id" property is not needed
                            because of the phandle ...
                };
        };

        soc {
                ethernet@0 {
                        phy = <&phy0>;
                        ...
                };

                ethernet@1 {
                        phy = <&phy1>;
                        ...
                };
        };

Quoted 1 line

or do you have in mind another representation?

Not really this is more or less what I had in mind. I am wondering whether we should really declare the "mdio-fixed" node, or if we should not rather make the following:

Quoted 5 lines

- declare all PHY nodes in the system as sub nodes of their belonging real hardware MDIO bus node
- flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
- if we see that flag, make that specific PHY node bind to the fixed-phy driver instead

So the fixed PHY driver is going to travel through *all* nodes of the DT, and whenever some random node has a "fixed" property, it's going to say it corresponds to a fixed PHY? That doesn't seem like a good idea.

So that's really what I was asking: how is the fixed PHY driver going to know which DT nodes to look at. Is it a platform_driver, where the corresponding DT node has sub-nodes? Is it something else? Or a specific compatible string?

Quoted 5 lines

What do you think? I suspect someone might rightfully say that the "fixed-mdio" is not a real piece of hardware and is just a software concept. A PHY in the real world may very well have a fixed link speed/duplex/pause settings on the other end.

I agree that the mdio-fixed idea is clearly moving away from the hardware representation. But see my question above: we need a way of letting the fixed PHY driver know which DT nodes it should have a look at. And just saying "those nodes will have property 'foo' is not sufficient".

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Quoted 9 lines

Quoted 5 lines

- declare all PHY nodes in the system as sub nodes of their belonging real hardware MDIO bus node
- flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
- if we see that flag, make that specific PHY node bind to the fixed-phy driver instead

So the fixed PHY driver is going to travel through *all* nodes of the DT, and whenever some random node has a "fixed" property, it's going to say it corresponds to a fixed PHY? That doesn't seem like a good idea.

Why not? Since we are already have to scan the entire MDIO bus we are attached to, when we encounter such a PHY node with the special "fixed" properties, we just call fixed_phy_add() with the right parameters and voila. Which is also the reason why I was suggesting to put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that we have this logic only in one place.

Quoted 4 lines

So that's really what I was asking: how is the fixed PHY driver going to know which DT nodes to look at. Is it a platform_driver, where the corresponding DT node has sub-nodes? Is it something else? Or a specific compatible string?

Without DT at play here, the usual way to register a fixed PHY is:

1) make your arch code or whatever runs before the fixed MDIO bus probing to call fixed_phy_add() with the expected parameters
2) when your ethernet driver probes its PHY devices, format the phy name to be bound to the fixed bus with the expected address by then the fixed MDIO bus would have already been probed and would find the fixed PHY nodes because of the first step
3) call of_phy_connect() from your driver to attach to the fixed PHY

Quoted 6 lines

Why not? Since we are already have to scan the entire MDIO bus we are attached to, when we encounter such a PHY node with the special "fixed" properties, we just call fixed_phy_add() with the right parameters and voila. Which is also the reason why I was suggesting to put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that we have this logic only in one place.

I'm still not sure to understand you here. Scanning the *entire* DT tree and consider all nodes having a property named "fixed" as fixed PHYs is definitely not acceptable. So I suppose you have a different idea, but I'm still not getting it. Where in the DT would the fixed PHY driver start looking for fixed PHYs ?

Quoted 8 lines

Quoted 5 lines

So that's really what I was asking: how is the fixed PHY driver going to know which DT nodes to look at. Is it a platform_driver, where the corresponding DT node has sub-nodes? Is it something else? Or a specific compatible string?

Without DT at play here, the usual way to register a fixed PHY is:

Quoted 7 lines

1) make your arch code or whatever runs before the fixed MDIO bus probing to call fixed_phy_add() with the expected parameters
2) when your ethernet driver probes its PHY devices, format the phy name to be bound to the fixed bus with the expected address by then the fixed MDIO bus would have already been probed and would find the fixed PHY nodes because of the first step
3) call of_phy_connect() from your driver to attach to the fixed PHY

Right, but that's still doesn't answer the question of how the fixed PHY driver discovers from the DT which PHYs to instantiate.

For example, we would probably have something:

        phys {
                phy0: phy@0 {
                        ... PHY properties ...
                };
                phy1: phy@1 {
                        ... PHY properties ...
                };
        };

        soc {
                ethernet@0 {
                        compatible = "...";
                        ...
                        phy = <&phy0>;
                };
                ethernet@1 {
                        compatible = "...";
                        ...
                        phy = <&phy1>;
                };
        };

How will the fixed PHY driver know that it should instantiate phy@0 and phy@1 as PHY devices?

I am talking about scanning the MDIO bus DT nodes, not the entire DT. That job is already done by of_mdiobus_probe() to register PHY devices, so having a central point where the knowledge of how to treat PHY deivces could be here I guess.

Well either we go with some specific compatible property like "ethernet-phy-fixed" for instance, or we simply add a boolean property to the node, so a fixed PHY would either look like this:

phy {
         compatible = "linux,ethernet-phy-fixed";
         speed = <1000>;
         duplex = <1>;
         pause;
         asym-pause;
};

or respectively, something like this:

phy {
         fixed;
         speed = <1000>;
         duplex = <1>;
         pause;
         asym-pause;
};

Hello Thomas,

2013/7/10 Thomas Petazzoni <[email protected]>:

Quoted 3 lines

Dear Florian Fainelli,

On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:

[snip]

Quoted 34 lines

Quoted 28 lines

Quoted 22 lines

                };

                phy1: ethernet-phy@1 {
                        ... all the properties you listed ...
                        ... maybe the "id" property is not needed
                            because of the phandle ...
                };
        };

        soc {
                ethernet@0 {
                        phy = <&phy0>;
                        ...
                };

                ethernet@1 {
                        phy = <&phy1>;
                        ...
                };
        };

Quoted 1 line

or do you have in mind another representation?

Not really this is more or less what I had in mind. I am wondering whether we should really declare the "mdio-fixed" node, or if we should not rather make the following:

Quoted 5 lines

- declare all PHY nodes in the system as sub nodes of their belonging real hardware MDIO bus node
- flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
- if we see that flag, make that specific PHY node bind to the fixed-phy driver instead

Quoted 3 lines

So the fixed PHY driver is going to travel through *all* nodes of the DT, and whenever some random node has a "fixed" property, it's going to say it corresponds to a fixed PHY? That doesn't seem like a good idea.

Why not? Since we are already have to scan the entire MDIO bus we are attached to, when we encounter such a PHY node with the special "fixed" properties, we just call fixed_phy_add() with the right parameters and voila. Which is also the reason why I was suggesting to put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that we have this logic only in one place.

Quoted 46 lines · Florian Fainelli

Hello Thomas,

2013/7/10 Thomas Petazzoni <[email protected]>:

Quoted 3 lines

Dear Florian Fainelli,

On Wed, 10 Jul 2013 17:29:44 +0100, Florian Fainelli wrote:

[snip]

Quoted 34 lines

Quoted 28 lines

Quoted 22 lines

                 };

                 phy1: ethernet-phy@1 {
                         ... all the properties you listed ...
                         ... maybe the "id" property is not needed
                             because of the phandle ...
                 };
         };

         soc {
                 ethernet@0 {
                         phy = <&phy0>;
                         ...
                 };

                 ethernet@1 {
                         phy = <&phy1>;
                         ...
                 };
         };

Quoted 1 line

or do you have in mind another representation?

Not really this is more or less what I had in mind. I am wondering whether we should really declare the "mdio-fixed" node, or if we should not rather make the following:

Quoted 5 lines

- declare all PHY nodes in the system as sub nodes of their belonging real hardware MDIO bus node
- flag specific PHY nodes as "fixed" with a "fixed-link" boolean for instance
- if we see that flag, make that specific PHY node bind to the fixed-phy driver instead

Quoted 3 lines

So the fixed PHY driver is going to travel through *all* nodes of the DT, and whenever some random node has a "fixed" property, it's going to say it corresponds to a fixed PHY? That doesn't seem like a good idea.

Quoted 6 lines

Why not? Since we are already have to scan the entire MDIO bus we are attached to, when we encounter such a PHY node with the special "fixed" properties, we just call fixed_phy_add() with the right parameters and voila. Which is also the reason why I was suggesting to put the "fixed" PHY nodes as sub-nodes of the real MDIO node such that we have this logic only in one place.

Hi Florian,

I think this discussion is going in the wrong direction. The concept of a dummy phy is really a Linux kernel internal detail. Creating some kind of dummy MDIO bus node does not describe the hardware. There is already support in the kernel for Ethernet MACs connected directly to a switch or other device. It is far better to describe how the MAC needs to be configured than to invent a non-existent phy. Search for "fixed-link" in the kernel tree to see how it is used.

I think this discussion is going in the wrong direction. The concept of a dummy phy is really a Linux kernel internal detail. Creating some kind of dummy MDIO bus node does not describe the hardware.

There is
already support in the kernel for Ethernet MACs connected directly to a switch or other device. It is far better to describe how the MAC needs to be configured than to invent a non-existent phy. Search for "fixed-link" in the kernel tree to see how it is used.