We need to specifically deal with phylink_of_phy_connect() returning
-ENODEV, because this can happen when a CPU/DSA port does connect
neither to a PHY, nor has a fixed-link property. This is a valid use
case that is permitted by the binding and indicates to the switch:
auto-configure port with maximum capabilities.
Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
Signed-off-by: Florian Fainelli <[email protected]>
---
net/dsa/port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index d74bc9df1359..dde3085ff065 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -622,7 +622,7 @@ static int dsa_port_phylink_register(struct dsa_port *dp)
}
err = phylink_of_phy_connect(dp->pl, port_dn, 0);
- if (err) {
+ if (err && err != -ENODEV) {
pr_err("could not attach to PHY: %d\n", err);
goto err_phy_connect;
}
--
2.17.1
On Mon, 10 Jun 2019 at 22:31, Florian Fainelli <[email protected]> wrote:
>
> We need to specifically deal with phylink_of_phy_connect() returning
> -ENODEV, because this can happen when a CPU/DSA port does connect
> neither to a PHY, nor has a fixed-link property. This is a valid use
> case that is permitted by the binding and indicates to the switch:
> auto-configure port with maximum capabilities.
>
> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
> net/dsa/port.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index d74bc9df1359..dde3085ff065 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -622,7 +622,7 @@ static int dsa_port_phylink_register(struct dsa_port *dp)
> }
>
> err = phylink_of_phy_connect(dp->pl, port_dn, 0);
> - if (err) {
> + if (err && err != -ENODEV) {
> pr_err("could not attach to PHY: %d\n", err);
> goto err_phy_connect;
> }
> --
> 2.17.1
>
Hi Florian,
Can you give an example of when this is a valid use case, and why
fixed-link is not appropriate?
Regards,
-Vladimir
On 6/10/19 10:53 PM, Vladimir Oltean wrote:
> On Mon, 10 Jun 2019 at 22:31, Florian Fainelli <[email protected]> wrote:
>>
>> We need to specifically deal with phylink_of_phy_connect() returning
>> -ENODEV, because this can happen when a CPU/DSA port does connect
>> neither to a PHY, nor has a fixed-link property. This is a valid use
>> case that is permitted by the binding and indicates to the switch:
>> auto-configure port with maximum capabilities.
>>
>> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
>> Signed-off-by: Florian Fainelli <[email protected]>
>> ---
>> net/dsa/port.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/dsa/port.c b/net/dsa/port.c
>> index d74bc9df1359..dde3085ff065 100644
>> --- a/net/dsa/port.c
>> +++ b/net/dsa/port.c
>> @@ -622,7 +622,7 @@ static int dsa_port_phylink_register(struct dsa_port *dp)
>> }
>>
>> err = phylink_of_phy_connect(dp->pl, port_dn, 0);
>> - if (err) {
>> + if (err && err != -ENODEV) {
>> pr_err("could not attach to PHY: %d\n", err);
>> goto err_phy_connect;
>> }
>> --
>> 2.17.1
>>
>
> Hi Florian,
>
> Can you give an example of when this is a valid use case, and why
> fixed-link is not appropriate?
>
> Regards,
> -Vladimir
>
Hi,
This reminds me of a previous discussion on what to do when the DSA CPU
port does not have a device_tree node at all:
https://www.spinics.net/lists/netdev/msg573554.html.
This was the case of the dsa-loop driver that probes as a platform
device. I'm still not clear how the PHYLINK callbacks are supposed to
work in that case though.
--
Ioana
> Hi Florian,
>
> Can you give an example of when this is a valid use case, and why
> fixed-link is not appropriate?
A DSA link is used to connect two switches together. ZII devel b and c
are two boards which does this. Such links have the MACs connected
back to back, no PHYs involved. You can also connect a SoC interface
to the CPU port of a switch without having PHYs involved.
We have defined that CPU and DSA ports are always configured by the
driver to there maximum speed. Because of this, you often don't need a
fixed-link on CPU or DSA ports. So you will see most DT blobs don't
have any sort of PHY for the CPU or DSA ports.
You only need fixed-link when you need to slow a port down, e.g. a SoC
FE port connected to a switch 1G port.
Andrew
On Mon, Jun 10, 2019 at 12:31:49PM -0700, Florian Fainelli wrote:
> We need to specifically deal with phylink_of_phy_connect() returning
> -ENODEV, because this can happen when a CPU/DSA port does connect
> neither to a PHY, nor has a fixed-link property. This is a valid use
> case that is permitted by the binding and indicates to the switch:
> auto-configure port with maximum capabilities.
>
> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
> Signed-off-by: Florian Fainelli <[email protected]>
Hi Florian
This fixes the regression.
Reviewed-by: Andrew Lunn <[email protected]>
But i wonder if we want to add in
(dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port) i.e. force a
user port to have some form of PHY?
Andrew
From: Florian Fainelli <[email protected]>
Date: Mon, 10 Jun 2019 12:31:49 -0700
> We need to specifically deal with phylink_of_phy_connect() returning
> -ENODEV, because this can happen when a CPU/DSA port does connect
> neither to a PHY, nor has a fixed-link property. This is a valid use
> case that is permitted by the binding and indicates to the switch:
> auto-configure port with maximum capabilities.
>
> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")
> Signed-off-by: Florian Fainelli <[email protected]>
Applied.