linux-kernel - Re: [net-next: PATCH v3 1/6] Documentation: ACPI: DSD: describe additional MAC configuration

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:   Thu, 24 Jun 2021 00:42:18 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Marcin Wojtas <mw@...ihalf.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        linux@...linux.org.uk, jaz@...ihalf.com, gjb@...ihalf.com,
        upstream@...ihalf.com, Samer.El-Haj-Mahmoud@....com,
        jon@...id-run.com, tn@...ihalf.com, rjw@...ysocki.net,
        lenb@...nel.org
Subject: Re: [net-next: PATCH v3 1/6] Documentation: ACPI: DSD: describe
 additional MAC configuration

Hi Andrew,

On Wed, Jun 23, 2021 at 10:18:02PM +0200, Andrew Lunn wrote:
> > +MAC node example with a "fixed-link" subnode.
> > +---------------------------------------------
> > +
> > +.. code-block:: none
> > +
> > +	Scope(\_SB.PP21.ETH1)
> > +	{
> > +	  Name (_DSD, Package () {
> > +	    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > +		 Package () {
> > +		     Package () {"phy-mode", "sgmii"},
> > +		 },
> > +	    ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> > +		 Package () {
> > +		     Package () {"fixed-link", "LNK0"}
> > +		 }
> > +	  })
> 
> At least in the DT world, it is pretty unusual to see both fixed-link
> and phy-mode. You might have one of the four RGMII modes, in order to
> set the delays when connecting to a switch. But sgmii and fixed link
> seems very unlikely, how is sgmii autoneg going to work?

SGMII autoneg is supposed to be disabled if you have a fixed-link, and
there is nothing unusual in that kind of setup.
There are 3 types of phylink setups:

MLO_AN_INBAND: there might or might not be a phy-handle, but SGMII
               autoneg should be enabled and the MAC should be
               reconfigured automatically (in hardware) to the right
               speed/duplex based on that
MLO_AN_PHY: there is a phy-handle but SGMII autoneg should be disabled*
            and the MAC should be reconfigured (forced) in software to
            the speed/duplex determined by reading the PHY MDIO
            registers
MLO_AN_FIXED: there is no phy-handle or phy_device, but the driver
              should do the same thing, the speed/duplex is configured
              by management (in this case DT/ACPI)

*there appears to be some debate here, since the "managed" property is
phylink-specific and therefore a phylib driver will not necessarily
disable its in-band autoneg, but this is what the existing phylink_pcs
drivers in drivers/net/pcs/ do and I think there's nothing wrong with
settling on that if phylink is being used. It does create some interesting
questions though when a driver is being converted from phylib to phylink,
since the meaning of the existing firmware bindings suddenly changes.

An SGMII link with MLO_AN_FIXED is nothing unusual, it is in fact very
widespread as a way to reduce pin count compared to the parallel RGMII.
I suspect there are more DSA setups in the field with an SGMII fixed-link
than with RGMII fixed-link, due to practicality.

The 2 characteristic features of SGMII compared to 1000base-X are:
- customization of the 16-bit configuration word communicated via the
  clause 37 state machines. Those are bypassed in MLO_AN_PHY and
  MLO_AN_FIXED modes, true
- symbol replication at 10/100 speeds.

So since it is equally valid to have an SGMII fixed-link at 100Mbps or
10Mbps, it is just as valid to have an SGMII fixed-link at 1Gbps with
in-band autoneg disabled.