On Wed, Apr 22, 2009 at 4:21 AM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Mon, 2009-04-20 at 20:10 -0400, Kyle Moffett wrote: >> > IIRC, Ben had some issues with how phylib and the EMAC would need to >> > interact. Not sure if he has those written down somewhere or not. >> > (CC'd). >> >> Hmm, yeah, I'd be interested to see those. There's enough similar >> between phylib and the EMAC and sungem drivers that I'm considering a >> series of somewhat-mechanical patches to make EMAC and sungem use the >> "struct phy_device" and "struct mii_bus" from phylib, possibly >> abstracting out some helper functions along the way. > > Yup, emac and sungem predate phylib. > > I had a quick look at what it would take to port at least emac over, the > main issue was that I want to be able to sleep (ie, take a mutex) in my > mdio read/write functions, and back then, phylib wouldn't let me do that > due to spinlock and timer/softirq usage.
Ok, I've made some progress in the port, but right now I'm trying to puzzle out what the "gpcs" bits in the code are. From the few publicly available docs and some mailing list posts, the gpcs address appears to be some kind of integrated virtual PHY used when 460GT-ish chips are communicating via an SGMII bus. My current plan of action is to separate the "gpcs" out into a separate PHY device controlled by the emac code. I'm also curious about the intent of the "mdio_instance" pointer (IE: the "mdio-device" property). Is that used when all the PHY devices are attached to the MDIO bus of only one of the (multiple) emac devices? Or is that for when two emac chipsets are connected to the same MDIO bus wire? (or both?) What keeps the emac_instance pointed to by the "mdio_instance" from going away while the other emac chipset is using it? In either case, I plan to have the device actually holding the MDIO bus run the mdiobus_alloc() and mdiobus_register() functions, then the other emac instance will simply take a reference to that MDIO bus (which would also pin down the emac instance that owns it). Cheers, Kyle Moffett _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev