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
| ||
|
Date: Thu, 6 Feb 2014 08:50:26 -0600 From: Rob Herring <robherring2@...il.com> To: Gerlando Falauto <gerlando.falauto@...mile.com> Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Grant Likely <grant.likely@...retlab.ca>, Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>, "Brunck, Holger" <Holger.Brunck@...mile.com> Subject: Re: Disabling autoneg and enforcing speed/duplex On Thu, Feb 6, 2014 at 6:00 AM, Gerlando Falauto <gerlando.falauto@...mile.com> 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: https://lkml.org/lkml/2014/1/15/533 Rob > > Thanks! > Gerlando > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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