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

Powered by blists - more mailing lists