Received-SPF: pass (google.com: domain of linux-kernel+bounces-162294-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 29 Apr 2024 14:52:03 +0200
From: Kory Maincent <kory.maincent@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>, 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
Message-ID: <20240429145203.219bee06@kmaincent-XPS-13-7390>
In-Reply-To: <57a79abd-722c-4907-b0e7-2396392ae675@lunn.ch>
References: <20240426124253.56fd0933@kmaincent-XPS-13-7390>
	<57a79abd-722c-4907-b0e7-2396392ae675@lunn.ch>
Organization: bootlin
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 27 Apr 2024 00:41:19 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > 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 ha=
ve
> > interest to such callbacks? =20
>=20
> Could you define this API in more details.

The first new PoE features targeted by this API was to read the consumed po=
wer
and get set the power limit for each ports. Yes mainly book keeping.
Few drivers callbacks that will be called by ethtool and maybe the read of =
power
limit and consumed power could be add to read-only sysfs regulator.

> I'm assuming this is mostly about book keeping? When a regulator is
> created, we want to say is can deliver up to X Kilowatts. We then want
> to allocate power to ports. So there needs to be a call asking it to
> allocate part of X to a consumer, which could fail if there is not
> sufficient power budget left. And there needs to be a call to release
> such an allocation.

This is more the aim of the second point I have raised, power priority and
parent power budget. And how the core can manage it.

> We are probably not so much interested in what the actual current
> power draw is, assuming there is no wish to over provision?
>=20
> There is in theory a potential second user of this. Intel have been
> looking at power control for SFPs. Typically they are guaranteed a
> minimum of 1.5W. However, they can operate at higher power
> classes. You can have boards with multiple SFPs, with a theoretical
> maximum power draw more than what the supply can supply. So you need
> similar sort of power budget book keeping to allocate power to an SFP
> cage before telling the SFP module it can swap to a higher power
> class. I say this is theoretical, because the device Intel is working
> on has this hidden away in firmware. But maybe sometime in the future
> somebody will want Linux doing this.

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.

Regards,
--=20
K=C3=B6ry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com