netdev - Re: [Intel-wired-lan] [PATCH 1/2] ethtool: transceiver reset and presence pin control

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: <6f127b5b-77c6-4bd4-8124-8eea6a12ca61@lunn.ch>
Date: Tue, 8 Apr 2025 18:10:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marek Pazdan <mpazdan@...sta.com>
Cc: aleksander.lobakin@...el.com, almasrymina@...gle.com,
	andrew+netdev@...n.ch, anthony.l.nguyen@...el.com,
	daniel.zahka@...il.com, davem@...emloft.net, ecree.xilinx@...il.com,
	edumazet@...gle.com, gal@...dia.com, horms@...nel.org,
	intel-wired-lan@...ts.osuosl.org, jianbol@...dia.com,
	kory.maincent@...tlin.com, kuba@...nel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	pabeni@...hat.com, przemyslaw.kitszel@...el.com, willemb@...gle.com
Subject: Re: [Intel-wired-lan] [PATCH 1/2] ethtool: transceiver reset and
 presence pin control

On Tue, Apr 08, 2025 at 03:32:30PM +0000, Marek Pazdan wrote:
> On Mon, 7 Apr 2025 22:39:17 +0200 Andrew Lunn wrote:
> > How do you tell the kernel to stop managing the SFP? If you hit the
> > module with a reset from user space, the kernel is going to get
> > confused. And how are you talking to the module? Are you going to
> > hijack the i2c device via i2-dev? Again, you need to stop the kernel
> > from using the device.
> 
> This is something to implement in driver code. For ice driver this reset will
> be executed through AQ command (Admin Queue) which is communication channel
> between driver and firmware. What I probably need to do is to add additional PHY
> state (like USER_MODULE_RESET) and check it when driver wants to execute AQ command.
> 
> > Before you go any further, i think you need to zoom out and tell us
> > the big picture....
> 
> In my use case I need to have ability to reset transceiver module. There are 
> several reasons for that. Most common is to reinit module if case of error state.
> (this according to CMIS spec). Another use case is that in our switch's cli there
> is a command for transceiver reinitialisation which involves transceiver reset.

Now zoom out, ignore your hardware, look at the Linux abstraction for
an SFP, across all NICs and switches.

There are ethtool calls to retrieve the modules eeprom contents. There
is an ethtool call to program the modules firmware. There is an
ethtool call to get/set the power mode. Modules can also export their
sensors via HWMON, the temperature, receive power, etc.

How does your wish to reset the module fit into the general Linux
model of an SFP? Should it be allowed in the middle of a firmware
upgrade? Should the power mode be lost due to a reset? Can you still
read from the EEPROM etc while it is in reset? What should HWMON
report? Should it be a foot gun?

It does however seem to me, what you want should somehow be an ethtool
operation. And it probably needs to be plumbed through
net/ethtool/module.c, and you need to look at how it interacts with
all the other code in that file. And you maybe need to force the
netdev to do a down/up so that it gets the new state of the module, or
you only allow it on an netdev which is admin down?

Your patch needs to explain the big picture, how it fits into the
Linux abstraction of an SFP, and how other vendors should implement
the same operation, if they wish to implement it.

    Andrew