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
