netdev - Re: [Intel-wired-lan] [PATCH 2/2] ice: add qsfp 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d55a3455-defd-4b23-9e0f-42d87e25f72d@lunn.ch>
Date: Tue, 8 Apr 2025 17:23:14 +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 2/2] ice: add qsfp transceiver reset
 and presence pin control

On Tue, Apr 08, 2025 at 02:22:43PM +0000, Marek Pazdan wrote:
> On Mon, 7 Apr 2025 22:30:54 +0200 Andrew Lunn wrote:
> 
> > As the name get/set-phy-tunable suggests, these are for PHY
> > properties, like downshift, fast link down, energy detected power
> > down.
> > 
> > What PHY are you using here?
> 
> Thanks for review.
> It's PHY E810-C in this case. According to spreadsheet: E810_Datasheet_Rev2.4.pdf
> (Chapter 17.3.3 E810 SDP[0:7] (GPIO) Connection), it's SDP0 and SDP2 GPIOs 
> are being connected to QSFP Reset and Presence pins correspondingly.
> I assume you may suggest this use case is not directly PHY related. In first approach
> I tried to use reset operation which has following flag in enum ethtool_reset_flags:
> ETH_RESET_PHY           = 1 << 6,       /* Transceiver/PHY */
> but this doesn't allow for reset asserting and later deasserting so I took 'get/set-phy-tunable'.

This does look like an abuse of the phy tunables. Lets get the big
picture, and then we can maybe suggest a better API.

Please consider my previous questions, how do you tell the kernel not
to use the SFP?  How do you ensure you don't reset the SFP in the
middle of the kernel performing a firmware upgrade of the SFP, etc.

	Andrew