[PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

Subsystems: marvell 88e6xxx ethernet switch fabric driver, networking drivers, networking [dsa], the rest

STALE1770d

9 messages, 4 authors, 2021-12-07 · open the first message on its own page

[PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: Russell King (Oracle) <hidden>
Date: 2021-12-07 10:59:24

Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
---
This patch requires:
https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk

If we convert Marvell DSA filly to split PCS (we have 6185 and 6352
complete, 6390 and 6393 remain), the "legacy_march2020" patches, and
the phylink get_caps patches, we can then make Marvell DSA a non-
legacy phylink driver. This gives much cleaner semantics concerning
when the phylink_mac_config() method is called. Specifically, being
non-legacy means phylink_mac_config() will no longer be called just
before every phylink_mac_link_up() method call, and will not be called
for in-band advertisement changes.

This means that phylink_mac_config() will only be called when the port
needs to be reconfigured, which allows drivers to force the link down
for safe reconfiguration without potentially causing an infinite loop
of link-down link-up events that can occur with the legacy behaviour.

Thus, being non-legacy and allowing the forcing removes the need for
DSA to synthesise a call to phylink_mac_link_down() at initialisation
time for this driver... but we need all DSA drivers to be non-legacy
before we can safely remove that.

 drivers/net/dsa/mv88e6xxx/chip.c | 56 +++++++++++++++++++-------------
 1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 9f675464efc3..b033e653d3f4 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -698,7 +698,7 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
 {
 	struct mv88e6xxx_chip *chip = ds->priv;
 	struct mv88e6xxx_port *p;
-	int err;
+	int err = 0;
 
 	p = &chip->ports[port];
 
@@ -711,31 +711,43 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port,
 		return;
 
 	mv88e6xxx_reg_lock(chip);
-	/* In inband mode, the link may come up at any time while the link
-	 * is not forced down. Force the link down while we reconfigure the
-	 * interface mode.
-	 */
-	if (mode == MLO_AN_INBAND && p->interface != state->interface &&
-	    chip->info->ops->port_set_link)
-		chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN);
 
-	err = mv88e6xxx_port_config_interface(chip, port, state->interface);
-	if (err && err != -EOPNOTSUPP)
-		goto err_unlock;
-
-	err = mv88e6xxx_serdes_pcs_config(chip, port, mode, state->interface,
-					  state->advertising);
-	/* FIXME: we should restart negotiation if something changed - which
-	 * is something we get if we convert to using phylinks PCS operations.
-	 */
-	if (err > 0)
-		err = 0;
+	if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port)) {
+		/* In inband mode, the link may come up at any time while the
+		 * link is not forced down. Force the link down while we
+		 * reconfigure the interface mode.
+		 */
+		if (mode == MLO_AN_INBAND &&
+		    p->interface != state->interface &&
+		    chip->info->ops->port_set_link)
+			chip->info->ops->port_set_link(chip, port,
+						       LINK_FORCED_DOWN);
+
+		err = mv88e6xxx_port_config_interface(chip, port,
+						      state->interface);
+		if (err && err != -EOPNOTSUPP)
+			goto err_unlock;
+
+		err = mv88e6xxx_serdes_pcs_config(chip, port, mode,
+						  state->interface,
+						  state->advertising);
+		/* FIXME: we should restart negotiation if something changed -
+		 * which is something we get if we convert to using phylinks
+		 * PCS operations.
+		 */
+		if (err > 0)
+			err = 0;
+	}
 
 	/* Undo the forced down state above after completing configuration
-	 * irrespective of its state on entry, which allows the link to come up.
+	 * irrespective of its state on entry, which allows the link to come
+	 * up in the in-band case where there is no separate SERDES. Also
+	 * ensure that the link can come up if the PPU is in use and we are
+	 * in PHY mode (we treat the PPU as an effective in-band mechanism.)
 	 */
-	if (mode == MLO_AN_INBAND && p->interface != state->interface &&
-	    chip->info->ops->port_set_link)
+	if (chip->info->ops->port_set_link &&
+	    ((mode == MLO_AN_INBAND && p->interface != state->interface) ||
+	     (mode == MLO_AN_PHY && mv88e6xxx_port_ppu_updates(chip, port))))
 		chip->info->ops->port_set_link(chip, port, LINK_UNFORCED);
 
 	p->interface = state->interface;
-- 
2.30.2

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: Martyn Welch <hidden>
Date: 2021-12-07 12:47:40

Sorry Russell, but unfortunately this patch doesn't seem to be
resolving the issue for me.

I've dumped in a bit of debug around this change to see if I could
determine what was going on here, it seems that in my case the function
is being exited before this at:

