[PATCH net-next 0/2] net: sfp: Describe and handle regulators

[PATCH net-next 0/2] net: sfp: Describe and handle regulators

[Romain Gantois]

Hi everyone,

This series describes regulators supplying the VccT and VccR pins of an SFP
cage or soldered-down transceiver.

These regulators can then be turned on only when the SFP device is probed,
thus saving power on systems which only load SFP cage support at certain
times, or load SFP device descriptions via device tree overlays.

Please let me know what you think.

Best Regards,

Romain

Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
Romain Gantois (2):
      dt-bindings: net: sff,sfp: Describe power supply pins
      net: sfp: manage receiver and transmitter regulators

 Documentation/devicetree/bindings/net/sff,sfp.yaml | 8 ++++++++
 drivers/net/phy/sfp.c                              | 9 +++++++++
 2 files changed, 17 insertions(+)
---
base-commit: ed0abfe93fd135dac223e87a3c945017b1fa8bfc
change-id: 20260303-sfp-regulators-1702369b4523

Best regards,
-- 
Romain Gantois <romain.gantois@bootlin.com>

[PATCH net-next 1/2] dt-bindings: net: sff,sfp: Describe power supply pins

[Romain Gantois]

SFP cages and soldered-on SFF transceivers have two separate power supply
pins: one for the transmitter circuit, and one for the receiver circuit.

Describe these two pins and the regulators supplying them.

Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
 Documentation/devicetree/bindings/net/sff,sfp.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/sff,sfp.yaml b/Documentation/devicetree/bindings/net/sff,sfp.yaml
index 15616ad737f57..95729cf694a7d 100644
--- a/Documentation/devicetree/bindings/net/sff,sfp.yaml
+++ b/Documentation/devicetree/bindings/net/sff,sfp.yaml
@@ -68,6 +68,14 @@ properties:
       output gpio signal (SFP+ only), low - low Tx rate, high - high Tx rate. Must
       not be present for SFF modules
 
+  vccr-supply:
+    description:
+      Phandle to a regulator supplying the receiver power (AKA VccR) pin.
+
+  vcct-supply:
+    description:
+      Phandle to a regulator supplying the transmitter power (AKA VccT) pin.
+
 allOf:
   - if:
       properties:

-- 
2.52.0

Re: [PATCH net-next 1/2] dt-bindings: net: sff,sfp: Describe power supply pins

[Conor Dooley]

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

On Tue, Mar 03, 2026 at 02:54:26PM +0100, Romain Gantois wrote:
> SFP cages and soldered-on SFF transceivers have two separate power supply
> pins: one for the transmitter circuit, and one for the receiver circuit.
> 
> Describe these two pins and the regulators supplying them.
> 
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Romain Gantois]

If phandles to receiver and/or transmitter regulators for an SFP device are
found, enable them at probe time.

Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
 drivers/net/phy/sfp.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f4bf53da3d4fd..602c166f60ddf 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -12,6 +12,7 @@
 #include <linux/of.h>
 #include <linux/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
 #include <linux/rtnetlink.h>
 #include <linux/slab.h>
 #include <linux/workqueue.h>
@@ -3095,6 +3096,14 @@ static int sfp_probe(struct platform_device *pdev)
 	struct sfp *sfp;
 	int err, i;
 
+	err = devm_regulator_get_enable_optional(&pdev->dev, "vccr");
+	if (err && err != -ENODEV)
+		return err;
+
+	err = devm_regulator_get_enable_optional(&pdev->dev, "vcct");
+	if (err && err != -ENODEV)
+		return err;
+
 	sfp = sfp_alloc(&pdev->dev);
 	if (IS_ERR(sfp))
 		return PTR_ERR(sfp);

-- 
2.52.0

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

[Mark Brown]

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

On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:
> If phandles to receiver and/or transmitter regulators for an SFP device are
> found, enable them at probe time.

The driver should unconditionally request whatever power the device
needs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Romain Gantois]

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

Hello Mark,

On Tuesday, 3 March 2026 15:22:40 CET Mark Brown wrote:
> On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:
> > If phandles to receiver and/or transmitter regulators for an SFP device
> > are
> > found, enable them at probe time.
> 
> The driver should unconditionally request whatever power the device
> needs.

