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] [day] [month] [year] [list]

Message-Id: <JRP8UR.4LGGLMICAZ5S@brun.one>
Date: Sat, 06 May 2023 16:04:31 +0200
From: Lorenz Brun <lorenz@...n.one>
To: Russell King <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: Quirks for exotic SFP module

Am Sa, 6. Mai 2023 um 14:54:55 +01:00:00 schrieb Russell King (Oracle) 
<linux@...linux.org.uk>:
> 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.

That was my initial thought as well, Andrew told me to look for some 
interface to talk with a PHY.

> 
> 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.

Sounds good, I'll do that. Thanks for your help!

Regards,
Lorenz