Re: [PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327
Michał Kępień <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
> > 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. Understood. Is it a long-standing issue for the QCA mgmt Ethernet code in general or for a specific subset of switches (or devices)? > 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? This thread? https://lore.kernel.org/netdev/[email protected]/ If so, that was for QCA8337, on a board where the external MDIO bus has an extra PHY attached, so it did not look like a match for my case. Of course, it _might_ be related to the issue I'm running into, it just did not seem to be at first glance. > 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. Ack. > Also as Andrew said I would still save this for the MIB part as the 2 thing > should be unrelated. Got it, I'll play around with it and see what I can find out, thanks. -- Best regards, Michał Kępień