From: Kory Maincent <kory.maincent@bootlin.com>
To: Jonas Jelonek <jonas@jonasjelonek.de>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Sander Vanheule <sander@svanheule.net>,
Russell Senior <russell@personaltelco.net>
Subject: Re: [PATCH net-next 3/4] net: pse-pd: realtek-pse-mcu: configure global power budget
Date: Wed, 4 Nov 2026 13:36:36 +0100 [thread overview]
Message-ID: <357f6311-7f00-42c3-8eec-e0fd0c35749e@bootlin.com> (raw)
In-Reply-To: <e0910567-999c-4c96-9b20-2e34434bec3d@jonasjelonek.de>
On 11/4/26 13:20, Jonas Jelonek wrote:
> Hi Kory,
>
> On 04.11.26 12:32, Kory Maincent wrote:
>>
>>
>> On 11/3/26 23:03, Jonas Jelonek wrote:
>>> Use the optional VMAIN regulator power budget to configure the MCU's
>>> aggregate PoE power limit during probe. Quantize the available budget to
>>> the protocol's 100 mW units and reserve exactly that amount through the
>>> regulator core.
>>>
>>> The regulator budget represents the usable PoE allowance. Program zero
>>> reserved power so the previous firmware guard band does not further reduce
>>> that allowance.
>>>
>>> Require a finite budget of at least one protocol unit when vmain-supply is
>>> provided. Program the budget before selecting dynamic power management and
>>> ungating the ports, so enforcement starts with the regulator-derived limit.
>>>
>>> Enable VMAIN before hardware initialization and register one managed cleanup
>>> action to free any reserved budget and release the enable reference on probe
>>> failure and driver removal. Record each successful reservation immediately
>>> so subsequent initialization failures are covered by this action.
>>>
>>> Read the current budget index before programming the MCU. Retain the
>>> programmed MCU limit on probe failure and driver removal, as reducing that
>>> limit to zero would interrupt ongoing power delivery.
>>>
>>> Boards without vmain-supply retain their existing firmware-managed
>>> budget.
>>>
>>> Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
>>> ---
>>
>> ...
>>
>>> +static void rtpse_mcu_cleanup_vmain(void *data)
>>> +{
>>> + struct rtpse_mcu_ctrl *pse = data;
>>> +
>>> + if (pse->requested_budget_mW)
>>> + regulator_free_power_budget(pse->vmain, pse->requested_budget_mW);
>>> + regulator_disable(pse->vmain);
>>> +}
>>
>> Following patch 4 logic, you might not want to disable the PSE controller power supply,
>
> I added it because of the requirement that regulator_enable() calls must be
> balanced with regulator_disable() calls. Accepting that this may power off the
> rail in theory, something outside of the driver would need to keep the supply
> enabled. Concretely, I'm thinking of "regulator-always-on". And all boards
> I've seen so far which can use this driver do not provide a provide to really
> power off the PoE rail. Sure this is no finite guarantee.
>
> What is the correct way? I see either droping the enable call too, just relying on
> that it is correctly handled outside of this driver, or I keep enable + disable and
> the continued delivery is ensured with "regulator-always-on".
Indeed if you use "regulator-always-on" it does not turn off the power
supply when we call regulator_disable().
https://elixir.bootlin.com/linux/v7.3/source/drivers/regulator/core.c#L3269
Does the PSE controller needs this supply to start, or is it only
required to power the PSE PIs?
If it is the first you will need to enable it in the driver.
If it's the latter, you could describe it as the PI's regulator parent
supply. An enable of any PI will enable this vmain regulator.
>> this will lead to a power off of all your PIs.
>
> Is this enforced by PSE-PD or just based on the rail really being turned off?
If you call regulator_disable() on the main PSE power supply it will
turn off the power rail which will turn off you PIs.
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2026-11-04 12:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 22:03 [PATCH net-next 0/4] net: pse-pd: realtek-pse-mcu: establish power management configuration Jonas Jelonek
2026-11-03 22:03 ` [PATCH net-next 1/4] net: pse-pd: realtek-pse-mcu: ensure MCU does dynamic power management Jonas Jelonek
2026-11-04 10:02 ` Kory Maincent
2026-11-03 22:03 ` [PATCH net-next 2/4] dt-bindings: net: pse-pd: realtek,pse-mcu: add VMAIN supply Jonas Jelonek
2026-11-04 10:04 ` Kory Maincent
2026-11-04 21:49 ` Rob Herring (Arm)
2026-11-03 22:03 ` [PATCH net-next 3/4] net: pse-pd: realtek-pse-mcu: configure global power budget Jonas Jelonek
2026-11-04 11:32 ` Kory Maincent
2026-11-04 12:20 ` Jonas Jelonek
2026-11-04 12:36 ` Kory Maincent [this message]
2026-11-04 12:51 ` Jonas Jelonek
2026-11-03 22:03 ` [PATCH net-next 4/4] net: pse-pd: realtek-pse-mcu: avoid global disable on teardown Jonas Jelonek
2026-11-04 9:45 ` Kory Maincent
2026-11-04 9:51 ` Jonas Jelonek
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=357f6311-7f00-42c3-8eec-e0fd0c35749e@bootlin.com \
--to=kory.maincent@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@kernel.org \
--cc=jonas@jonasjelonek.de \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=russell@personaltelco.net \
--cc=sander@svanheule.net \
/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
all inboxes | Powered by JetHome®