For a kernel that is being kexec'd we re-enable the integrated GPHY in
order for the subsequent MDIO bus scan to succeed and properly bind to
the bcm7xxx PHY driver. If we did not do that, the GPHY would be shut
down by the time the MDIO driver is probing the bus, and it would fail
to read the correct PHY OUI and therefore bind to an appropriate PHY
driver. Later on, this would cause DSA not to be able to successfully
attach to the PHY, and the interface would not be created at all.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
@@ -1133,6 +1134,18 @@ static int bcm_sf2_sw_remove(struct platform_device *pdev)return0;}+staticvoidbcm_sf2_sw_shutdown(structplatform_device*pdev)+{+structbcm_sf2_priv*priv=platform_get_drvdata(pdev);++/* For a kernel about to be kexec'd we want to keep the GPHY on for a+*successfulMDIObusscantooccur.IfwedidturnofftheGPHY+*before(e.g:port_disable),thiswillalsopoweritbackon.+*/+if(priv->hw_params.num_gphy==1)+bcm_sf2_gphy_enable_set(priv->dev->ds,kexec_in_progress);+}+#ifdef CONFIG_PM_SLEEPstaticintbcm_sf2_suspend(structdevice*dev){
For a kernel that is being kexec'd we re-enable the integrated GPHY in
order for the subsequent MDIO bus scan to succeed and properly bind to
the bcm7xxx PHY driver. If we did not do that, the GPHY would be shut
down by the time the MDIO driver is probing the bus, and it would fail
to read the correct PHY OUI and therefore bind to an appropriate PHY
driver. Later on, this would cause DSA not to be able to successfully
attach to the PHY, and the interface would not be created at all.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, but I have to wonder...
If enabling the GPHY is necessary for proper probing, why isn't the
kexec kernel enabling it properly?
For a kernel that is being kexec'd we re-enable the integrated GPHY in
order for the subsequent MDIO bus scan to succeed and properly bind to
the bcm7xxx PHY driver. If we did not do that, the GPHY would be shut
down by the time the MDIO driver is probing the bus, and it would fail
to read the correct PHY OUI and therefore bind to an appropriate PHY
driver. Later on, this would cause DSA not to be able to successfully
attach to the PHY, and the interface would not be created at all.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, but I have to wonder...
If enabling the GPHY is necessary for proper probing, why isn't the
kexec kernel enabling it properly?
The GPHY enable control is unfortunately located in the switch register
block space and is dependent upon the switch port to be
enabled/accessible, which the DSA layer won't create if the GPHY is not
successfully probed and bound to a PHY driver. It did not appear that
probe deferral could help solve that problem, since MDIO and switch are
reasonable independent from each other.
This was the easiest way I could come up with, without requiring DT
changes and references to register blocks that are not quite relevant to
each other.
HTH
--
Florian