Ok, I'll use devm_regulator_get_enable() instead then.

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 --]

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

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 03:40:54PM +0100, Romain Gantois wrote:
> Hello Mark,
> 
> On Tuesday, 3 March 2026 15:22:40 CET Mark Brown wrote:
> > On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:
> > > If phandles to receiver and/or transmitter regulators for an SFP device
> > > are
> > > found, enable them at probe time.
> > 
> > The driver should unconditionally request whatever power the device
> > needs.
> 
> Ok, I'll use devm_regulator_get_enable() instead then.

What Mark is suggesting will break existing users. So, I'm afraid we
can't proceed with this proposal. Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 02:22:40PM +0000, Mark Brown wrote:
> On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:
> > If phandles to receiver and/or transmitter regulators for an SFP device are
> > found, enable them at probe time.
> 
> The driver should unconditionally request whatever power the device
> needs.

... and then we break everyone, just like you broke SATA, and I've
never forgiven you for taking a principled line on this rather than a
pragmatic approach. You're making the same mistake here.

As we disagree, we're at a stalemate, the result of which will be a
NACK to this patch set.

Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Mark Brown]

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

On Tue, Mar 03, 2026 at 03:12:14PM +0000, Russell King (Oracle) wrote:
> On Tue, Mar 03, 2026 at 02:22:40PM +0000, Mark Brown wrote:
> > On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:

> > > If phandles to receiver and/or transmitter regulators for an SFP device are
> > > found, enable them at probe time.

> > The driver should unconditionally request whatever power the device
> > needs.

> ... and then we break everyone, just like you broke SATA, and I've
> never forgiven you for taking a principled line on this rather than a
> pragmatic approach. You're making the same mistake here.

Sorry, what's the breakage here?  The log messages, or something else?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 03:14:02PM +0000, Mark Brown wrote:
> On Tue, Mar 03, 2026 at 03:12:14PM +0000, Russell King (Oracle) wrote:
> > On Tue, Mar 03, 2026 at 02:22:40PM +0000, Mark Brown wrote:
> > > On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:
> 
> > > > If phandles to receiver and/or transmitter regulators for an SFP device are
> > > > found, enable them at probe time.
> 
> > > The driver should unconditionally request whatever power the device
> > > needs.
> 
> > ... and then we break everyone, just like you broke SATA, and I've
> > never forgiven you for taking a principled line on this rather than a
> > pragmatic approach. You're making the same mistake here.
> 
> Sorry, what's the breakage here?  The log messages, or something else?

... which then caused someone to "fix" DT by disabling devices to shut
up those log messages, including for platforms where those devices were
being used, which ultimately caused a boot failure.

... and your argument that SATA PHYs need these supplies, which is false
when the SATA PHY is integrated into the SoC and there's no details on
what those supplies are or where they come from, or even if they are
controllable.

Yet you demand that a SATA PHY supply must be provided, and so we're
stuck with:

[    1.207484] ahci f2540000.sata: supply ahci not found, using dummy regulator
[    1.213524] ahci f2540000.sata: supply phy not found, using dummy regulator
[    1.219630] platform f2540000.sata:sata-port@1: supply target not found, using dummy regulator
[    1.227800] ahci f4540000.sata: supply ahci not found, using dummy regulator
[    1.233757] ahci f4540000.sata: supply phy not found, using dummy regulator
[    1.239805] platform f4540000.sata:sata-port@0: supply target not found, using dummy regulator

on every boot with no way to shut them up. These supplies *ARE*
optional in terms of whether they can be described in DT.

As I've told you before, we have no information by which to describe
these supplies in DT on these platforms (not even with the data for
the chip) so you are effectively forcing people to "make stuff up" in
DT to shut up your warnings - blowing the whole idea that DT should
describe the hardware out of the water. How can we describe this
hardware if we don't have the internal design details of the chip?

The only way is to make something up, and all because you've decided
SATA supplies are no longer optional.

As SFP cages have not had to describe these supplies, requiring them
*now* will cause *regressions* because no one is going to be specifying
them, which will lead to stuff breaking. Again.

So, for the good of users of my SFP code, I will refuse any
introduction of regulators into my code for as long as you're take
the principled stance that regulators shall not be optional, rather
than applying a sensible pragmatic approach. You give me no option
here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Mark Brown]

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

On Tue, Mar 03, 2026 at 03:25:35PM +0000, Russell King (Oracle) wrote:
> On Tue, Mar 03, 2026 at 03:14:02PM +0000, Mark Brown wrote:

