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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 Feb 2014 08:50:26 -0600
From:	Rob Herring <>
To:	Gerlando Falauto <>
Cc:	"" <>,
	"" <>,
	Grant Likely <>,
	Sebastian Hesselbarth <>,
	"Brunck, Holger" <>
Subject: Re: Disabling autoneg and enforcing speed/duplex

On Thu, Feb 6, 2014 at 6:00 AM, Gerlando Falauto
<> wrote:
> 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).

You shouldn't need a property in this case. The driver knows what the
h/w is limited to and can configure the phy based on that. It is when
both sides should support a higher speed and you need to limit it for
some other reason like errata or board level configuration.

> Or perhaps I'm missing some important bits here?

Does this patch help you:


> Thanks!
> Gerlando
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to
> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists