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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 5 Sep 2020 18:06:47 +0200
From:   Andrew Lunn <>
To:     Paul Barker <>
Cc:     Woojung Huh <>,
        Microchip Linux Driver Support <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        "David S . Miller" <>,
Subject: Re: [PATCH 3/4] net: dsa: microchip: Disable RGMII in-band status on

On Sat, Sep 05, 2020 at 04:53:20PM +0100, Paul Barker wrote:
> On Sat, 5 Sep 2020 at 16:32, Andrew Lunn <> 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
> (
> 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:

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


Powered by blists - more mailing lists