> > Sorry, what's the breakage here?  The log messages, or something else?

> ... which then caused someone to "fix" DT by disabling devices to shut
> up those log messages, including for platforms where those devices were
> being used, which ultimately caused a boot failure.

> ... and your argument that SATA PHYs need these supplies, which is false
> when the SATA PHY is integrated into the SoC and there's no details on
> what those supplies are or where they come from, or even if they are
> controllable.

The supplies don't need to be controllable or have any other information
to be specified, it sounds like this hardware has a fixed voltage
regulator that's supplying the PHY which is representable without any
changes, though I do agree it's annoying.

Though having said that with your description above I'm really not clear
that the regulator support is in the right place in the SATA framework
at all, it sounds like the supplies are being requested by the SATA
controller but the expectation is that the SATA controller is the thing
that is supplying power rather than consuming it.  I think that's where
things are going wrong here?  There are some SATA implementations that
don't include the power delivery part of SATA and only those require the
supplies?  The logs you posted looked like it was controllers requesting
the supplies which does look like the bindings and associated requests
aren't what I'd expect for something describing the hardware.

For SFP my understanding is that SFP has a physical specification which
includes power inputs and that these supplies are being requested by the
devices that consume them.  If some part of that is not the case then it
sounds like the bindings aren't describing the hardware (or at least are
a bit unclear about how they're doing so) and should be revised.  The
series doesn't seem to do anything at all with the supply side either,
I'm guessing there are some SFP controllers with integrated power
provisioning.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 05:31:36PM +0000, Mark Brown wrote:
> On Tue, Mar 03, 2026 at 03:25:35PM +0000, Russell King (Oracle) wrote:
> > On Tue, Mar 03, 2026 at 03:14:02PM +0000, Mark Brown wrote:
> 
> > > Sorry, what's the breakage here?  The log messages, or something else?
> 
> > ... which then caused someone to "fix" DT by disabling devices to shut
> > up those log messages, including for platforms where those devices were
> > being used, which ultimately caused a boot failure.
> 
> > ... and your argument that SATA PHYs need these supplies, which is false
> > when the SATA PHY is integrated into the SoC and there's no details on
> > what those supplies are or where they come from, or even if they are
> > controllable.
> 
> The supplies don't need to be controllable or have any other information
> to be specified, it sounds like this hardware has a fixed voltage
> regulator that's supplying the PHY which is representable without any
> changes, though I do agree it's annoying.
> 
> Though having said that with your description above I'm really not clear
> that the regulator support is in the right place in the SATA framework
> at all, it sounds like the supplies are being requested by the SATA
> controller but the expectation is that the SATA controller is the thing
> that is supplying power rather than consuming it.  I think that's where
> things are going wrong here?  There are some SATA implementations that
> don't include the power delivery part of SATA and only those require the
> supplies?  The logs you posted looked like it was controllers requesting
> the supplies which does look like the bindings and associated requests
> aren't what I'd expect for something describing the hardware.

The setup here as far as can be derived from the SoC documentation is:


----------------------------------------------------------+ External
 SoC +--------------------------------+                   | World
     |             .---- SATA port 0 --- COMPHY SerDes <-----> port 2
<-bus-> AHCI SATA controller          |                   |
     |             ^---- SATA port 1 --- COMPHY SerDes <-----> port 1
     +--------------------------------+                   |
----------------------------------------------------------+

The COMPHY SerDes is a multi-protocol SerDes, which supports PCIe, SATA,
and Ethernet, and is driven optionally by firmware via the generic PHY
driver. This is entirely separate from the SATA ports in the AHCI
controller. The external world are the two pairs of data pin
connections to the SATA drive per port. Nothing more - no power pins.

Drive power is up to the user. In my case, I've plugged in a 12V ATX
format power module that provides the +12V and +5V through normal PC
style wiring to the drives - none of that has any business being
described in DT because it's out of scope of the board itself.

The AHCI SATA controller and COMPHY are integrated into the SoC.
Internally, these components would be provided power by the internal
SoC design.

So, let's go through the supplies for the AHCI controller. The binding
documentation states:

  ahci-supply:
    description: Power regulator for AHCI controller

First, this is not listed as a required property. In this case, the
AHCI controller is internal to the SoC, and no details are given in
the documentation what that supply is, where it is derived from, or
whether it's controllable.

  target-supply:
    description: Power regulator for SATA target device

