[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250408153311.30539-1-mpazdan@arista.com>
Date: Tue, 8 Apr 2025 15:32:30 +0000
From: Marek Pazdan <mpazdan@...sta.com>
To: andrew@...n.ch
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,
mpazdan@...sta.com,
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 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.
Powered by blists - more mailing lists