netdev - Disabling autoneg and enforcing speed/duplex

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-next>] [day] [month] [year] [list]

Date:	Thu, 06 Feb 2014 13:00:43 +0100
From:	Gerlando Falauto <gerlando.falauto@...mile.com>
To:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	"Brunck, Holger" <Holger.Brunck@...mile.com>,
	Florian Fainelli <f.fainelli@...il.com>
Subject: Disabling autoneg and enforcing speed/duplex

Hi,

I'm using the Kirkwood Ethernet controller (mv643xx_eth.c) with a 
Marvell 88E3018 PHY which needs to be set in forced 100Base-TX mode.

Thanks to Sebastian's addition of DT support to the ethernet driver, I 
can easily set speed and duplex within the ethernet's port node, 
therefore leaving the phy unmanaged -- this works fine (I guess this 
mode is set on the phy by the bootloader or by strap settings).

However, this PHY has an erratum whose workaround requires some 
registers be written -- I believe the natural solution would be to start 
managing the PHY (i.e. set "phy-handle") and implement the proper 
workaround within drivers/net/phy/marvell.c. Making the PHY managed does 
however enable autoneg and therefore break everything.

Which brings me to my question: shouldn't there be a way to specify some 
forced settings within the PHY's node for such cases?

Only thing I found vaguely resembling what I'm looking for is Florian's 
patch introducing "max-speed" in the PHY -- not quite the same thing 
though. Which, if I understand it correctly, implements it as a property 
of the PHY, whereas ePAPR specifies it as a property of the ethernet 
device (which makes sense, since you might want to connect a 10/100 MII 
to a 10/100/1000 PHY and therefore have the MII restrict the 
capabilities of the PHY).

Or perhaps I'm missing some important bits here?

Thanks!
Gerlando
--
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