netdev - Re: [PATCH net-next 1/4] dt-bindings: net: dsa: microchip: add SGMII port support to KSZ9477 switch

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: <9b960383-6f6c-4a8c-85bb-5ccba96abb01@lunn.ch>
Date: Wed, 14 Aug 2024 15:50:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Tristram.Ha@...rochip.com
Cc: Woojung.Huh@...rochip.com, UNGLinuxDriver@...rochip.com,
	devicetree@...r.kernel.org, f.fainelli@...il.com, olteanv@...il.com,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, marex@...x.de, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: dsa: microchip: add SGMII
 port support to KSZ9477 switch

On Tue, Aug 13, 2024 at 10:17:03PM +0000, Tristram.Ha@...rochip.com wrote:
> > > > > From: Tristram Ha <tristram.ha@...rochip.com>
> > > > >
> > > > > The SGMII module of KSZ9477 switch can be setup in 3 ways: 0 for direct
> > > > > connect, 1 for 1000BaseT SFP, and 2 for 10/100/1000 SFP.
> > > > >
> > > > > SFP is typically used so the default is 1.  The driver can detect
> > > > > 10/100/1000 SFP and change the mode to 2.  For direct connect this mode
> > > > > has to be explicitly set to 0 as driver cannot detect that
> > > > > configuration.
> > > >
> > > > Could you explain this in more detail. Other SGMII blocks don't need
> > > > this. Why is this block special?
> > > >
> > > > Has this anything to do with in-band signalling?
> > >
> > > There are 2 ways to program the hardware registers so that the SGMII
> > > module can communicate with either 1000Base-T/LX/SX SFP or
> > > 10/100/1000Base-T SFP.  When a SFP is plugged in the driver can try to
> > > detect which type and if it thinks 10/100/1000Base-T SFP is used it
> > > changes the mode to 2 and program appropriately.
> > 
> > What should happen here is that phylink will read the SFP EEPROM and
> > determine what mode should be used. It will then tell the MAC or PCS
> > how to configure itself, 1000BaseX, or SGMII. Look at the
> > mac_link_up() callback, parameter interface.
>  
> I am not sure the module can retrieve SFP EEPROM information.

The board should be designed such that the I2C bus pins of the SFP
cage are connected to an I2C controller. There are also a few pins
which ideally should be connected to GPIOs, LOS, Tx disable etc. You
can then put a node in DT describing the SFP cage:

Documentation/devicetree/bindings/net/sff,sfp.yaml

    sfp2: sfp {
      compatible = "sff,sfp";
      i2c-bus = <&sfp_i2c>;
      los-gpios = <&cps_gpio1 28 GPIO_ACTIVE_HIGH>;
      mod-def0-gpios = <&cps_gpio1 27 GPIO_ACTIVE_LOW>;
      pinctrl-names = "default";
      pinctrl-0 = <&cps_sfpp0_pins>;
      tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>;
      tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>;
    };

and then the ethernet node has a link to it:

    ethernet {
      phy-names = "comphy";
      phys = <&cps_comphy5 0>;
      sfp = <&sfp1>;
    };

Phylink will then driver the SFP and tell the MAC what to do.

	Andrew