linux-kernel - RE: [PATCH net-next v2] 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:
 <DM3PR11MB87361CADB3A3A26772B11EEEEC1B2@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Fri, 17 Jan 2025 00:56:14 +0000
From: <Tristram.Ha@...rochip.com>
To: <maxime.chevallier@...tlin.com>, <olteanv@...il.com>
CC: <Woojung.Huh@...rochip.com>, <andrew@...n.ch>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v2] net: dsa: microchip: Add SGMII port support
 to KSZ9477 switch

> Hello Vlad, Tristram,
> 
> I'm replying to Vlad's review as he correctly points that this looks
> very much like XPCS :)

> I mentionned on the previous iteration that there's indeed a DW XPCS in
> there :
> https://lore.kernel.org/netdev/20241129135919.57d59c90@fedora.home/
> 
> I have access to a platform with a KSZ9477, and indeed the PHY id
> register for the PCS mdio device show the DW XPCS id.
> 
> I've been able to get this serdes port working with the XPCS driver
> (although on 6.1 due to project constraints), although I couldn't get
> 1000BaseX autoneg to work.
> 
> So all in all I agree with Vlad's comments here, there's a lot of logic
> in this series to detect the phy_interface_mode, detect SFP or not,
> most of which isn't needed.
> 
> The logic should boil down to :
> 
>  - Create some helpers to access the PCS through a virtual mdio bus
> (basically the current port_sgmii_w/r)
> 
>  - Register a virtual mdio bus to access the PCS, hooked in
> ksz9477_port_setup() for the serdes port. That would look something
> like this :
> 
> +       bus = devm_mdiobus_alloc(ds->dev);
> (...)
> +       bus->read_c45 = ksz9477_sgmii_read;
> +       bus->write_c45 = ksz9477_sgmii_write;
> (...)
> +       ret = devm_mdiobus_register(ds->dev, bus);
> +       if (ret)
> +               (...)
> +
> +       port->xpcs = xpcs_create_mdiodev(bus, 0, <iface>);
> 
> - Make sure that .phylink_select_pcs() returns a ref to that xpcs
> 
> - Write the necessary ksz9477-specific glue logic (adjust the phylink capabilities,
> make sure the virual MDIO registers are un the regmap area, etc.)
> 
> I will be happy to test any further iterations :)

The KSZ9477 SGMII module does use DesignWare IP, but its implementation
is probably too old as some registers do not match.  When using XPCS
driver link detection works but the SGMII port does not pass traffic for
some SFPs.  It is probably doable to update the XPCS driver to work in
KSZ9477, but there is no way to submit that patch as that may affect
other hardware implementation.

One thing that is strange is that driver enables interrupt for 1000BaseX
mode but not SGMII mode, but in KSZ9477 SGMII mode can trigger link up
and link down interrupt but 1000BaseX can only trigger link up interrupt.