[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5063429d-5dca-4538-b240-50c35cbf5e93@lunn.ch>
Date: Mon, 29 Apr 2024 16:57:35 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Kory Maincent <kory.maincent@...tlin.com>,
Mark Brown <broonie@...nel.org>,
Kyle Swenson <kyle.swenson@....tech>,
Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: PoE complex usage of regulator API
> 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?
> > 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
Powered by blists - more mailing lists