netdev - Re: [PATCH net-next v2 0/7] net: rework SFP capability parsing and quirks

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: <b67b9041-71ac-4e60-86fc-9d59329719cf@bootlin.com>
Date: Wed, 24 Sep 2025 12:12:17 +0530
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 linux-arm-msm@...r.kernel.org, Marek Behún
 <kabel@...nel.org>, netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next v2 0/7] net: rework SFP capability parsing and
 quirks

Hi Russell,

On 17/09/2025 03:16, Russell King (Oracle) wrote:
> The original SPF module parsing was implemented prior to gaining any
> quirks, and was designed such that the upstream calls the parsing
> functions to get the translated capabilities of the module.
> 
> SFP quirks were then added to cope with modules that didn't correctly
> fill out their ID EEPROM. The quirk function was called from
> sfp_parse_support() to allow quirks to modify the ethtool link mode
> masks.
> 
> Using just ethtool link mode masks eventually lead to difficulties
> determining the correct phy_interface_t mode, so a bitmap of these
> modes were added - needing both the upstream API and quirks to be
> updated.
> 
> We have had significantly more SFP module quirks added since, some
> which are modifying the ID EEPROM as a way of influencing the data
> we provide to the upstream - for example, sfp_fixup_10gbaset_30m()
> changes id.base.connector so we report PORT_TP. This could be done
> more cleanly if the quirks had access to the parsed SFP port.
> 
> In order to improve flexibility, and to simplify some of the upstream
> code, we group all module capabilities into a single structure that
> the upstream can access via sfp_module_get_caps(). This will allow
> the module capabilities to be expanded if required without reworking
> all the infrastructure and upstreams again.
> 
> In this series, we rework the SFP code to use the capability structure
> and then rework all the upstream implementations, finally removing the
> old kernel internal APIs.
> 

That's some nice work !

I however would have like to be in CC for that, and to have gotten the
information that you were working on that.

You commented on the phy_port V10 that we were moving away from
sfp_select_interface() and at the time, I asked if the approach I was
considering for phy_port was correct or not [1].

Without any reply from you I move on and implemented some reworks in the
phy_port series, without comments from you on V11/12/13, only to find out
now that this whole thing I've added since v10 to come-up with generic
interface selection on PHY driver SFP is superseded by that work.

While your approach is definitely better, I'd have appreciated a heads-up
that you were working on that, or even be in CC: for that work, as I'm
having very limited availabilities to parse the full netdev list :(

In any case, this will make the phy_port series simpler, so thanks for
that work

[1] : https://lore.kernel.org/netdev/a30d00cd-9148-423b-a3e5-b11d6c5c270b@bootlin.com/

Maxime
> ---