The board does not provide power to the target device, that is derived
off-board and completely up to the user. Thus, this can't be specified.

  phy-supply:
    description: Power regulator for SATA PHY

The PHY is an entirely separate device (the COMPHY) from the AHCI
controller. Thus, specifying a PHY supply for this AHCI hardware is
not relevant at the AHCI controller layer. Sure, other AHCI designs
where the PHY is not generic may require a separate PHY supply which
may be controllable, but here is one example where this just isn't
relevant.

So, as a result of commit 962399bb7fbf ("ata: libahci_platform: Fix
regulator_get_optional() misuse") we have now ended up with kernel
boots issuing messages at warning severity (which means something is
wrong and requires attention) for supplies that are not relevant to
this SoC hardware design.

The side effect of that commit was commit 30023876aef4 ("arm64: dts:
marvell: only enable complete sata nodes") which disabled the ports
to shut up these warning messages, but the hunk for
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi was incomplete,
only enabling one SATA port, despite the board having three SATA
ports. This caused boot failure as SATA drives that were previously
accessible became inaccessible due to the SATA ports missing until
I fixed that in 2aeadea47f5b ("ARM64: dts: mcbin: fix SATA ports on
Macchiatobin").

We're now left with the annoying warning messages that - as I've
stated above - are certainly in one case just not relevant to the
SoC design.

> For SFP my understanding is that SFP has a physical specification which
> includes power inputs and that these supplies are being requested by the
> devices that consume them.  If some part of that is not the case then it
> sounds like the bindings aren't describing the hardware (or at least are
> a bit unclear about how they're doing so) and should be revised.  The
> series doesn't seem to do anything at all with the supply side either,
> I'm guessing there are some SFP controllers with integrated power
> provisioning.

First, please scrap the idea of "SFP controller". There's no such
device. There's a SFP cage, which is a physical connector and a
specification of the signals on the pins. How those signals are
provided, or even whether they are provided is outside the scope
of the "specification".

This includes the high-speed SerDes pairs for transmit and receive
data. There are also low-speed pins - I2C and state pins. Finally,
there are power pins. State pins end up being connected to GPIOs, or
appropriately tied to their inactive levels or left open depending
whether they are an input to the module or output.

There is no specification that power pins will be controllable.
The only requirement is the voltage on the pins and the stability
of that voltage.

SFP modules have two sets of power pins, one set for the transmitter
and one set for the receiver.

1. Modules are allowed to tie these two sets of power pins together.
2. The recommendation in the SFF documentation is that these are
   derived from a common supply via filtering, and that common supply
   is also used for the signalling pin pull-ups.
3. It is unspecified which of these supplies is used for the "low-
   speed" signalling interfaces.

Given (1), it is unwise for a board with a cage to present two
controllable supplies, as turning one supply off can result in
power being back-fed via a module tying both together. Thus,
specifying separate supplies could be dangerous.

Removing power from a module while plugged in, while keeping the
low-speed signals at logic high levels may result in damage due to
backfeeding power through the ESD protection diodes in the silicon
devices. If the I2C bus is shared, then powering down a module may
corrupt communication to other devices on that I2C bus.

So, given all that, every design I've seen so far connects the SFP
cage power pins to the board's 3.3V supply that is active when the
board is powered.

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.

- A LED may be wired between a GPIO and a supply.
- A switch that pulls a GPIO up to logic 1 state needs to be connected
  to some sort of supply to do that.
- A GPIO controller requires a source of power in order to signal a
  logic high.

We tend not to describe those because they aren't relevant to the
OS, because they tend to be "always on" supplies that the OS can't
control, and have no effect at all on the kernel itself. DT is not
about translating every single wire and component on a schematic for
a board into a firmware description.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Mark Brown]

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

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:

> > supplies?  The logs you posted looked like it was controllers requesting
> > the supplies which does look like the bindings and associated requests
> > aren't what I'd expect for something describing the hardware.

> The setup here as far as can be derived from the SoC documentation is:

> The AHCI SATA controller and COMPHY are integrated into the SoC.
> Internally, these components would be provided power by the internal
> SoC design.

> So, let's go through the supplies for the AHCI controller. The binding
> documentation states:

>   ahci-supply:
>     description: Power regulator for AHCI controller

> First, this is not listed as a required property. In this case, the
> AHCI controller is internal to the SoC, and no details are given in
> the documentation what that supply is, where it is derived from, or
> whether it's controllable.

This just shouldn't be there as a generic property for all AHCI
controllers, if there are controllers that have such a supply it should
be part of the controller specific bindings not forced on every single
controller.

>   target-supply:
>     description: Power regulator for SATA target device

> The board does not provide power to the target device, that is derived
> off-board and completely up to the user. Thus, this can't be specified.

Right, and also even within the board this is a property of the target
device not the controller.  Arguably you could say that your separate
ATX supply ends up being part of the same system for practical purposes
but it's a stretch.

>   phy-supply:
>     description: Power regulator for SATA PHY

> The PHY is an entirely separate device (the COMPHY) from the AHCI
> controller. Thus, specifying a PHY supply for this AHCI hardware is
> not relevant at the AHCI controller layer. Sure, other AHCI designs
> where the PHY is not generic may require a separate PHY supply which
> may be controllable, but here is one example where this just isn't
> relevant.

Yeah, same here.  This is a property of the PHY, and possibly of a
specific PHY.

> So, as a result of commit 962399bb7fbf ("ata: libahci_platform: Fix
> regulator_get_optional() misuse") we have now ended up with kernel
> boots issuing messages at warning severity (which means something is
> wrong and requires attention) for supplies that are not relevant to
> this SoC hardware design.

The underlying issue here being that the generic AHCI code's bindings
and hence regulator usage just don't reflect general AHCI hardware at
all, that's then causing knock on effects since as you say there's no
way for systems to provide sensible information corresponding to what
the drivers are asking for.  

> We're now left with the annoying warning messages that - as I've
> stated above - are certainly in one case just not relevant to the
> SoC design.

I agree that we should do something here, I was working on the basis
that the bindings reflected the hardware but that seems rather far from
reality.  I'm wondering if we should have an API that lets drivers say
they're requesting a regulator for a "legacy" binding, that way we can
keep all the checking of usage and avoid fragility with mishandling of
errors but avoid complaining at users.

> > For SFP my understanding is that SFP has a physical specification which
> > includes power inputs and that these supplies are being requested by the
> > devices that consume them.  If some part of that is not the case then it
> > sounds like the bindings aren't describing the hardware (or at least are
> > a bit unclear about how they're doing so) and should be revised.  The
> > series doesn't seem to do anything at all with the supply side either,
> > I'm guessing there are some SFP controllers with integrated power
> > provisioning.

> First, please scrap the idea of "SFP controller". There's no such
> device. There's a SFP cage, which is a physical connector and a
> specification of the signals on the pins. How those signals are
> provided, or even whether they are provided is outside the scope
> of the "specification".

I see.  That's sounding like rather than having something that applies
to all SFP devices anything we do end up having should be something that
represents a SFP cage specifically, that's the thing that has the
physical specification with a known set of supplies.  With soldered down
stuff I suspect there's enough room for complication that it should be
dealt with on a device by device basis if needed.

> Given (1), it is unwise for a board with a cage to present two
> controllable supplies, as turning one supply off can result in
> power being back-fed via a module tying both together. Thus,
> specifying separate supplies could be dangerous.

I guess even if they're not controlled separately it's possible that
someone might decide that having two LDOs is part of their filtering
strategy...  It is generally easier to cope with the situation where one
supply does two consumers that are controlled together than it is to
deal with the situation where two supplies that are normally the same
are delivered by two separate regulators.  It all feels very edge casey
thugh.

> 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Romain Gantois]

[-- 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 --]

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

[Russell King (Oracle)]

On Fri, Mar 20, 2026 at 10:39:10AM +0100, Romain Gantois wrote:
> 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.

Have you measured how much power is saved by this?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Romain Gantois]

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

On Friday, 20 March 2026 15:45:31 CET Russell King (Oracle) wrote:
> On Fri, Mar 20, 2026 at 10:39:10AM +0100, Romain Gantois wrote:
> > 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.
> 
> Have you measured how much power is saved by this?

Sure, here are a few measures of saved power with several different modules 
I've tested. The measures were done with a shunt resistor on the regulator 
line feeding all power pins on both SFP cages. Only one SFP cage was occupied 
during each measure and the upper network interface was down.

Module           | Power saved (uW)
SFP-10G-T-I    | 80
SFP-10G-T-30 | 359
SFP-GB-GE-T  | 191
CHAMPION ONE 1000SFPT | 188
SFP-H10GB-CU1M | 0
ES8512-3LCD05 | 248
SFP100BFXST | 351

So with both SFP cages occupied, we could see about 0.7mW of saved power by 
cutting the regulators to the cages.

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 --]

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