/* FIXME: is this the correct test? If we're in fixed mode on an
 * internal port, why should we process this any different from
 * PHY mode? On the other hand, the port may be automedia between
 * an internal PHY and the serdes...
 */
if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port))
        return;

Martyn


On Tue, 2021-12-07 at 10:59 +0000, Russell King (Oracle) wrote:
quoted hunk
Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
---
This patch requires:
https://lore.kernel.org/r/E1muXm7-00EwJB-7n@rmk-PC.armlinux.org.uk

If we convert Marvell DSA filly to split PCS (we have 6185 and 6352
complete, 6390 and 6393 remain), the "legacy_march2020" patches, and
the phylink get_caps patches, we can then make Marvell DSA a non-
legacy phylink driver. This gives much cleaner semantics concerning
when the phylink_mac_config() method is called. Specifically, being
non-legacy means phylink_mac_config() will no longer be called just
before every phylink_mac_link_up() method call, and will not be called
for in-band advertisement changes.

This means that phylink_mac_config() will only be called when the port
needs to be reconfigured, which allows drivers to force the link down
for safe reconfiguration without potentially causing an infinite loop
of link-down link-up events that can occur with the legacy behaviour.

Thus, being non-legacy and allowing the forcing removes the need for
DSA to synthesise a call to phylink_mac_link_down() at initialisation
time for this driver... but we need all DSA drivers to be non-legacy
before we can safely remove that.

 drivers/net/dsa/mv88e6xxx/chip.c | 56 +++++++++++++++++++-------------
 1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
b/drivers/net/dsa/mv88e6xxx/chip.c
index 9f675464efc3..b033e653d3f4 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -698,7 +698,7 @@ static void mv88e6xxx_mac_config(struct dsa_switch
*ds, int port,
 {
        struct mv88e6xxx_chip *chip = ds->priv;
        struct mv88e6xxx_port *p;
-       int err;
+       int err = 0;
 
        p = &chip->ports[port];
 
@@ -711,31 +711,43 @@ static void mv88e6xxx_mac_config(struct
dsa_switch *ds, int port,
                return;
 
        mv88e6xxx_reg_lock(chip);
-       /* In inband mode, the link may come up at any time while the
link
-        * is not forced down. Force the link down while we reconfigure
the
-        * interface mode.
-        */
-       if (mode == MLO_AN_INBAND && p->interface != state->interface
&&
-           chip->info->ops->port_set_link)
-               chip->info->ops->port_set_link(chip, port,
LINK_FORCED_DOWN);
 
-       err = mv88e6xxx_port_config_interface(chip, port, state-
quoted
interface);
-       if (err && err != -EOPNOTSUPP)
-               goto err_unlock;
-
-       err = mv88e6xxx_serdes_pcs_config(chip, port, mode, state-
quoted
interface,
-                                         state->advertising);
-       /* FIXME: we should restart negotiation if something changed -
which
-        * is something we get if we convert to using phylinks PCS
operations.
-        */
-       if (err > 0)
-               err = 0;
+       if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port))
{
+               /* In inband mode, the link may come up at any time
while the
+                * link is not forced down. Force the link down while
we
+                * reconfigure the interface mode.
+                */
+               if (mode == MLO_AN_INBAND &&
+                   p->interface != state->interface &&
+                   chip->info->ops->port_set_link)
+                       chip->info->ops->port_set_link(chip, port,
+                                                     
LINK_FORCED_DOWN);
+
+               err = mv88e6xxx_port_config_interface(chip, port,
+                                                     state-
quoted
interface);
+               if (err && err != -EOPNOTSUPP)
+                       goto err_unlock;
+
+               err = mv88e6xxx_serdes_pcs_config(chip, port, mode,
+                                                 state->interface,
+                                                 state->advertising);
+               /* FIXME: we should restart negotiation if something
changed -
+                * which is something we get if we convert to using
phylinks
+                * PCS operations.
+                */
+               if (err > 0)
+                       err = 0;
+       }
 
        /* Undo the forced down state above after completing
configuration
-        * irrespective of its state on entry, which allows the link to
come up.
+        * irrespective of its state on entry, which allows the link to
come
+        * up in the in-band case where there is no separate SERDES.
Also
+        * ensure that the link can come up if the PPU is in use and we
are
+        * in PHY mode (we treat the PPU as an effective in-band
mechanism.)
         */
-       if (mode == MLO_AN_INBAND && p->interface != state->interface
&&
-           chip->info->ops->port_set_link)
+       if (chip->info->ops->port_set_link &&
+           ((mode == MLO_AN_INBAND && p->interface != state-
quoted
interface) ||
+            (mode == MLO_AN_PHY && mv88e6xxx_port_ppu_updates(chip,
port))))
                chip->info->ops->port_set_link(chip, port,
LINK_UNFORCED);
 
        p->interface = state->interface;

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2021-12-07 12:58:35

On Tue, Dec 07, 2021 at 12:47:35PM +0000, Martyn Welch wrote:
Sorry Russell, but unfortunately this patch doesn't seem to be
resolving the issue for me.

I've dumped in a bit of debug around this change to see if I could
determine what was going on here, it seems that in my case the function
is being exited before this at:

/* FIXME: is this the correct test? If we're in fixed mode on an
 * internal port, why should we process this any different from
 * PHY mode? On the other hand, the port may be automedia between
 * an internal PHY and the serdes...
 */
if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port))
        return;
