Thread (23 messages) 23 messages, 5 authors, 2026-03-25

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

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2026-03-03 17:19:38
Also in: linux-devicetree, lkml

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:
quoted
On Tue, Mar 03, 2026 at 02:54:25PM +0100, Romain Gantois wrote:
quoted
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.
quoted
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!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help