public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Romain Gantois <romain.gantois@bootlin.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/2] net: sfp: Describe and handle regulators
Date: Tue, 3 Mar 2026 15:10:12 +0000	[thread overview]
Message-ID: <aab51KbpIq72wtSU@shell.armlinux.org.uk> (raw)
In-Reply-To: <20260303-sfp-regulators-v1-0-7101ae34cb84@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!

  parent reply	other threads:[~2026-03-03 15:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03 13:54 [PATCH net-next 0/2] net: sfp: Describe and handle regulators Romain Gantois
2026-03-03 13:54 ` [PATCH net-next 1/2] dt-bindings: net: sff,sfp: Describe power supply pins Romain Gantois
2026-03-03 18:37   ` Conor Dooley
2026-03-03 13:54 ` [PATCH net-next 2/2] net: sfp: manage receiver and transmitter regulators Romain Gantois
2026-03-03 14:22   ` Mark Brown
2026-03-03 14:40     ` Romain Gantois
2026-03-03 15:12       ` Russell King (Oracle)
2026-03-03 15:12     ` Russell King (Oracle)
2026-03-03 15:14       ` Mark Brown
2026-03-03 15:25         ` Russell King (Oracle)
2026-03-03 17:31           ` Mark Brown
2026-03-03 18:32             ` Russell King (Oracle)
2026-03-06 19:20               ` Mark Brown
2026-03-20  9:39                 ` Romain Gantois
2026-03-20 14:45                   ` Russell King (Oracle)
2026-03-25  9:40                     ` Romain Gantois
2026-03-20  9:55                 ` Romain Gantois
2026-03-04 21:38             ` Andrew Lunn
2026-03-06 16:19               ` Mark Brown
2026-03-03 15:10 ` Russell King (Oracle) [this message]
2026-03-03 15:54   ` [PATCH net-next 0/2] net: sfp: Describe and handle regulators Romain Gantois
2026-03-03 17:19     ` Russell King (Oracle)
2026-03-04 21:44     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aab51KbpIq72wtSU@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --cc=romain.gantois@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox