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]

Message-Id: <1241126291.29501.41.camel@pasglop>
Date:	Fri, 01 May 2009 07:18:11 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Kyle Moffett <kyle@...fetthome.net>
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)

> 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.

Well... GPCS is indeed some kind of internal PHY if you like but it's
not MDIO controlled and I don't really see a need to move it to the
phylib as it's so specific to the NIC itself. But if you think it cleans
the code up significantly... There are also some subtle differences in
how the NIC is programmed when using GPCS vs. xMII

> 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? 

It's common especially on older SoCs using EMAC to have only one of
the EMAC instance with an MDIO bus for configuring the PHYs. This is one
of the reasons why I have the mutex in the low level MDIO access
routines since 2 EMACs can try to talk to the same MDIO, and this is the
problem I had with phylib back then which was doing everything in atomic
contexts.

> What keeps the emac_instance pointed
> to by the "mdio_instance" from going away while the other emac chipset
> is using it?

Nothing other than those are all in a SoC and so generally don't do
hotplug, but I suppose that with things like kvm which could potentially
hotplug devices between partitions, one would have to get a bit more
careful.

> 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).

Sounds good at first.

Cheers,
Ben.

--
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