[Romain Gantois]

[-- 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 --]

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

[Andrew Lunn]

> For SFP my understanding is that SFP has a physical specification which
> includes power inputs and that these supplies are being requested by the
> devices that consume them.  If some part of that is not the case then it
> sounds like the bindings aren't describing the hardware (or at least are
> a bit unclear about how they're doing so) and should be revised.  The
> series doesn't seem to do anything at all with the supply side either,
> I'm guessing there are some SFP controllers with integrated power
> provisioning.

There is not really an SFP controller.

SFPs really break up into two parts, because they are
hot-pluggable. There is a cage, which is mounted on the board, and a
module which is inserted into the cage. The cage is passive.

https://en.wikipedia.org/wiki/Small_Form-factor_Pluggable gives a
reasonable overview.

The cage provides the module with power, 3.3v, max 300mA for Rx and
the same for TX. Something must supply the cage, and most designs just
connect the cage to the board power rails. The example give in
Multisource Agreement does exactly that, with some capacitors and
inducters to limit surge on hot plug.

This is the first board since 2017, when support for SFPs was added,
which can actually control the power supplies. We cannot make
regulators mandatory without breaking backwards compatibility.

So for me, the patch is good as it is now, the regulators are
optional.

   Andrew

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

[Mark Brown]

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

