Re: [PATCH net-next 2/2] net: sfp: manage receiver and transmitter regulators

[Romain Gantois <romain.gantois@bootlin.com>]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

Hello Mark,

On Friday, 6 March 2026 20:20:41 CET Mark Brown wrote:
> On Tue, Mar 03, 2026 at 06:32:52PM +0000, Russell King (Oracle) wrote:
> > On Tue, Mar 03, 2026 at 05:31:36PM +0000, Mark Brown wrote:
...
> 
> > Now, if you're going to say "ah, so it has power pins, you need to
> > describe them using a regulator" then I would say to you, when are
> > we introducing regulators for every device we describe in DT such
> > as LEDs, switches, GPIO pins, RAM, etc? Every device needs to have a
> > source of power after all.
> 
> It sounds from the cover letter for this series like there's some demand
> for power control of SFP cages, the cover letter isn't terribly specific
> about what circumstances though.  Possibly there's some UI for this on
> the system, or the hardware has some mechanism for detecting physical
> insertion to the SFP cage (hopefully well in advance of the electrical
> contacts being made)?  Romain, are you able to share more specifics on
> the use case here?

It seems like my upstreaming strategy was incorrect. The series that I sent is 
a subset of my original use case, but in hindsight I should've just presented 
the original one in the first place, that would've been clearer, sorry about 
that.

Originally, I implemented a runtime PM support in the SFP core. This allowed 
to cut power to the cages when the attached network interface was down, 
thereby saving power. This is interesting since I'm dealing with a battery-
powered system which has SFP cages. However, an upstream version of this would 
require some kind of new userspace interface to signal indifference to module 
detection when the upstream network interface is down. Otherwise it could 
break existing userspace applications which expect to detect and interact with 
SFP modules (e.g. read EEPROMs, read temperature sensors) even when their 
upper network interfaces are down.

Aside from this, what Russell told me in this message:

https://lore.kernel.org/all/aacYGTBobbfJgZpp@shell.armlinux.org.uk/

suggests that cutting power to SFP cages could lead to unspecified behavior 
with some modules, so for example unloading the SFP core kernel module while 
an SFP module was inserted could have unintended consequences... This problem 
requires some more investigation on my side before I can submit a proper 
runtime PM solution.

Thanks,

-- 
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]