linux-kernel - Re: [PATCH v2 net-next 3/3] net: phy: aquantia: add support for aqr115c

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]

Message-ID: <CAMRc=Mcftb9MRAP50ZNMfQpsjLzc-=OKvxo5Xkeqdgs-rZFNug@mail.gmail.com>
Date: Fri, 28 Jun 2024 14:11:44 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, 
	Russell King <linux@...linux.org.uk>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 net-next 3/3] net: phy: aquantia: add support for aqr115c

On Fri, Jun 28, 2024 at 3:11 AM Daniel Golle <daniel@...rotopia.org> wrote:
>
> On Fri, Jun 28, 2024 at 02:18:45AM +0200, Andrew Lunn wrote:
> > On Thu, Jun 27, 2024 at 11:42:45PM +0100, Daniel Golle wrote:
> > > Hi Bartosz,
> > >
> > > On Thu, Jun 27, 2024 at 01:30:17PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > > >
> > > > Add support for a new model to the Aquantia driver. This PHY supports
> > > > Overlocked SGMII mode with 2.5G speeds.
> > >
> > > I don't think that there is such a thing as "Overclocked SGMII mode with
> > > 2.5G speed".
> >
> > Unfortunately, there is. A number of vendors say they do this, without
> > saying quite what they actually do.  As you point out, symbol
> > replication does not work, and in-band signalling also makes no
> > sense. So they throw all that away. Leaving just the higher clock
> > rate, single speed, and no in-band signalling.
> >
> > In the end, that looks very similar to 2500BaseX with broken inband
> > signalling.
>
> Let's call it that then: "2500Base-X with broken in-band signalling".
>
> MaxLinear describes that quite clearly in their (open!) datasheets[1],
> and gives some insight into the (mis-)use of the term "SGMII" in the
> industry as synonymous to just any type of serialized Ethernet MII:
>
> "
> 3.4 SGMII Interface
>
> The GPY211 implements a serial data interface, called SGMII or SerDes,
> to connect to another chip implementing the MAC layer (MAC SoC).
> "
> (page 32)
>
> Later on they mention that
> "
> 3.4.7 Auto-negotiation Modes Supported by SGMII
>
> Two modes are supported for the SGMII auto-negotiation protocol:
>  * Cisco* Serial-GMII Specification 1.8 [4]
>  * 1000BX IEEE 802.3 following IEEE Clause 37 [2]
> "
> (page 37)
>
> Aquantia's datasheets are only available under NDA, so I cannot quote
> them directly, but I can tell you that their definition of "SGMII" is
> pretty similar to that of MaxLinear.
>

Well, hopefully without breaching the NDA I can tell you that there's
no definition at all. At least not in the ~700 pages doc I have access
to anyway.

> >
> > > Hence I assume that what you meant to say here is that the PHY uses
> > > 2500Base-X as interface mode and performs rate-adaptation for speeds
> > > less than 2500M (or half-duplex) using pause frames.
> >
> > Not all systems assume rate adaptation. Some are known to use SGMII
> > for 10/100/1G with inband signalling, and then swap to 2500BaseX
> > without inband-signalling for 2.5G operation!
>
> Yes, most 2.5G PHYs out there (MaxLinear, RealTek) actually support both,
> with interface-mode switching being the better option compared to often
> rather problematic rate-adaptation...
>
> When it comes to Aquantia we are using 2500Base-X with rate adaptation
> for the older 2.5G PHYs, so I assume the newer ones would not differ in
> that regard. Or rather: If we were to introduce interface-mode-switching
> also for the Aquantia 2.5G PHYs then we should try doing it for all of
> them at least.
>
> >
> > 2.5G is a mess.
>
> +1
>

Not sure what to do, should I still be adding a new mode here or is it
fine to just explain in the commit message that this really is
"2500Base-X-sans-in-band-signalling" and keep the code as is? Or maybe
some quirk disallowing `managed = "in-band-status"`?

Bartosz