On Wed, Mar 04, 2026 at 10:38:54PM +0100, Andrew Lunn wrote:

> This is the first board since 2017, when support for SFPs was added,
> which can actually control the power supplies. We cannot make
> regulators mandatory without breaking backwards compatibility.

> So for me, the patch is good as it is now, the regulators are
> optional.

To be clear the actual effect of the regular API is that no regulator
has been specified by the firmware then we assume that there's something
we don't know about and substitute in a dummy regulator, otherwise
adding regulator support to anything would be excessively complex and
fragile.  We do currently warn when we do this since we're generally
very conservative about things like this as messing up power can crash
the system.

The issues Russell is seeing with AHCI are a combination of people just
bodging those warnings and the AHCI regulator bindings being very
confused, I'll follow up to his mail separately.

Optional regulators are for the case where the supply may be physically
absent and the driver needs to do something about it, for example the
original use case was for some of the MMC/SD specs where higher
performance modes add an additional supply which needs to be turned on
only after negotating with the device, if it's absent then the system
should handle this by not enabling those higher performance modes.

If a supply absolutely has to be there the driver should use a normal
regulator and write code on the basis that it will actually have power.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH net-next 0/2] net: sfp: Describe and handle regulators

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 02:54:25PM +0100, Romain Gantois wrote:
> Hi everyone,
> 
> This series describes regulators supplying the VccT and VccR pins of an SFP
> cage or soldered-down transceiver.
> 
> These regulators can then be turned on only when the SFP device is probed,
> thus saving power on systems which only load SFP cage support at certain
> times, or load SFP device descriptions via device tree overlays.
> 
> Please let me know what you think.

As ever, I don't want to be adding support for stuff into mainline
which doesn't ever get used - historically, we've had a lot of that.
So, any patch set which adds some kind of facility like this needs to
be accompanied by a user of it.

This is especially true in this case, because I want to see why you're
wanting to have two regulators, when INF-8074 suggests that both VccT
and VccR should be derived from the same supply. The reason the
modules have separate supplies for the transmitter and receiver is
because the host side has the supply filtering networks to ensure
cross-talk between each is kept to a minimum.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next 0/2] net: sfp: Describe and handle regulators

[Romain Gantois]

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

Hi Russell,

On Tuesday, 3 March 2026 16:10:12 CET Russell King (Oracle) wrote:
> On Tue, Mar 03, 2026 at 02:54:25PM +0100, Romain Gantois wrote:
> > Hi everyone,
> > 
> > This series describes regulators supplying the VccT and VccR pins of an
> > SFP
> > cage or soldered-down transceiver.
> > 
> > These regulators can then be turned on only when the SFP device is probed,
> > thus saving power on systems which only load SFP cage support at certain
> > times, or load SFP device descriptions via device tree overlays.
> > 
> > Please let me know what you think.
> 
> As ever, I don't want to be adding support for stuff into mainline
> which doesn't ever get used - historically, we've had a lot of that.
> So, any patch set which adds some kind of facility like this needs to
> be accompanied by a user of it.
> 

