netdev - Re: Quirks for exotic SFP module

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: <ZFZcL8LKkX3+GKMT@shell.armlinux.org.uk>
Date: Sat, 6 May 2023 14:54:55 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Lorenz Brun <lorenz@...n.one>, netdev@...r.kernel.org
Subject: Re: Quirks for exotic SFP module

On Sat, May 06, 2023 at 03:35:42PM +0200, Andrew Lunn wrote:
> > Oh, so you're talking about signalling on the AR8033 <-> Linux Host part of
> > the link. I actually wasn't aware that 1000Base-X did in-band signalling,
> > TIL. Since the I2C bus is connected to the modem SoC it would have to
> > forward any MDIO to the AR8033 transceiver, right? This would also be a bit
> > weird as the AR8033 is connected "backwards", i.e. with RGMII facing towards
> > the Modem SoC and 1000Base-X towards the Linux host.

(To Lorenz)

It's not backwards at all. For a fibre link, 1000baseX is carried over
the fibre, and it looks like this:

Host MAC <==> Host PCS <==1000baseX==> Remote PCS <==> Remote MAC

The host has no access to the remote PCS.

In your case:

Host MAC <==> Host PCS <==1000baseX==> AR8033 <==RGMII==> SoC

How is this any different? I would say the AR8033 is up to the SoC to
manage itself. The fact that the SoC does something with the packets
to them stuff them out to the rest of the world is neither here nor
there. In the 1000base-X over fibre example above, the SoC could be
something designed for routing applications inside a network switch/
router.

Please don't get hung up on "there is a PHY on the module, I want
access to it!" As you're not talking twisted-pair ethernet, you
don't, there is nothing we need to control there.

The fact the module wants 1000base-X on its host interface is just
what it wants - and that it specifies that it offers 1000base-T
compliance is just the manufacturer being idiotic (as seems to be
the case with a lot of SFPs.)

Just add a quirk removing the 1000base-T capability, setting
1000base-X in the supported mask, and also clear the
PHY_INTERFACE_MODE_SGMII and set PHY_INTERFACE_MODE_1000BASEX in
the interfaces mask.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!