This series is based on the "Net: Revive fixed link support" series posted by Anton Vorontsov on June 26.
On June 26, Anton Vorontsov wrote: > The fixed link support is broken since The Big OF MDIO Rework, > the rework simply removed most of the code that was needed for > fixed links. > > Too bad I didn't notice this earlier, I saw a bunch of patches > on the ml, but unfortunately I didn't look very close presuming > that Grant knew what he was doing. :-) And obviously I didn't > test linux-next on anything that requires a fixed link. > > Anyway, here are four patches. The first one adds the fixed link > support to a framework, otherwise we'd duplicate the code across > the drivers (as we did previously), and I tried to keep drivers' > changes minimal. I took issue with the approach on the basis of a) I find the whole dummy phy approach to be a hack and an abuse of the mdio bus, b) Handling the lack of a phy is trivial and should just be done within the MAC driver itself, and c) the approach caused all drivers using of_phy_connect() to parse the 'fixed-link' property, when only three drivers actually define and use it. I wrote and posted a competing patch which removed the usage of a dummy phy and made each driver handle the lack of a phy gracefully. However, Anton rightly pointed out that my patch still leaves the regression of userspace no longer being able to use ethtool to query the link speed because the affected drivers all depend on phylib for the ethtool ioctl implementations. Part of the problem I think is that the phylib code merges two separate constructs; the construct of an MDIO bus (on which many device may reside, not all of them PHYs), and the construct of an MII link whose speed and configuration need to be manipulated. I've run into problems myself on how best to handle things like Ethernet switches which definitely do not behave like PHYs and the phylib state machine cannot be used on them. It seems to me that the whole 'dummy phy' approach is just an artifact of the phylib model not being quite right yet. I want to investigate the possibility of separating the two concepts, but that will require a fair bit of thought and experimentation. Right now this is a regression situation during the 2.6.31 stabilization, so I don't think it is appropriate to write a new set of ioctl handlers at this late stage when there is another solution. I've reworked Anton's patches to constrain the effects to just the three drivers which use 'fixed-link'. It kills me to leave the dummy phy approach in place, but the alternative is to invasive and risky to apply at this stage. It irks me to say so, but I think Anton's approach of reenabling the dummy phy is the right think to do, Anton, once again I don't have hardware to test this, so I rely on you to tell be if I screwed it up. It has been compile tested. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
