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 18:21:18 -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 Thu, Apr 30, 2009 at 5:18 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
> 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

Ok, thanks, that's helpful information.  Mainly I was trying to puzzle
out why the driver sometimes resets the GPCS and other times resets
the real PHY.  It seems to be rather inconsistent when it resets
different devices.  For instance, one of the Marvell PHY's init()
helper resets the PHY, which was getting in the way of me ensuring
that the init() helpers are called after every PHY reset (because I
need to reinitialize the state that just got erased by the reset).

The challenge is working out which of the implicit ordering is
required for correct operation and which is simply an artifact of the
current implementation.

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

Ok, good, the current mdiobus code seems to make handling this a good
deal easier.

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

Yeah, I was experimenting with fiddling with the bind/unbind files in
sysfs and determined that the device-removal code is completely
broken.  As far as I can tell, any attempts to unregister one of the
emac devices cause an OOPS, even if it isn't used by another emac for
MDIO.  I may just start by nuking the broken device-removal code
entirely, and re-implement it properly once the rework is done.

Thanks for the info!

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