On Sat, Jul 18, 2009 at 12:04 PM, Anton Vorontsov<avoront...@ru.mvista.com> wrote: > On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote: > [...] >> 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. > > Yep. With a bit of phylib rework we can remove all the MDIO emulation > stuff from phy/fixed.c driver, and leave there just speed/duplex/pause > assignments. > > Though, I still believe that we should avoid two code paths in the > drivers. One of the code paths will be constantly broken if we do so.
Yes, I agree. Splitting the concepts also has the added advantage that non-phy devices will have an interface to manipulate the link speed without modifying drivers. >> 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. > > Works fine here, thanks! Awesome. Dave, can you please pick up this series? Thanks, 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
