On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote: > Given the current code, you cannot. Now we understand the > requirements, we can come up with some ideas how to do this properly.
Okay, I've been a little quiet because of sorting out the ARM tree for merging with Linus (now done) and I've been working on a solution to this problem. The good news is, I have an implementation in phylink to use the sync status reported from a PCS, and to appropriately enable sync status reporting. I'm quite nervous about having that enabled as a matter of routine as I've seen some Marvell hardware end up with interrupt storms from it - presumably due to noise pickup on the serdes lines being interpreted as an intermittently valid signal. I have mvneta using it, and partially tested on the SolidRun Clearfog platform; for testing, I've stripped out everything for the SFP and replaced it with a fixed link - that way, I can control whether the serdes is in sync or not. It isn't mainline quality as I need to work out how to properly handle the MVNETA_INTR_MISC_MASK which looks to me like it's needlessly written in multiple places in the driver. I have a partial implementation on mvpp2, but not complete yet, that is to come - it will need mvpp2 converted to the new phylink pcs_ops which has yet to happen, and may take a bit of time to sort. So, some progress towards a solution, but not to the point where I'd be happy to post some patches just yet. However, I think we need to think about: 1) how we classify Thomas' problem - does it count as a regression given that support for his platform is not part of mainline, and the use of in-band-status in his unreviewed DT is clearly incorrect? 2) if we deem it to be a regression, then how do we intend to solve this for stable kernels? 3) re-enabling AN bypass for mvpp2 would create inconsistencies between different drivers for similar hardware from the same manufacturer, so should we propagate the "fix" to them as well (e.g. mvneta.) 4) what about when we have a proper solution to this, what do we then do with mvpp2 if we decide to change it's behaviour, and do we then recommend that Thomas switches to using this (I suppose so, otherwise there's not much point me developing a solution to this problem.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
