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>

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!

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

> 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

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!