Oh, I was going to remove that, but clearly forgot, sorry. Please can
you try again with that removed? Meanwhile, I'll update the patch at
my end.

Thanks.
-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: Martyn Welch <hidden>
Date: 2021-12-07 14:20:40

On Tue, 2021-12-07 at 12:58 +0000, Russell King (Oracle) wrote:
On Tue, Dec 07, 2021 at 12:47:35PM +0000, Martyn Welch wrote:
quoted
Sorry Russell, but unfortunately this patch doesn't seem to be
resolving the issue for me.

I've dumped in a bit of debug around this change to see if I could
determine what was going on here, it seems that in my case the
function
is being exited before this at:

/* FIXME: is this the correct test? If we're in fixed mode on an
 * internal port, why should we process this any different from
 * PHY mode? On the other hand, the port may be automedia between
 * an internal PHY and the serdes...
 */
if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port))
        return;
Oh, I was going to remove that, but clearly forgot, sorry. Please can
you try again with that removed? Meanwhile, I'll update the patch at
my end.
Yes! That makes it work for me.

To be clear, the additional change I made was:

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
b/drivers/net/dsa/mv88e6xxx/chip.c
index b033e653d3f4..14f87f6ac479 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -702,14 +702,6 @@ static void mv88e6xxx_mac_config(struct dsa_switch
*ds, int port,
 
        p = &chip->ports[port];
 
-       /* FIXME: is this the correct test? If we're in fixed mode on
an
-        * internal port, why should we process this any different from
-        * PHY mode? On the other hand, the port may be automedia
between
-        * an internal PHY and the serdes...
-        */
-       if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds,
port))
-               return;
-
        mv88e6xxx_reg_lock(chip);
 
        if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port))
{


Assuming that's also what you've done:

Tested-by: Martyn Welch <redacted>

Thanks for your help!

Martyn

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2021-12-07 14:23:28

On Tue, Dec 07, 2021 at 02:20:28PM +0000, Martyn Welch wrote:
quoted hunk
On Tue, 2021-12-07 at 12:58 +0000, Russell King (Oracle) wrote:
quoted
On Tue, Dec 07, 2021 at 12:47:35PM +0000, Martyn Welch wrote:
quoted
Sorry Russell, but unfortunately this patch doesn't seem to be
resolving the issue for me.

I've dumped in a bit of debug around this change to see if I could
determine what was going on here, it seems that in my case the
function
is being exited before this at:

/* FIXME: is this the correct test? If we're in fixed mode on an
 * internal port, why should we process this any different from
 * PHY mode? On the other hand, the port may be automedia between
 * an internal PHY and the serdes...
 */
if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port))
        return;
Oh, I was going to remove that, but clearly forgot, sorry. Please can
you try again with that removed? Meanwhile, I'll update the patch at
my end.
Yes! That makes it work for me.

