From: Andrew Lunn <andrew@lunn.ch>
To: Oleksij Rempel <o.rempel@pengutronix.de>
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 16:57:35 +0200 [thread overview]
Message-ID: <5063429d-5dca-4538-b240-50c35cbf5e93@lunn.ch> (raw)
In-Reply-To: <Zi-vhKx-WlYPQe3c@pengutronix.de>
> 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
next prev parent reply other threads:[~2024-04-29 14:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 10:42 PoE complex usage of regulator API 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 [this message]
2024-04-29 15:58 ` Oleksij Rempel
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=5063429d-5dca-4538-b240-50c35cbf5e93@lunn.ch \
--to=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=o.rempel@pengutronix.de \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).