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!