2014-12-18 19:49 GMT-08:00 Lennart Sorensen <lsore...@csclub.uwaterloo.ca>: > I have been trying to move an 8360 based system from a 3.0 kernel to a > 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an > oops in the ucc_geth driver when using RTBI mode on one of the ucc > ports. I haven't managed to find any commits to of_mdio or ucc_geth or > fsl_pq_mdio that would appear to address this problem, so I believe it > is still present in the latest kernel, but have not confirmed that with > testing yet. > > Commit 058112c7efc9ef43bb511c137293dddbe6e42908 appears to have broken > ucc support for tbi phy detection. > > With the patch in place, I am unable to get the mdio bus to create phy > devices for the tbi phy in the ucc on an 8360e, and the ucc_geth driver > causes a kernel oops, while with the patch reverted, it does create them > and the driver comes up and works. > > The tbi phy is needed when using a ucc in RTBI, TBI or SGMII mode. > > I am not convinced that the tbi phy really behaves quite like a real phy, > which may be why get_phy_device does not work with it. Perhaps there > is a better way to deal with the tbi phy on the ucc for this purpose.
There are some comments in ucc_geth that also lead me to believe this is a just a hack instead of a real Ethernet PHY device. Part of what I think got broken is because of this comment: /* Initialize TBI PHY interface for communicating with the * SERDES lynx PHY on the chip. We communicate with this PHY * through the MDIO bus on each controller, treating it as a * "normal" PHY at the address found in the UTBIPA register. We assume * that the UTBIPA register is valid. Either the MDIO bus code will set * it to a value that doesn't conflict with other PHYs on the bus, or the * value doesn't matter, as there are no other PHYs on the bus. */ In particular this one: "Either the MDIO bus code will set * it to a value that doesn't conflict with other PHYs on the bus, or the * value doesn't matter, as there are no other PHYs on the bus." and what Sebastian removed did exactly that, we used the special MDIO broadcast address 0 to provide this "whatever". If this is such a requirement from the ucc_geth driver and TBI PHYs, maybe we should have this hack somewhere in the actual MDIO driver used by the ucc_geth driver instead, or set a flag/read the PHY connection mode and do this in drivers/of/of_mdio.c > > Certainly as it is, this patch has caused a regression though, although > probably not very many systems with ucc ports actually use one of the > affected modes so the damage isn't that great. > > -- > Len Sorensen -- Florian _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
