summaryrefslogtreecommitdiff
path: root/lib/bootconfig.c
diff options
context:
space:
mode:
authorRussell King <rmk+kernel@armlinux.org.uk>2020-06-30 16:31:28 +0100
committerRussell King <rmk+kernel@armlinux.org.uk>2020-09-02 10:01:28 +0100
commitf31e4694ea7170f64061d276451b0a902f6458bb (patch)
tree9f01bc287d10ad2d312d66de4189625278fa365d /lib/bootconfig.c
parenta727306763b30a83b1afdc55b2155e99384bb10b (diff)
phy: armada-38x: fix NETA lockup when repeatedly switching speeds
The mvneta hardware appears to lock up in various random ways when repeatedly switching speeds between 1G and 2.5G, which involves reprogramming the COMPHY. It is not entirely clear why this happens, but best guess is that reprogramming the COMPHY glitches mvneta clocks causing the hardware to fail. It seems that rebooting resolves the failure, but not down/up cycling the interface alone. Various other approaches have been tried, such as trying to cleanly power down the COMPHY and then take it back through the power up initialisation, but this does not seem to help. It was finally noticed that u-boot's last step when configuring a COMPHY for "SGMII" mode was to poke at a register described as "GBE_CONFIGURATION_REG", which is undocumented in any external documentation. All that we have is the fact that u-boot sets a bit corresponding to the "SGMII" lane at the end of COMPHY initialisation. Experimentation shows that if we clear this bit prior to changing the speed, and then set it afterwards, mvneta does not suffer this problem on the SolidRun Clearfog when switching speeds between 1G and 2.5G. This problem was found while script-testing phylink. This fix also requires the corresponding change to DT to be effective. See "ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speeds". Fixes: 14dc100b4411 ("phy: armada38x: add common phy support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Diffstat (limited to 'lib/bootconfig.c')
0 files changed, 0 insertions, 0 deletions