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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YE6zrUufDhOp31SJ@lunn.ch>
Date:   Mon, 15 Mar 2021 02:09:01 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Robert Hancock <robert.hancock@...ian.com>
Cc:     "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "claudiu.beznea@...rochip.com" <claudiu.beznea@...rochip.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>
Subject: Re: [PATCH net-next 2/2] net: macb: Disable PCS auto-negotiation for
 SGMII fixed-link mode

On Sun, Mar 14, 2021 at 11:22:03PM +0000, Robert Hancock wrote:
> On Sat, 2021-03-13 at 02:45 +0100, Andrew Lunn wrote:
> > On Thu, Mar 11, 2021 at 02:18:13PM -0600, Robert Hancock wrote:
> > > When using a fixed-link configuration in SGMII mode, it's not really
> > > sensible to have auto-negotiation enabled since the link settings are
> > > fixed by definition. In other configurations, such as an SGMII
> > > connection to a PHY, it should generally be enabled.
> > 
> > So how do you tell the PCS it should be doing 10Mbps over the SGMII
> > link? I'm assuming it is the PCS which does the bit replication, not
> > the MAC?
> 
> I'm not sure if this is the same for all devices using this Cadence IP, but the
> register documentation I have for the Xilinx UltraScale+ MPSoC we are using
> indicates this PCS is only capable of 1000 Mbps speeds:
> 
> https://www.xilinx.com/html_docs/registers/ug1087/gem___pcs_control.html
> 
> So it doesn't actually seem applicable in this case.
> 
> > 
> > I'm surprised you are even using SGMII with a fixed link. 1000BaseX is
> > the norm, and then you don't need to worry about the speed.
> > 
> 
> That would be a bit simpler, yes - but it seems like this hardware is set up
> more for SGMII mode - it's not entirely clear to me that 1000BaseX is supported
> in the hardware, and it's not currently supported in the driver that I can see.

This hardware just seems odd. If it was not for the fact the
documentation say SGMII all over the place, i would be temped to say
it is actually doing 1000BaseX.

Assuming the documentation is not totally wrong, your code seems
sensible for the hardware.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