To be clear, the additional change I made was:

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
b/drivers/net/dsa/mv88e6xxx/chip.c
index b033e653d3f4..14f87f6ac479 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -702,14 +702,6 @@ static void mv88e6xxx_mac_config(struct dsa_switch
*ds, int port,
 
        p = &chip->ports[port];
 
-       /* FIXME: is this the correct test? If we're in fixed mode on
an
-        * internal port, why should we process this any different from
-        * PHY mode? On the other hand, the port may be automedia
between
-        * an internal PHY and the serdes...
-        */
-       if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds,
port))
-               return;
-
        mv88e6xxx_reg_lock(chip);
 
        if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port))
{


Assuming that's also what you've done:
That is exactly right, indeed, thanks!
Tested-by: Martyn Welch <redacted>

Thanks for your help!
Thanks for testing. I'll wait a little while in case there's any
further comments.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-12-07 14:54:45

On Tue, Dec 07, 2021 at 10:59:19AM +0000, Russell King (Oracle) wrote:
Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
Hi Russell

It would be good to have a Fixes: tag here, to help with back porting.

The concept looks good, and i see you now have a Tested-by:, so with
the fixup applied i think you are good to go. Please add my
Reviewed-by: to the next version.

   Andrew

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2021-12-07 14:59:21

On Tue, Dec 07, 2021 at 03:54:37PM +0100, Andrew Lunn wrote:
On Tue, Dec 07, 2021 at 10:59:19AM +0000, Russell King (Oracle) wrote:
quoted
Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
Hi Russell

It would be good to have a Fixes: tag here, to help with back porting.
Oh, I thought this was a new development, not a regression. Do you have
a pointer to the earlier bits of the thread please, e.g. the message ID
of the original report.

Thanks.
The concept looks good, and i see you now have a Tested-by:, so with
the fixup applied i think you are good to go. Please add my
Reviewed-by: to the next version.
Will do.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: Andrew Lunn <andrew@lunn.ch>
Date: 2021-12-07 15:07:33

On Tue, Dec 07, 2021 at 02:58:26PM +0000, Russell King (Oracle) wrote:
On Tue, Dec 07, 2021 at 03:54:37PM +0100, Andrew Lunn wrote:
quoted
On Tue, Dec 07, 2021 at 10:59:19AM +0000, Russell King (Oracle) wrote:
quoted
Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
Hi Russell

It would be good to have a Fixes: tag here, to help with back porting.
Oh, I thought this was a new development, not a regression. Do you have
a pointer to the earlier bits of the thread please, e.g. the message ID
of the original report.
This all seems to be part of:

b98043f66e8c6f1fd75d11af7b28c55018c58d79.camel@collabora.com

It looks like 5.15-rc3 has issues, but i suspect it goes back further.
I'm also assuming it is a regression, not that it never worked in the
first place. Maybe i'm wrong?

   Andrew

Re: [PATCH RFC net] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2021-12-07 15:28:14

On Tue, Dec 07, 2021 at 04:07:26PM +0100, Andrew Lunn wrote:
On Tue, Dec 07, 2021 at 02:58:26PM +0000, Russell King (Oracle) wrote:
quoted
On Tue, Dec 07, 2021 at 03:54:37PM +0100, Andrew Lunn wrote:
quoted
On Tue, Dec 07, 2021 at 10:59:19AM +0000, Russell King (Oracle) wrote:
quoted
Martyn Welch reports that his CPU port is unable to link where it has
been necessary to use one of the switch ports with an internal PHY for
the CPU port. The reason behind this is the port control register is
left forcing the link down, preventing traffic flow.

This occurs because during initialisation, phylink expects the link to
be down, and DSA forces the link down by synthesising a call to the
DSA drivers phylink_mac_link_down() method, but we don't touch the
forced-link state when we later reconfigure the port.

Resolve this by also unforcing the link state when we are operating in
PHY mode and the PPU is set to poll the PHY to retrieve link status
information.

Reported-by: Martyn Welch <redacted>
Signed-off-by: Russell King (Oracle) <redacted>
Hi Russell

It would be good to have a Fixes: tag here, to help with back porting.
Oh, I thought this was a new development, not a regression. Do you have
a pointer to the earlier bits of the thread please, e.g. the message ID
of the original report.
This all seems to be part of:

b98043f66e8c6f1fd75d11af7b28c55018c58d79.camel@collabora.com

It looks like 5.15-rc3 has issues, but i suspect it goes back further.
I'm also assuming it is a regression, not that it never worked in the
first place. Maybe i'm wrong?
Thanks.

It looks like DT support for this was added in e26dead44268, which is
in v4.16-rc1.

The introduction of the phylink_mac_link_down() in net/dsa/port.c was
in 3be98b2d5fbc, v5.7-rc2, as was the addition of MLO_AN_FIXED in
mv88e6xxx DSA link down/up functions in 34b5e6a33c1a (these are
consecutive commits.)

Thankfully, the addition of mv88e6xxx_port_ppu_updates was in v5.7-rc1.

Now, this patch can't simply be backported without the update to
mv88e6xxx_port_ppu_updates(), so I feel we need to invent a Requires:
or Depends: tag so stable people don't backport this without the other
patch - my recent experience with stable is that patches get picked up
quite randomly.

I think I'd be tempted to go with:

Fixes: 3be98b2d5fbc ("net: dsa: Down cpu/dsa ports phylink will control")

I think we also need:

Cc: <redacted> # v5.7-rc2: xxxxx: net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's"

which seems to be a thing according to stable-kernel-rules.rst...
with the xxxxx replaced with the proper sha1 ID once the dependent
patch has been applied to the net tree.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help