netdev - Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Apr 2009 11:04:22 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	netdev <netdev@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	linuxppc-dev@...abs.org
Subject: Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC 
	questions)

On Wed, Apr 22, 2009 at 4:21 AM, Benjamin Herrenschmidt
<benh@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html