Re: [PATCH net-next v8 1/4] dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Thu, Jul 23, 2026 at 11:45:20AM +0200, Jonas Jelonek wrote:
> Hi Oleksij,
> 
> On 23.07.26 09:36, Oleksij Rempel wrote:
> > [...]
> >> Correct me if I'm wrong but from what I see, most of that budgeting machinery
> >> isn't used in dynamic budget evaluation strategy, which is used here because the
> >> MCU does budgeting on it's own.
> > Hm, I guess the wording in header is a bit confusing, I see now the
> > misconception :)
> >
> > dynamic vs static means - haw available budget is calculated, not where.
> > Dynamic can be implemented in the linux core too, but so far no one did.
> > Static can be implement in the MCU firmware as well.
> >
> > In static case - the Powered Device tells us haw much power budget we
> > need to reserve for this device and it will be permanently accounted.
> > Advantage - every device will get what it is requesting.
> > Disadvantage - we do not use full capability of the power supply.
> >
> > In dynamic case - we do not fully trust the Powered Device, first we
> > reserve requested budget and then start measuring the PD consumption.
> > If real consumption is less as requested, the reservation will be
> > reduced.
> > Advantage - more PDs can be attached.
> > Disadvantage - a spike in consumption of one PD, may kick out some low
> > prio PDs.
> >
> > Since the dynamic case need a lot of measurements, it is usually
> > implemented in the firmware. Both strategies have advantages and
> > disadvantages and MCUs may allow to change the strategies, this is why we
> > provide this information.
> >
> > In your case it is not documented, but it can be tested if you have
> > enough PDs where you can influence the load.
> 
> Probably takes a bit of preparation to set up such a test.
> 
> >
> > Not sure if we need an UNKNOWN flag to tell the user - we do not know
> > what to expect, use it on your own risk.
> 
> So dynamic happens to be the suitable case here right now, because the core
> doesn't handle it yet and the MCU does it on it's own without the core
> disturbing that?

Yes, dynamic happens to work with current core implementation for
software point of view. And provide correct or incorrect information to
user space. The PSE behavior expectations for user perspective will be
different depending on this information. 

> I'd like to avoid dealing with that in this series as this seems at least to me
> like another deep rabbit hole. The MCU comes always in kind of a
> pre-configured state, having several limits set so it should behave safe
> and mostly as expected without the driver changing anything.

Ack, reverse engineering has own limitations. I do not expect we will be
able to find all needed information.

> >> Using vpwr-supply on each PI still buys that the
> >> supply is enabled and ref-counted by PSE-PD core, and keeps potential for what
> >> might come. But no requesting, allocation or deallocation of power.
> > Ack, in many cases it is for diagnostic. Please note, a "manger" is in
> > the practice a multi channel current limiter/regulator. It has maximal
> > load per chip and different max load per port. This can be properly
> > reflected with the regulators. 
> >
> > For example, RTL8238B-VB datasheet do not document maximal rating per
> > chip, only per port. Calculating 8 ports, with 36W max, would result in
> > 288W. It feels like a lot of heat. Can it actually handle it?
> 
> I can't tell, but I would guess so. Several switches I have use a single PSE
> chip for 8 ports. Given the advertisment of 30W per port and staying within
> the overall budget, I might expect to be able to use it. Or the vendor hides
> some information.
> 
> > May be the MCU firmware has integrated maximal power limit do avoid HW
> > damage. A proper information in the regulator tree would help user to
> > understand why not all ports will get requested power.
> >
> >> Given that, I had a closer look at PD692x0 and it seems, this has a similar setup.
> >> The difference here being just that there's no multi-manager concept. There is
> >> also a manager-level supply reference "vmain-supply" which the driver reads
> >> and applies to the hardware, which does budgeting also in hardware.
> > According to RTL8238B documentation, it has same multi-manager concept.
> > Since one manager RTL8238B supports max 8 ports, a switch with more PoE
> > capable ports would need more chips.
> 
> I see. I mixed up the terms and thought this "manager" is separate level in
> between. If "manager" == RTL823x PSE chip, then it's the same setup.
> 
> What do you suggest? I would like to avoid doing any half-grounded claims
> or assumptions here while not fully overviewing the whole picture. At the same
> time, I have the feeling the datasheet and host command guide from Realtek
> are genuinely trying to fool me.
> 
> The setup seems to be very similar to PD692x0, we have multiple managers,
> managed by a controller (the MCU). The MCU mostly does runtime discovery
> of the downstream managers, so right now there is no apparent need to
> have the same manager + port definitions in DT as PD692x0.
> 
> In reality I haven't seen a board which has different power rails for different
> managers. So there's usually a single wire from the PSU going to the PoE
> daughterboard where everything lands on a single supply PCB trace. The MCU
> has a multi-bank concept, however it's usage right now is rather confusing.
> Managers seem to have strapping pins which tell which bank they use, and on
> the MCU side one can set power limit for each bank.

Current PSE framework already has a concept of power domain. Depending
on implementation, the "manger" can be the weakest point in the chain.
For example: one manager has 8 ports and can handle 200W, we have
devices with 2 managers each 200W max and PSU providing 500W. If we
attach 3 devices 100W each to ports 1, 2, 3 - will not work for the last
one. If we attache them to ports 1, 2 + 9, will work just fine. Because
it is attached to different power domain/manger.

Even if this information is hidden in the MCU. It is usable for admins,
to understand what combination of ports should be used for optimal power
delivery.

> > Since we already talk about power budgeting - all of this make sense if
> > we have port priorities. For example PD692x0 firmware has default prios
> > bound to port numbers. Is it the same with this firmware?
> 
> Looking at several switches, by default all ports have a priority of 0 assigned.
> Thus, no pre-defined prioritisation, it's up to the user to set this.

Do this switches have PSU covering all port at max load or it is over
provisioning by design. Haw it behave in reality If we attach more
consumer then it is able to handle - all ports go off, or only some of
them?

PD692x0 firmware has user configurable prios - but if many ports share
same prios it has internal prios based on port number.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |