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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 5 Sep 2020 09:04:59 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Paul Barker <pbarker@...sulko.com>, Andrew Lunn <andrew@...n.ch>
Cc:     Woojung Huh <woojung.huh@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Vivien Didelot <vivien.didelot@...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 9/5/2020 8:53 AM, 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.

The RGMII 2.0 specification, pages 7 and 8 has more details:

http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf

and section 3.4.1 indicates that this is optional anyway for link 
status/speed/duplex.

It comes down to putting a appropriate data word on RXD[7:0] to signal 
link status, speed and speed, if the link partner does not provide the 
inter-frame word, then the receiver cannot reconstruct that information, 
or it will incorrectly decode it.

> 
> I don't really know much about how this is implemented or how widely
> it's supported.

It is supported by the Broadcom GENET adapter and probably a few others, 
however for the same reasons, I have not seen it being widely used. You 
would save two reads of BMSR to determine the link status which is nice, 
but link parameter changes are disruptive anyway.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