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
| ||
|
Date: Sat, 5 Sep 2020 18:06:47 +0200 From: Andrew Lunn <andrew@...n.ch> To: Paul Barker <pbarker@...sulko.com> Cc: Woojung Huh <woojung.huh@...rochip.com>, Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: [PATCH 3/4] net: dsa: microchip: Disable RGMII in-band status on KSZ9893 On Sat, Sep 05, 2020 at 04:53:20PM +0100, Paul Barker wrote: > On Sat, 5 Sep 2020 at 16:32, Andrew Lunn <andrew@...n.ch> wrote: > > > > On Sat, Sep 05, 2020 at 03:03:24PM +0100, Paul Barker wrote: > > > We can't assume that the link partner supports the in-band status > > > reporting which is enabled by default on the KSZ9893 when using RGMII > > > for the upstream port. > > > > What do you mean by RGMII inband status reporting? SGMII/1000BaseX has > > in band signalling, but RGMII? > > > > Andrew > > I'm referencing page 56 of the KSZ9893 datasheet > (http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9893R-Data-Sheet-DS00002420D.pdf). > The datasheet says "The RGMII port will not function properly if IBS > is enabled in the switch, but it is not receiving in-band status from > a connected PHY." Since we can't guarantee all possible link partners > will support this it should be disabled. In particular, the IMX6 SoC > we're using with this switch doesn't support this on its Ethernet > port. > > I don't really know much about how this is implemented or how widely > it's supported. I never knew RGMII had this. What i did find was: http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf which does talk about it, section 3.4.1. It is clearly optional, and since this is the first time i've heard of it, i suspect not many systems actually implement it. So turning it off seems wise. Reviewed-by: Andrew Lunn <andrew@...n.ch> Andrew
Powered by blists - more mailing lists