netdev - Re: ethtool settings and SFP modules with PHYs

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: <20240917175347.5ad207da@fedora>
Date: Tue, 17 Sep 2024 17:53:47 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Daniel Golle <daniel@...rotopia.org>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Heiner Kallweit
 <hkallweit1@...il.com>, Kory Maincent <kory.maincent@...tlin.com>, Edward
 Cree <ecree.xilinx@...il.com>, Paolo Abeni <pabeni@...hat.com>, Jakub
 Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, "David S.
 Miller" <davem@...emloft.net>, John Crispin <john@...ozen.org>
Subject: Re: ethtool settings and SFP modules with PHYs

Hi,

On Mon, 16 Sep 2024 18:34:59 +0100
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

[...]

> The best place to decide to notify userspace would be at the
> module_start() callback - this happens when a module is present,
> and the netdev has been brought up. Note that this call will happen
> each and every time the netdev is brought up.

As we are brainstorming, may I suggest an alternative approach ?

I'm currently working on getting some way of providing userspace with a
representation of the front-facing ports of a netdev. This would
include SFP module ports, RJ45/8P8C/BaseT ports, BaseT1 ports, you name
it.

This would allow to represent with a bit more clarity use-cases such as
the MCBin's ports controlled by the 88x3310, the combo RJ45 / SFP ports.

The other case would be devices which have several PHYs in parallel.

The way I see it for now, is that we would have internal kernel objects
with a name such as "phy_port" or "phy_mdi" or just "mdi" (I'm bad at
naming), instanciated by PHY drivers (or phylib through generic helpers
in most simple case for single-port PHYs), as well as the SFP
subsystem, but also by NICs that have a front-facing port that's driven
neither through SFPs nor PHYs (through a firmware of some sort).

These phy_port would have a set of callback ops to get their
ethtool_ksettings linkmodes and could be added/removed dynamically, in
the case of SFP module insertion for example.

The notification I would imagine would be "there's a change on the
front-facing port" or "there's a new one, here's what it can do" in the
case of module insertion.

I already have some code for that, and I will talk about this exact
topic tomorrow morning at the networking track of LPC [1]

For the SFP case, the notification would trigger indeed at the
module_start/module_remove step.

All of that is still WIP, but I think it would reply to that exact need
of "notifying users when something happens to the ports", including SFP
module insertion.

I plan to submit an RFC shortly after LPC, I still need to iron some
things out, and I think that RFC will itself trigger a lot of
discussions, but do you see that this kind of work could help resolving
the issue faced by Daniel as well as the need for SFP-event
notifications ?

Thanks,

Maxime

[1] : https://lpc.events/event/18/contributions/1964/