From: Kory Maincent <kory.maincent@bootlin.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Donald Hunter <donald.hunter@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Dent Project <dentproject@linuxfoundation.org>,
kernel@pengutronix.de
Subject: Re: [PATCH net-next v3 5/7] net: ethtool: Add new power limit get and set features
Date: Mon, 17 Jun 2024 18:14:13 +0200 [thread overview]
Message-ID: <20240617181413.12178f95@kmaincent-XPS-13-7390> (raw)
In-Reply-To: <Zm6BGJxu4bLVszFD@pengutronix.de>
On Sun, 16 Jun 2024 08:07:20 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> On Sat, Jun 15, 2024 at 08:28:30PM +0200, Oleksij Rempel wrote:
> [...]
>
> Except of current value, we need an interface to return list of supported
> ranges. For example a controller with flexible configuration will have
> one entry
Yes, good idea.
> Proposed interface may look like this:
>
> ``ETHTOOL_A_C33_PSE_AVAIL_PWR_VAL_LIMIT`` u32 Get PoE PSE currently
> configured power value limit ``ETHTOOL_A_C33_PSE_PWR_LIMIT_RANGES``
> nested Supported power limit configuration ranges
> ====================================== ====== =============================
>
> +------------------------------------------+--------+----------------------------+
> | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGES`` | nested | array of power
> limit ranges|
> +-+----------------------------------------+--------+----------------------------+
> | | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGE_ENTRY`` | nested | one power
> limit range |
> +-+-+--------------------------------------+--------+----------------------------+
> | | | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_MIN`` | u32 | minimum power value
> (mW) |
> +-+-+--------------------------------------+--------+----------------------------+
> | | | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_MAX`` | u32 | maximum power value
> (mW) |
> +-+-+--------------------------------------+--------+----------------------------+
Not sure the ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGE_ENTRY bring anything
interesting.
+--------------------------------------------+--------+----------------------------+
| ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGES`` | nested | array of power limit ranges|
+-+------------------------------------------+--------+----------------------------+
| | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_MIN`` | u32 | minimum power value (mW) |
+-+------------------------------------------+--------+----------------------------+
| | ``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_MAX`` | u32 | maximum power value (mW) |
+-+------------------------------------------+--------+----------------------------+
> > Huh... i took some more time to investigate it. Looks like there is no
> > simple answer. Some devices seems to write power class on the box. Other
> > client devices write power consumption in watts. IEEE 802.3-2022
> > provides LLDP specification with PowerValue for watts and PowerClass for
> > classes. Different product user interfaces provide class and/or watts.
> > So, let's go with watts then. Please update the name to something like
> > pse_available_power_value or pse_available_power_value_limit and
> > document how it is related to State diagrams in the IEEE spec.
>
> Here is proposal for documentation:
>
> ``ETHTOOL_A_C33_PSE_AVAIL_PWR_VAL_LIMIT`` u32 Control PoE PSE available
> power value limit
>
> When set, the optional ``ETHTOOL_A_C33_PSE_AVAIL_PWR_VAL_LIMIT`` attribute is
> used to control the available power value limit for C33 PSE in milliwatts.
> This attribute corresponds to the `pse_available_power` variable described in
> ``IEEE 802.3-2022`` 33.2.4.4 Variables and `pse_avail_pwr` in 145.2.5.4
> Variables, which are described in power classes.
>
> It was decided to use milliwatts for this interface to unify it with other
> power monitoring interfaces, which also use milliwatts, and to align with
> various existing products that document power consumption in watts rather than
> classes. If power limit configuration based on classes is needed, the
> conversion can be done in user space, for example by ethtool.
Thanks for the rephrasing!
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2024-06-17 16:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 14:33 [PATCH net-next v3 0/7] net: pse-pd: Add new PSE c33 features Kory Maincent
2024-06-14 14:33 ` [PATCH net-next v3 1/7] net: ethtool: pse-pd: Expand C33 PSE status with class, power and extended state Kory Maincent
2024-06-15 11:22 ` Oleksij Rempel
2024-06-17 13:47 ` Kory Maincent
2024-06-17 19:55 ` Oleksij Rempel
2024-06-21 16:29 ` Kory Maincent
2024-06-22 5:06 ` Oleksij Rempel
2024-06-25 9:18 ` Kory Maincent
2024-06-25 10:33 ` Oleksij Rempel
2024-06-25 11:59 ` Kory Maincent
2024-06-14 14:33 ` [PATCH net-next v3 2/7] netlink: specs: Expand the PSE netlink command with C33 new features Kory Maincent
2024-06-17 8:01 ` Donald Hunter
2024-06-14 14:33 ` [PATCH net-next v3 3/7] net: pse-pd: pd692x0: Expand ethtool status message Kory Maincent
2024-06-14 14:33 ` [PATCH net-next v3 4/7] net: pse-pd: Add new power limit get and set c33 features Kory Maincent
2024-06-14 14:33 ` [PATCH net-next v3 5/7] net: ethtool: Add new power limit get and set features Kory Maincent
2024-06-15 15:59 ` Oleksij Rempel
2024-06-15 18:28 ` Oleksij Rempel
2024-06-16 6:07 ` Oleksij Rempel
2024-06-17 16:14 ` Kory Maincent [this message]
2024-06-17 19:57 ` Oleksij Rempel
2024-06-14 14:33 ` [PATCH net-next v3 6/7] netlink: specs: Expand the PSE netlink command with C33 pw-limit attributes Kory Maincent
2024-06-17 8:03 ` Donald Hunter
2024-06-17 9:53 ` Kory Maincent
2024-06-14 14:33 ` [PATCH net-next v3 7/7] net: pse-pd: pd692x0: Enhance with new current limit and voltage read callbacks Kory Maincent
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=20240617181413.12178f95@kmaincent-XPS-13-7390 \
--to=kory.maincent@bootlin.com \
--cc=davem@davemloft.net \
--cc=dentproject@linuxfoundation.org \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--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