I understand, though I'm dealing with an out-of-tree board but I understand 
that this doesn't really count as a valid first use case.

> This is especially true in this case, because I want to see why you're
> wanting to have two regulators, when INF-8074 suggests that both VccT
> and VccR should be derived from the same supply. The reason the
> modules have separate supplies for the transmitter and receiver is
> because the host side has the supply filtering networks to ensure
> cross-talk between each is kept to a minimum.

Interesting, I wasn't aware of this. I thought it was something like "being 
able to shut down the transmitter side only while waiting for a WoL packet".

It seems like there won't be a v2 anyway but I just wanted to explain why I 
went with two regulators in the first place.

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 --]

Re: [PATCH net-next 0/2] net: sfp: Describe and handle regulators

[Russell King (Oracle)]

On Tue, Mar 03, 2026 at 04:54:56PM +0100, Romain Gantois wrote:
> Hi Russell,
> 
> On Tuesday, 3 March 2026 16:10:12 CET Russell King (Oracle) wrote:
> > On Tue, Mar 03, 2026 at 02:54:25PM +0100, Romain Gantois wrote:
> > > Hi everyone,
> > > 
> > > This series describes regulators supplying the VccT and VccR pins of an
> > > SFP
> > > cage or soldered-down transceiver.
> > > 
> > > These regulators can then be turned on only when the SFP device is probed,
> > > thus saving power on systems which only load SFP cage support at certain
> > > times, or load SFP device descriptions via device tree overlays.
> > > 
> > > Please let me know what you think.
> > 
> > As ever, I don't want to be adding support for stuff into mainline
> > which doesn't ever get used - historically, we've had a lot of that.
> > So, any patch set which adds some kind of facility like this needs to
> > be accompanied by a user of it.
> > 
> 
> I understand, though I'm dealing with an out-of-tree board but I understand 
> that this doesn't really count as a valid first use case.
> 
> > This is especially true in this case, because I want to see why you're
> > wanting to have two regulators, when INF-8074 suggests that both VccT
> > and VccR should be derived from the same supply. The reason the
> > modules have separate supplies for the transmitter and receiver is
> > because the host side has the supply filtering networks to ensure
> > cross-talk between each is kept to a minimum.
> 
> Interesting, I wasn't aware of this. I thought it was something like "being 
> able to shut down the transmitter side only while waiting for a WoL packet".

A transceiver module is permitted to internally connect VccT and VccR,
which would make separate supplies questionable. See INF-8074, table 1
note 8, on page 22.

I suspect there could be boards out there which do have separate
control of each supply, but they need to be prepared for a module that
does physically connect VccT and VccR together on the module.

There is the problem that these documents do not specify which Vcc
pins supply power to the EEPROM, and if one powers down the supply
for the EEPROM, or the PHY/uC in the case of a copper module, that
could cause ESD diodes to conduct, pulling down the I2C bus. It
would also be out of spec. For example, the M24C02C datasheet from
Microchip states in 1.0 under the Absolute Maximum Ratings (beyond
which damage may occur) that for any input or output, the allowable
voltage range is -0.6V to Vcc + 1.0V - this is normally because of
the ESD diodes that clamp the input pin voltages to be within the
supply voltage pins +/- the diode drop.

Thus, powering down supplies to a SFP/SFF module while it's plugged
in and keeping IOs at their normal levels would have unspecified
behaviour, especially if there is no way to isolate the I2C bus from
the module and/or if other signals are actively driven or pulled up
to their "high" state.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next 0/2] net: sfp: Describe and handle regulators

[Andrew Lunn]

> Interesting, I wasn't aware of this. I thought it was something like "being 
> able to shut down the transmitter side only while waiting for a WoL packet".

That will not be reliable. INF-8074 says:

6) VeeR and VeeT may be internally connected within the SFP module.

So shutting down the transmit regulator might end up putting double
load on the receive regulator, and the magic smoke getting out, if the
design does not take this into account.

       Andrew