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

[Jonas Jelonek <jelonek.jonas@gmail.com>]

Hi Oleksij,

On 23.07.26 12:20, Oleksij Rempel wrote:
> On Thu, Jul 23, 2026 at 11:45:20AM +0200, Jonas Jelonek wrote:
>> [...]
>> 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.

It is not hidden, but I see two ways to surface this right now:
(1) Someone figures is out once per board and puts that topology in the DT.
(2) Runtime topology detection, the MCU tells us how many managers we
     have, which downstream addresses they have and which port lives on
     which manager.

I'm not sure what is preferred, having it in DT or using runtime detection
if possible.

>>> 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. 

In most cases it's overprovisioned by design, the PSU budget is usually lower
than what would be needed for all ports at max load. Even one of my switches,
having a PoE budget of 400W, has 8 ports with 32W and 16 ports with 60 W,
managed by 5 managers. Usually a manager is not overprovisioned but the
system PSU is.

> 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?

That's a good question ^^. Unfortunately, I do not have enough PoE-powered
devices here to test this scenario, or at least it takes a bit of time to get
enough devices.

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

At least I'm not aware of that but since the firmware on the MCU is a
blackbox, in the end this could be the case too. But it's not an obvious
feature.


I'd like to slightly adjust the bindings, given the confusion about the naming
that came up with Sander. Is there anything else that should be changed? Or
is everything else in terms of supply, budgeting, etc. fine for follow-ups?


Best regards,
Jonas