PoE complex usage of regulator API

[Kory Maincent <kory.maincent@bootlin.com>]

Hello Mark, Oleksij,

Now that PoE support has been merged, I am digging more into the PoE features.
We decided to use the regulator API inside the PSE (Power Sourcing Equipment)
API because PSE and regulators are quite similar as exposed by Oleksij in the ML
before: https://lore.kernel.org/netdev/20231221174246.GI1697233@pengutronix.de/
We designed it to have one regulator provider registered for each PSE ports
as described by Oleksij.

I am not really familiar with the regulator API and regulator controllers so I
have few questions and one issue using the API.

Let's begin simple, in PSE world we are more talking about power.
Would it be ok to add a regulator_get/set_power_limit() and
regulator_get_power() callback to regulator API. Would regulator API have
interest to such callbacks?

Port priority, more complex subject:
Indeed a PSE controller managing several ports may be able to turn off ports
with low priority if the total power consumption exceed a certain level.
- There are controller like PD692x0 that can managed this on the hardware side.
  In that case we would have a regulator_get/set_power_limit() callbacks from
  the regulator parent (the PSE contoller) and a regulator_get/set_priory()
  callbacks for the regulator children (PSE ports).
- There are controller like TPS23881 or LTC4266 that can set two priorities
  levels on their ports and a level change in one of their input pin can
  shutdown all the low priority ports. In that case the same callbacks could be
  used. regulator_get/set_power_limit() from the parent will be only at software
  level. regulator_get/set_priority() will set the priorities of the ports on
  hardware level. A polling function have to read frequently the total power
  used and compare it to the power budget, then it has to call something like
  regulator_shutdown_consumer() in case of power overflow.  
- We could also want to manage the regulator priorities fully at software level,
  in that case it will be like above but saving all informations in the driver
  or using regulator generic functions.
This priority support could bring lots of issue and complexity like unbinding
regulator children driver at runtime if regulator parent overflow its power
budget. In the other side it could be interesting in the global management of
power if power supply can vary, like battery or hot-pluggable power supply.
What do you think? Do you think it is worth adding it to regulator API?

Last point, the PSE issue with regulator counters:
In regulator world we are using counters to not disable a regulator if children
are still using it. In the PSE world the regulator providers describing the
PSE ports do not want such counter to exist. We do want to run enable/disable
commands several times without increment/decrement the counter. So I added an
admin_state_enabled PSE intermediate variable to fix that.
https://lore.kernel.org/netdev/20240417-feature_poe-v9-10-242293fd1900@bootlin.com/
But in case the port is enabled from Linux then shutdown from the PSE controller
for any reason, I have to run disable and enable command to enable it again. Not
really efficient :/
I am thinking of disabling the usage of counters in case of a
regulator_get_exclusive(). What do you think? Could it break other usage?

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com