linux-kernel - 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: <MN2PR11MB3566A463C897A7967F4FCB09EC872@MN2PR11MB3566.namprd11.prod.outlook.com>
Date: Wed, 14 Aug 2024 22:30:07 +0000
From: <Tristram.Ha@...rochip.com>
To: <andrew@...n.ch>
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.

I do not think the KSZ9477 switch design allows I2C access to the SFP
EEPROM.  The SGMII module provides only 2 registers that work like PHY's
MMD operation to access vendor-specific registers.  One of such
registers controls how the module communicates with the SFP so that it
works with either 1000Base-T/SX/LX fiber-like SFP or 10/100/1000Base-T
copper SFP.

Actually the default setting works with 10/100/1000Base-T copper SFP
without any programming.  That register needs to be changed when
1000Base-T/SX/LX fiber SFP is used.

I will see if those vendor-specific registers contain the SFP EEPROM,
but I do not know how the sfp_bus structure allows mapping the register
access to probe for those information.