mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Kory Maincent <kory.maincent@bootlin.com>,
	Mark Brown <broonie@kernel.org>,
	Kyle Swenson <kyle.swenson@est.tech>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: PoE complex usage of regulator API
Date: Mon, 29 Apr 2024 17:58:09 +0200	[thread overview]
Message-ID: <Zi_DkX-m0F3TyAwH@pengutronix.de> (raw)
In-Reply-To: <5063429d-5dca-4538-b240-50c35cbf5e93@lunn.ch>

On Mon, Apr 29, 2024 at 04:57:35PM +0200, Andrew Lunn wrote:
> > Since there is already support to work with current (I) values, there
> > are is also overcurrent protection. If a device is beyond the power
> > budget limit, it is practically an over current event. Regulator
> > framework already capable on handling some of this events, what we need
> > for PoE is prioritization. If we detect overcurrent on supply root/node
> > we need to shutdown enough low prio consumers to provide enough power
> > for the high prio consumers.
> 
> So the assumption is we allow over provisioning?

I assume yes. But I didn't spend enough time to understand and analyze
this part. May be I just misunderstand over provisioning.

> > > So there is a potential second user, that's great to hear it! Could the
> > > priority stuff be also interesting? Like to allow only high priority SFP to use
> > > higher power class in case of a limiting power budget.
> 
> I was not expecting over-provisioning to happen. So prioritisation
> does not make much sense. You either have the power budget, or you
> don't.
> The SFP gets to use a higher power class if there is budget, or
> it is kept at a lower power class if there is no budget. I _guess_ you
> could give it a high power class, let it establish link, monitor its
> actual power consumption, and then decide to drop it to a lower class
> if the actual consumption indicates it could work at a lower
> class. But the danger is, you are going to loose link.
> 
> I've no real experience with this, and all systems today hide this
> away in firmware, rather than have Linux control it.
> 
>      Andrew

It may not be a over-provisioning by design. I can imagine some scenarios where
available power budge may dynamically change:

- Changes in Available Power Budget: If a PoE switch is modular or supports
hot-swappable power supplies, inserting a power supply with a lower power
budget while the system is under load can lead to insufficient power
availability. This might cause the system to redistribute power, potentially
leading to instability or overcurrent situations if the power management isn't
handled smoothly.

- Power Loss and Switching to Backup Sources: In cases where a switch relies on
a backup power source (like a UPS or a secondary power supply), the transition
from the primary power source to the backup can create fluctuations. These
fluctuations may temporarily affect how power is supplied to the PoE ports,
potentially causing overcurrent if the backup power does not match the original
specifications.

- System Internal Consumers: Components within the switch itself, such as
processing units or internal lighting/cooling systems, might draw power
differently under various operating conditions. Changes in internal consumption
due to increased processing needs or thermal dynamics could affect the overall
power budget.

- Environmental Conditions: High ambient temperatures can reduce the efficiency
of power delivery and increase the electrical resistance in circuits,
potentially leading to higher current draws. Additionally, cooling failures
within the switch can exacerbate this issue.

- Faulty Power Management Logic: Firmware bugs or errors in the power
management algorithm might incorrectly allocate power or fail to properly
respond to changes in power demands, leading to potential overcurrent
scenarios.

Regards,
Oleksij
-- 
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 |

  reply	other threads:[~2024-04-29 15:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26 10:42 Kory Maincent
2024-04-26 22:41 ` Andrew Lunn
2024-04-29 12:52   ` Kory Maincent
2024-04-29 14:32     ` Oleksij Rempel
2024-04-29 14:57       ` Andrew Lunn
2024-04-29 15:58         ` Oleksij Rempel [this message]
2024-04-29 15:58         ` Mark Brown
2024-04-29 15:47   ` Mark Brown
2024-04-29 15:38 ` Mark Brown
2024-04-29 17:28   ` Kory Maincent
2024-04-30  2:23     ` Mark Brown
2024-04-30  6:48       ` Oleksij Rempel

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=Zi_DkX-m0F3TyAwH@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kyle.swenson@est.tech \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®