[PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327

[PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327

[Michał Kępień]

While the qca8327 switch appears to support in-band mgmt Ethernet,
prolonged use of that protocol (e.g. for polling link state) makes the
device unstable: within minutes, ports randomly go down and no traffic
is forwarded anymore.  The same issues do not occur when MDIO is used
exclusively, so ensure mgmt Ethernet is not used on the qca8327.

Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
I came across this while migrating an AR9344-based router with a QCA8327
rev. 4 switch to a DSA-aware driver.  This glitch is a pain in the neck
to troubleshoot any further as it occurs randomly, anywhere between a
minute to an hour after the switch is set up; traffic load exerted on
the switch does not seem to matter as the problem can be triggered on a
virtually idle device.  Previously working links are reported as going
down (one by one, not all at once), even though port LEDs still blink;
no traffic is forwarded; reloading qca8k does not alleviate the problem,
only power cycling seems to help.  Nothing like this happens when only
MDIO is used.  However, qca8k currently only uses MDIO as a fallback.  I
figured that simpler is better and that mgmt Ethernet should simply be
disabled for the qca8327, but I would be happy to work on some
configurable solution if that would be preferable.

 drivers/net/dsa/qca/qca8k-8xxx.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/dsa/qca/qca8k-8xxx.c b/drivers/net/dsa/qca/qca8k-8xxx.c
index 4c928983b8623..1d90a23aba6bb 100644
--- a/drivers/net/dsa/qca/qca8k-8xxx.c
+++ b/drivers/net/dsa/qca/qca8k-8xxx.c
@@ -160,6 +160,11 @@ qca8k_set_page(struct qca8k_priv *priv, u16 page)
 	return 0;
 }
 
+static bool qca8k_mgmt_eth_disabled(const struct qca8k_priv *priv)
+{
+	return priv->switch_id == QCA8K_ID_QCA8327;
+}
+
 static void qca8k_rw_reg_ack_handler(struct dsa_switch *ds, struct sk_buff *skb)
 {
 	struct qca8k_mgmt_eth_data *mgmt_eth_data;
@@ -316,6 +321,9 @@ static int qca8k_read_eth(struct qca8k_priv *priv, u32 reg, u32 *val, int len)
 	bool ack;
 	int ret;
 
+	if (qca8k_mgmt_eth_disabled(priv))
+		return -ENXIO;
+
 	skb = qca8k_alloc_mdio_header(MDIO_READ, reg, NULL,
 				      QCA8K_ETHERNET_MDIO_PRIORITY, len);
 	if (!skb)
@@ -368,6 +376,9 @@ static int qca8k_write_eth(struct qca8k_priv *priv, u32 reg, u32 *val, int len)
 	bool ack;
 	int ret;
 
+	if (qca8k_mgmt_eth_disabled(priv))
+		return -ENXIO;
+
 	skb = qca8k_alloc_mdio_header(MDIO_WRITE, reg, val,
 				      QCA8K_ETHERNET_MDIO_PRIORITY, len);
 	if (!skb)
@@ -630,6 +641,9 @@ qca8k_phy_eth_command(struct qca8k_priv *priv, bool read, int phy,
 	int ret, ret1;
 	bool ack;
 
+	if (qca8k_mgmt_eth_disabled(priv))
+		return -ENXIO;
+
 	if (regnum >= QCA8K_MDIO_MASTER_MAX_REG)
 		return -EINVAL;
 
-- 
2.55.0

Re: [PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327

[Andrew Lunn]

On Mon, Aug 10, 2026 at 08:15:53AM +0200, Michał Kępień wrote:
> While the qca8327 switch appears to support in-band mgmt Ethernet,
> prolonged use of that protocol (e.g. for polling link state) makes the
> device unstable: within minutes, ports randomly go down and no traffic
> is forwarded anymore.  The same issues do not occur when MDIO is used
> exclusively, so ensure mgmt Ethernet is not used on the qca8327.

Do you have time to narrow down the cause?

I _think_ in band management is used for a few different
things. e.g. statistics, as you said, PHY polling etc. Rather than
turning everything off, could you try just doing PHY polling via MDIO,
but statistics via ethernet, and do an ethtool -S every so often to
see if you can trigger the problem.

Could you also check if the management packets are getting lost? Look
at the results from wait_for_completion_timeout(), is it timing out?
If so, is the retry mechanism working? When i added the Marvell
equivalent for in-band signalling i got the retry mechanism wrong, but
never noticed because i was not loosing packets.

Thanks
	Andrew

Re: [PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327

[Christian Marangi]

On Mon, Aug 10, 2026 at 08:15:53AM +0200, Michał Kępień wrote:
> While the qca8327 switch appears to support in-band mgmt Ethernet,
> prolonged use of that protocol (e.g. for polling link state) makes the
> device unstable: within minutes, ports randomly go down and no traffic
> is forwarded anymore.  The same issues do not occur when MDIO is used
> exclusively, so ensure mgmt Ethernet is not used on the qca8327.
> 
> Signed-off-by: Michał Kępień <kernel@kempniu.pl>
> ---
> I came across this while migrating an AR9344-based router with a QCA8327
> rev. 4 switch to a DSA-aware driver.  This glitch is a pain in the neck
> to troubleshoot any further as it occurs randomly, anywhere between a
> minute to an hour after the switch is set up; traffic load exerted on
> the switch does not seem to matter as the problem can be triggered on a
> virtually idle device.  Previously working links are reported as going
> down (one by one, not all at once), even though port LEDs still blink;
> no traffic is forwarded; reloading qca8k does not alleviate the problem,
> only power cycling seems to help.  Nothing like this happens when only
> MDIO is used.  However, qca8k currently only uses MDIO as a fallback.  I
> figured that simpler is better and that mgmt Ethernet should simply be
> disabled for the qca8327, but I would be happy to work on some
> configurable solution if that would be preferable.
>

This is a long standing issue and it seems to me disabling mgmt is just a
big workaround to a real problem.

Long time ago it was reported that there seems to be a problem with the
mdio master register for external and internall access and how mgmt was
actually sending mdio command... just done by the switch. Could the 2 issue
related?

One idea might be to verify that stuff gets actually written... as Andrew
said to verify if some packets doesn't get lost or just ignored.

Also as Andrew said I would still save this for the MIB part as the 2 thing
should be unrelated.
 
>  drivers/net/dsa/qca/qca8k-8xxx.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/dsa/qca/qca8k-8xxx.c b/drivers/net/dsa/qca/qca8k-8xxx.c
> index 4c928983b8623..1d90a23aba6bb 100644
> --- a/drivers/net/dsa/qca/qca8k-8xxx.c
> +++ b/drivers/net/dsa/qca/qca8k-8xxx.c
> @@ -160,6 +160,11 @@ qca8k_set_page(struct qca8k_priv *priv, u16 page)
>  	return 0;
>  }
>  
> +static bool qca8k_mgmt_eth_disabled(const struct qca8k_priv *priv)
> +{
> +	return priv->switch_id == QCA8K_ID_QCA8327;
> +}
> +

Instead of this and return ENXIO I would just not install the relevant OPs
for the tagger and use the mdio path directly...

Makes the code cleaner and less CPU cycle (the target is ath79 and powerpc
stuff)

But as said above disabling the feature is the last solution after all the
verification are done.

>  static void qca8k_rw_reg_ack_handler(struct dsa_switch *ds, struct sk_buff *skb)
>  {
>  	struct qca8k_mgmt_eth_data *mgmt_eth_data;
> @@ -316,6 +321,9 @@ static int qca8k_read_eth(struct qca8k_priv *priv, u32 reg, u32 *val, int len)
>  	bool ack;
>  	int ret;
>  
> +	if (qca8k_mgmt_eth_disabled(priv))
> +		return -ENXIO;
> +
>  	skb = qca8k_alloc_mdio_header(MDIO_READ, reg, NULL,
>  				      QCA8K_ETHERNET_MDIO_PRIORITY, len);
>  	if (!skb)
> @@ -368,6 +376,9 @@ static int qca8k_write_eth(struct qca8k_priv *priv, u32 reg, u32 *val, int len)
>  	bool ack;
>  	int ret;
>  
> +	if (qca8k_mgmt_eth_disabled(priv))
> +		return -ENXIO;
> +
>  	skb = qca8k_alloc_mdio_header(MDIO_WRITE, reg, val,
>  				      QCA8K_ETHERNET_MDIO_PRIORITY, len);
>  	if (!skb)
> @@ -630,6 +641,9 @@ qca8k_phy_eth_command(struct qca8k_priv *priv, bool read, int phy,
>  	int ret, ret1;
>  	bool ack;
>  
> +	if (qca8k_mgmt_eth_disabled(priv))
> +		return -ENXIO;
> +
>  	if (regnum >= QCA8K_MDIO_MASTER_MAX_REG)
>  		return -EINVAL;
>  
> -- 
> 2.55.0
> 

-- 
	Ansuel