.../bindings/net/pse-pd/microchip,pd692x0.yaml | 22 +- .../bindings/net/pse-pd/ti,tps23881.yaml | 8 + Documentation/netlink/specs/ethtool.yaml | 76 ++ Documentation/networking/ethtool-netlink.rst | 49 + drivers/net/mdio/fwnode_mdio.c | 26 +- drivers/net/pse-pd/pd692x0.c | 225 +++++ drivers/net/pse-pd/pse_core.c | 1068 +++++++++++++++++++- drivers/net/pse-pd/tps23881.c | 403 +++++++- include/linux/ethtool_netlink.h | 9 + include/linux/pse-pd/pse.h | 108 +- include/uapi/linux/ethtool_netlink_generated.h | 40 + net/ethtool/pse-pd.c | 63 ++ 12 files changed, 2043 insertions(+), 54 deletions(-)
From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
This series brings support for budget evaluation strategy in the PSE
subsystem. PSE controllers can set priorities to decide which ports should
be turned off in case of special events like over-current.
This patch series adds support for two budget evaluation strategy.
1. Static Method:
This method involves distributing power based on PD classification.
It’s straightforward and stable, the PSE core keeping track of the
budget and subtracting the power requested by each PD’s class.
Advantages: Every PD gets its promised power at any time, which
guarantees reliability.
Disadvantages: PD classification steps are large, meaning devices
request much more power than they actually need. As a result, the power
supply may only operate at, say, 50% capacity, which is inefficient and
wastes money.
2. Dynamic Method:
To address the inefficiencies of the static method, vendors like
Microchip have introduced dynamic power budgeting, as seen in the
PD692x0 firmware. This method monitors the current consumption per port
and subtracts it from the available power budget. When the budget is
exceeded, lower-priority ports are shut down.
Advantages: This method optimizes resource utilization, saving costs.
Disadvantages: Low-priority devices may experience instability.
The UAPI allows adding support for software port priority mode managed from
userspace later if needed.
Patches 1-2: Add support for interrupt event report in PSE core, ethtool
and ethtool specs.
Patch 3: Adds support for interrupt and event report in TPS23881 driver.
Patches 4,5: Add support for PSE power domain in PSE core and ethtool.
Patches 6-8: Add support for budget evaluation strategy in PSE core,
ethtool and ethtool specs.
Patches 9-11: Add support for port priority and power supplies in PD692x0
drivers.
Patches 12,13: Add support for port priority in TPS23881 drivers.
Signed-off-by: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
---
Changes in v12:
- Rebase on net-next.
- Link to v11: https://lore.kernel.org/r/20250520-feature_poe_port_prio-v11-0-bbaf447e1b28@bootlin.com
Changes in v11:
- Move the PSE events enum description fully in the ethtool spec.
- Remove the first patch which was useless as not used.
- Split the second patch to separate the attached_phydev introduction to
the PSE interrupt support.
- Link to v10: https://lore.kernel.org/r/20250506-feature_poe_port_prio-v10-0-55679a4895f9@bootlin.com
Changes in v10:
- Change patch 2 and 7 due to possible used after free scenario or
deadlock scenario. Move the PSE notification send management to a
workqueue to protect it from the deadlock scenario.
- Link to v9: https://lore.kernel.org/r/20250422-feature_poe_port_prio-v9-0-417fc007572d@bootlin.com
Changes in v9:
- Add a missing check after skb creation.
- Link to v8: https://lore.kernel.org/r/20250416-feature_poe_port_prio-v8-0-446c39dc3738@bootlin.com
Changes in v8:
- Rename a few functions for better clarity.
- Add missing kref_init in PSE power domain support and a wrong error
check condition.
- Link to v7: https://lore.kernel.org/r/20250408-feature_poe_port_prio-v7-0-9f5fc9e329cd@bootlin.com
Changes in v7:
- Add reference count and mutex lock for PSE power domain.
- Add support to retry enabling port that failed to be powered in case of
port disconnection or priority change.
- Use flags definition for pse events in ethtool specs.
- Small changes in the TPS23881 driver.
- Link to v6: https://lore.kernel.org/r/20250304-feature_poe_port_prio-v6-0-3dc0c5ebaf32@bootlin.com
Changes in v6:
- Few typos.
- Use uint instead of bitset for PSE_EVENT.
- Remove report of budget evaluation strategy in the uAPI.
- Link to v5: https://lore.kernel.org/r/20250218-feature_poe_port_prio-v5-0-3da486e5fd64@bootlin.com
Changes in v5:
- Remove the first part of the patch series which tackled PSE
improvement and already gets merged:
https://lore.kernel.org/netdev/20250110-b4-feature_poe_arrange-v3-0-142279aedb94@bootlin.com/
- Remove the PSE index support which is useless for now. The PSE power
domain ID is sufficient.
- Add support for PD692x0 power supplies other than Vmain which was already
in the patch series.
- Few other small fixes.
- Link to v4: https://lore.kernel.org/r/20250103-feature_poe_port_prio-v4-0-dc91a3c0c187@bootlin.com
Changes in v4:
- Remove disconnection policy.
- Rename port priority mode to budget evaluation strategy.
- Add cosmetic changes in PSE core.
- Add support for port priority in PD692x0 driver.
- Link to v3: https://lore.kernel.org/r/20241121-feature_poe_port_prio-v3-0-83299fa6967c@bootlin.com
Changes in v3:
- Move power budget to regulator core.
- Add disconnection policies with PIs using the same priority.
- Several fixes on the TPS23881 drivers.
- Several new cosmetic patches.
- Link to v2: https://lore.kernel.org/r/20241030-feature_poe_port_prio-v2-0-9559622ee47a@bootlin.com
Changes in v2:
- Rethink the port priority management.
- Add PSE id.
- Add support for PSE power domains.
- Add get power budget regulator constraint.
- Link to v1: https://lore.kernel.org/r/20241002-feature_poe_port_prio-v1-0-787054f74ed5@bootlin.com
---
Kory Maincent (13):
net: pse-pd: Introduce attached_phydev to pse control
net: pse-pd: Add support for reporting events
net: pse-pd: tps23881: Add support for PSE events and interrupts
net: pse-pd: Add support for PSE power domains
net: ethtool: Add support for new power domains index description
net: pse-pd: Add helper to report hardware enable status of the PI
net: pse-pd: Add support for budget evaluation strategies
net: ethtool: Add PSE port priority support feature
net: pse-pd: pd692x0: Add support for PSE PI priority feature
net: pse-pd: pd692x0: Add support for controller and manager power supplies
dt-bindings: net: pse-pd: microchip,pd692x0: Add manager regulator supply
net: pse-pd: tps23881: Add support for static port priority feature
dt-bindings: net: pse-pd: ti,tps23881: Add interrupt description
.../bindings/net/pse-pd/microchip,pd692x0.yaml | 22 +-
.../bindings/net/pse-pd/ti,tps23881.yaml | 8 +
Documentation/netlink/specs/ethtool.yaml | 76 ++
Documentation/networking/ethtool-netlink.rst | 49 +
drivers/net/mdio/fwnode_mdio.c | 26 +-
drivers/net/pse-pd/pd692x0.c | 225 +++++
drivers/net/pse-pd/pse_core.c | 1068 +++++++++++++++++++-
drivers/net/pse-pd/tps23881.c | 403 +++++++-
include/linux/ethtool_netlink.h | 9 +
include/linux/pse-pd/pse.h | 108 +-
include/uapi/linux/ethtool_netlink_generated.h | 40 +
net/ethtool/pse-pd.c | 63 ++
12 files changed, 2043 insertions(+), 54 deletions(-)
---
base-commit: 573d51a171a9237a8ecd9921d9c69af74cc51ce8
change-id: 20240913-feature_poe_port_prio-a51aed7332ec
Best regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hi Kory, A short positive feedback: I partially tested this series and committed patches for PSE support and impressed how easy it is now to configure and use a switch with PoE support! For testing I used "Novarq Tactical 1000" switch with Microchip EV14Y36A PSE evaluation board attached to it. I didn't had enough equipment for actual prioritization testing, otherwise I would add my Tested-by here :) Thank you! On Sat, May 24, 2025 at 12:56:02PM +0200, Kory Maincent wrote: > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> > > This series brings support for budget evaluation strategy in the PSE > subsystem. PSE controllers can set priorities to decide which ports should > be turned off in case of special events like over-current. > > This patch series adds support for two budget evaluation strategy. > 1. Static Method: > > This method involves distributing power based on PD classification. > It’s straightforward and stable, the PSE core keeping track of the > budget and subtracting the power requested by each PD’s class. > > Advantages: Every PD gets its promised power at any time, which > guarantees reliability. > > Disadvantages: PD classification steps are large, meaning devices > request much more power than they actually need. As a result, the power > supply may only operate at, say, 50% capacity, which is inefficient and > wastes money. > > 2. Dynamic Method: > > To address the inefficiencies of the static method, vendors like > Microchip have introduced dynamic power budgeting, as seen in the > PD692x0 firmware. This method monitors the current consumption per port > and subtracts it from the available power budget. When the budget is > exceeded, lower-priority ports are shut down. > > Advantages: This method optimizes resource utilization, saving costs. > > Disadvantages: Low-priority devices may experience instability. > > The UAPI allows adding support for software port priority mode managed from > userspace later if needed. > > Patches 1-2: Add support for interrupt event report in PSE core, ethtool > and ethtool specs. > Patch 3: Adds support for interrupt and event report in TPS23881 driver. > Patches 4,5: Add support for PSE power domain in PSE core and ethtool. > Patches 6-8: Add support for budget evaluation strategy in PSE core, > ethtool and ethtool specs. > Patches 9-11: Add support for port priority and power supplies in PD692x0 > drivers. > Patches 12,13: Add support for port priority in TPS23881 drivers. > > Signed-off-by: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> > --- > Changes in v12: > - Rebase on net-next. > - Link to v11: https://lore.kernel.org/r/20250520-feature_poe_port_prio-v11-0-bbaf447e1b28@bootlin.com > > Changes in v11: > - Move the PSE events enum description fully in the ethtool spec. > - Remove the first patch which was useless as not used. > - Split the second patch to separate the attached_phydev introduction to > the PSE interrupt support. > - Link to v10: https://lore.kernel.org/r/20250506-feature_poe_port_prio-v10-0-55679a4895f9@bootlin.com > > Changes in v10: > - Change patch 2 and 7 due to possible used after free scenario or > deadlock scenario. Move the PSE notification send management to a > workqueue to protect it from the deadlock scenario. > - Link to v9: https://lore.kernel.org/r/20250422-feature_poe_port_prio-v9-0-417fc007572d@bootlin.com > > Changes in v9: > - Add a missing check after skb creation. > - Link to v8: https://lore.kernel.org/r/20250416-feature_poe_port_prio-v8-0-446c39dc3738@bootlin.com > > Changes in v8: > - Rename a few functions for better clarity. > - Add missing kref_init in PSE power domain support and a wrong error > check condition. > - Link to v7: https://lore.kernel.org/r/20250408-feature_poe_port_prio-v7-0-9f5fc9e329cd@bootlin.com > > Changes in v7: > - Add reference count and mutex lock for PSE power domain. > - Add support to retry enabling port that failed to be powered in case of > port disconnection or priority change. > - Use flags definition for pse events in ethtool specs. > - Small changes in the TPS23881 driver. > - Link to v6: https://lore.kernel.org/r/20250304-feature_poe_port_prio-v6-0-3dc0c5ebaf32@bootlin.com > > Changes in v6: > - Few typos. > - Use uint instead of bitset for PSE_EVENT. > - Remove report of budget evaluation strategy in the uAPI. > - Link to v5: https://lore.kernel.org/r/20250218-feature_poe_port_prio-v5-0-3da486e5fd64@bootlin.com > > Changes in v5: > - Remove the first part of the patch series which tackled PSE > improvement and already gets merged: > https://lore.kernel.org/netdev/20250110-b4-feature_poe_arrange-v3-0-142279aedb94@bootlin.com/ > - Remove the PSE index support which is useless for now. The PSE power > domain ID is sufficient. > - Add support for PD692x0 power supplies other than Vmain which was already > in the patch series. > - Few other small fixes. > - Link to v4: https://lore.kernel.org/r/20250103-feature_poe_port_prio-v4-0-dc91a3c0c187@bootlin.com > > Changes in v4: > - Remove disconnection policy. > - Rename port priority mode to budget evaluation strategy. > - Add cosmetic changes in PSE core. > - Add support for port priority in PD692x0 driver. > - Link to v3: https://lore.kernel.org/r/20241121-feature_poe_port_prio-v3-0-83299fa6967c@bootlin.com > > Changes in v3: > - Move power budget to regulator core. > - Add disconnection policies with PIs using the same priority. > - Several fixes on the TPS23881 drivers. > - Several new cosmetic patches. > - Link to v2: https://lore.kernel.org/r/20241030-feature_poe_port_prio-v2-0-9559622ee47a@bootlin.com > > Changes in v2: > - Rethink the port priority management. > - Add PSE id. > - Add support for PSE power domains. > - Add get power budget regulator constraint. > - Link to v1: https://lore.kernel.org/r/20241002-feature_poe_port_prio-v1-0-787054f74ed5@bootlin.com > > --- > Kory Maincent (13): > net: pse-pd: Introduce attached_phydev to pse control > net: pse-pd: Add support for reporting events > net: pse-pd: tps23881: Add support for PSE events and interrupts > net: pse-pd: Add support for PSE power domains > net: ethtool: Add support for new power domains index description > net: pse-pd: Add helper to report hardware enable status of the PI > net: pse-pd: Add support for budget evaluation strategies > net: ethtool: Add PSE port priority support feature > net: pse-pd: pd692x0: Add support for PSE PI priority feature > net: pse-pd: pd692x0: Add support for controller and manager power supplies > dt-bindings: net: pse-pd: microchip,pd692x0: Add manager regulator supply > net: pse-pd: tps23881: Add support for static port priority feature > dt-bindings: net: pse-pd: ti,tps23881: Add interrupt description > > .../bindings/net/pse-pd/microchip,pd692x0.yaml | 22 +- > .../bindings/net/pse-pd/ti,tps23881.yaml | 8 + > Documentation/netlink/specs/ethtool.yaml | 76 ++ > Documentation/networking/ethtool-netlink.rst | 49 + > drivers/net/mdio/fwnode_mdio.c | 26 +- > drivers/net/pse-pd/pd692x0.c | 225 +++++ > drivers/net/pse-pd/pse_core.c | 1068 +++++++++++++++++++- > drivers/net/pse-pd/tps23881.c | 403 +++++++- > include/linux/ethtool_netlink.h | 9 + > include/linux/pse-pd/pse.h | 108 +- > include/uapi/linux/ethtool_netlink_generated.h | 40 + > net/ethtool/pse-pd.c | 63 ++ > 12 files changed, 2043 insertions(+), 54 deletions(-) > --- > base-commit: 573d51a171a9237a8ecd9921d9c69af74cc51ce8 > change-id: 20240913-feature_poe_port_prio-a51aed7332ec > > Best regards, > -- > Köry Maincent, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com > > -- 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 |
On 5/24/25 12:56 PM, Kory Maincent wrote: > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> > > This series brings support for budget evaluation strategy in the PSE > subsystem. PSE controllers can set priorities to decide which ports should > be turned off in case of special events like over-current. > > This patch series adds support for two budget evaluation strategy. > 1. Static Method: > > This method involves distributing power based on PD classification. > It’s straightforward and stable, the PSE core keeping track of the > budget and subtracting the power requested by each PD’s class. > > Advantages: Every PD gets its promised power at any time, which > guarantees reliability. > > Disadvantages: PD classification steps are large, meaning devices > request much more power than they actually need. As a result, the power > supply may only operate at, say, 50% capacity, which is inefficient and > wastes money. > > 2. Dynamic Method: > > To address the inefficiencies of the static method, vendors like > Microchip have introduced dynamic power budgeting, as seen in the > PD692x0 firmware. This method monitors the current consumption per port > and subtracts it from the available power budget. When the budget is > exceeded, lower-priority ports are shut down. > > Advantages: This method optimizes resource utilization, saving costs. > > Disadvantages: Low-priority devices may experience instability. > > The UAPI allows adding support for software port priority mode managed from > userspace later if needed. > > Patches 1-2: Add support for interrupt event report in PSE core, ethtool > and ethtool specs. > Patch 3: Adds support for interrupt and event report in TPS23881 driver. > Patches 4,5: Add support for PSE power domain in PSE core and ethtool. > Patches 6-8: Add support for budget evaluation strategy in PSE core, > ethtool and ethtool specs. > Patches 9-11: Add support for port priority and power supplies in PD692x0 > drivers. > Patches 12,13: Add support for port priority in TPS23881 drivers. > > Signed-off-by: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> I'm sorry, even if this has been posted (just) before the merge window, I think an uAPI extension this late is a bit too dangerous, please repost when net-next will reopen after the merge window. Thanks, Paolo
On 28/05/2025 10:31, Paolo Abeni wrote: > I'm sorry, even if this has been posted (just) before the merge window, > I think an uAPI extension this late is a bit too dangerous, please > repost when net-next will reopen after the merge window. Are all new uapi changes expected to come with a test that exercises the functionality?
Le Sun, 8 Jun 2025 09:17:59 +0300, Gal Pressman <gal@nvidia.com> a écrit : > On 28/05/2025 10:31, Paolo Abeni wrote: > > I'm sorry, even if this has been posted (just) before the merge window, > > I think an uAPI extension this late is a bit too dangerous, please > > repost when net-next will reopen after the merge window. > > Are all new uapi changes expected to come with a test that exercises the > functionality? I don't think so and I don't think it is doable for now on PSE. There is nothing that could get the PSE control of a dummy PSE controller driver. We need either the support for a dummy PHY driver similarly to netdevsim or the support for the MDI ports. By luck Maxime Chevallier is currently working on both of these tasks and had already sent several times the patch series for the MDI port support. -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On 09/06/2025 11:36, Kory Maincent wrote: > Le Sun, 8 Jun 2025 09:17:59 +0300, > Gal Pressman <gal@nvidia.com> a écrit : > >> On 28/05/2025 10:31, Paolo Abeni wrote: >>> I'm sorry, even if this has been posted (just) before the merge window, >>> I think an uAPI extension this late is a bit too dangerous, please >>> repost when net-next will reopen after the merge window. >> >> Are all new uapi changes expected to come with a test that exercises the >> functionality? > > I don't think so and I don't think it is doable for now on PSE. There is nothing > that could get the PSE control of a dummy PSE controller driver. We need either > the support for a dummy PHY driver similarly to netdevsim or the support for the > MDI ports. > By luck Maxime Chevallier is currently working on both of these tasks and had > already sent several times the patch series for the MDI port support. > We shouldn't rule it out so quickly, testing is important, let's try to accommodate to our rules. Why can't this be tested on real hardware using a drivers/net/hw selftest? The test can skip if it lacks the needed hardware. Or rebase this over Maxime's work?
Le Mon, 9 Jun 2025 14:03:46 +0300, Gal Pressman <gal@nvidia.com> a écrit : > On 09/06/2025 11:36, Kory Maincent wrote: > > Le Sun, 8 Jun 2025 09:17:59 +0300, > > Gal Pressman <gal@nvidia.com> a écrit : > > > >> On 28/05/2025 10:31, Paolo Abeni wrote: > [...] > >> > >> Are all new uapi changes expected to come with a test that exercises the > >> functionality? > > > > I don't think so and I don't think it is doable for now on PSE. There is > > nothing that could get the PSE control of a dummy PSE controller driver. We > > need either the support for a dummy PHY driver similarly to netdevsim or > > the support for the MDI ports. > > By luck Maxime Chevallier is currently working on both of these tasks and > > had already sent several times the patch series for the MDI port support. > > > > We shouldn't rule it out so quickly, testing is important, let's try to > accommodate to our rules. > > Why can't this be tested on real hardware using a drivers/net/hw > selftest? The test can skip if it lacks the needed hardware. > Or rebase this over Maxime's work? How should I do it if I need to use ethtool to test it? It is a vicious circle as ethtool need this to be merge before supporting it. Would it be ok to accept it like that and wait for ethtool support to add the selftest? Otherwise I could test it through ynl python command but there is no similar cases in the selftest. Nevertheless, it would have been nicer to point this out earlier in the series. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On 09/06/2025 17:03, Kory Maincent wrote: > Le Mon, 9 Jun 2025 14:03:46 +0300, > Gal Pressman <gal@nvidia.com> a écrit : > >> On 09/06/2025 11:36, Kory Maincent wrote: >>> Le Sun, 8 Jun 2025 09:17:59 +0300, >>> Gal Pressman <gal@nvidia.com> a écrit : >>> >>>> On 28/05/2025 10:31, Paolo Abeni wrote: >> [...] >>>> >>>> Are all new uapi changes expected to come with a test that exercises the >>>> functionality? >>> >>> I don't think so and I don't think it is doable for now on PSE. There is >>> nothing that could get the PSE control of a dummy PSE controller driver. We >>> need either the support for a dummy PHY driver similarly to netdevsim or >>> the support for the MDI ports. >>> By luck Maxime Chevallier is currently working on both of these tasks and >>> had already sent several times the patch series for the MDI port support. >>> >> >> We shouldn't rule it out so quickly, testing is important, let's try to >> accommodate to our rules. >> >> Why can't this be tested on real hardware using a drivers/net/hw >> selftest? The test can skip if it lacks the needed hardware. >> Or rebase this over Maxime's work? > > How should I do it if I need to use ethtool to test it? It is a vicious circle > as ethtool need this to be merge before supporting it. > Would it be ok to accept it like that and wait for ethtool support to add the > selftest? > Otherwise I could test it through ynl python command but there is no similar > cases in the selftest. I think that in theory the userspace patches need to be posted together with the kernel, from maintainer-netdev.rst: User space code exercising kernel features should be posted alongside kernel patches. This gives reviewers a chance to see how any new interface is used and how well it works. I am not sure if that's really the case though. > > Nevertheless, it would have been nicer to point this out earlier in the series. I agree, we also encountered the same thing :\... I tried to convince the maintainer [1] that this needs to be documented more clearly, but got ignored. The current rule we have is: "Broadly, any new uAPI should come with tests which exercise the functionality." [1] https://lore.kernel.org/all/3a3ce4c2-5cc1-4deb-be47-d936b61c42c4@nvidia.com/
> I think that in theory the userspace patches need to be posted together > with the kernel, from maintainer-netdev.rst: > > User space code exercising kernel features should be posted > alongside kernel patches. This gives reviewers a chance to see > how any new interface is used and how well it works. > > I am not sure if that's really the case though. The ethtool Maintainer tends to wait to the end of the cycle to pick up all patches and then applies and releases a new ethtool binary. The same applies for iproute2. That means the CI tests are not capable of testing new features using ethtool. I'm also not sure if it needs a human to update the ethtool binary on the CI systems, and how active that human is. Could this be changed, sure, if somebody has the needed bandwidth. Using the APIs directly via ynl python is possible in CI, since that is all in tree, as far as i know. However, ethtool is the primary user tool, so i do see having tests for it as useful. But they might need to wait for a cycle, or at least fail gracefully until the ethtool binary is updated. Andrew
On 09/06/2025 18:12, Andrew Lunn wrote: >> I think that in theory the userspace patches need to be posted together >> with the kernel, from maintainer-netdev.rst: >> >> User space code exercising kernel features should be posted >> alongside kernel patches. This gives reviewers a chance to see >> how any new interface is used and how well it works. >> >> I am not sure if that's really the case though. > > The ethtool Maintainer tends to wait to the end of the cycle to pick > up all patches and then applies and releases a new ethtool binary. The > same applies for iproute2. That means the CI tests are not capable of > testing new features using ethtool. I'm also not sure if it needs a > human to update the ethtool binary on the CI systems, and how active > that human is. Could this be changed, sure, if somebody has the needed > bandwidth. > > Using the APIs directly via ynl python is possible in CI, since that > is all in tree, as far as i know. However, ethtool is the primary user > tool, so i do see having tests for it as useful. But they might need > to wait for a cycle, or at least fail gracefully until the ethtool > binary is updated. Thanks Andrew, so I interpret this as selftests should be added when the userspace patches get accepted (or released?)? Not part of the original kernel submission?
On Wed, Jun 11, 2025 at 09:05:01AM +0300, Gal Pressman wrote:
> On 09/06/2025 18:12, Andrew Lunn wrote:
> >> I think that in theory the userspace patches need to be posted together
> >> with the kernel, from maintainer-netdev.rst:
> >>
> >> User space code exercising kernel features should be posted
> >> alongside kernel patches. This gives reviewers a chance to see
> >> how any new interface is used and how well it works.
> >>
> >> I am not sure if that's really the case though.
> >
> > The ethtool Maintainer tends to wait to the end of the cycle to pick
> > up all patches and then applies and releases a new ethtool binary. The
> > same applies for iproute2. That means the CI tests are not capable of
> > testing new features using ethtool. I'm also not sure if it needs a
> > human to update the ethtool binary on the CI systems, and how active
> > that human is. Could this be changed, sure, if somebody has the needed
> > bandwidth.
> >
> > Using the APIs directly via ynl python is possible in CI, since that
> > is all in tree, as far as i know. However, ethtool is the primary user
> > tool, so i do see having tests for it as useful. But they might need
> > to wait for a cycle, or at least fail gracefully until the ethtool
> > binary is updated.
>
> Thanks Andrew, so I interpret this as selftests should be added when the
> userspace patches get accepted (or released?)? Not part of the original
> kernel submission?
I personally would submit the tests at the same time, but make them
gracefully fail when the ethtool binary is too old. As a reviewer,
seeing the tests as well and the ethtool patches and the kernel code
gives me a warm fuzzy feeling the overall quality is good, the new
code is actually tested, etc and the code should be merged.
Andrew
Le Wed, 28 May 2025 09:31:20 +0200, Paolo Abeni <pabeni@redhat.com> a écrit : > On 5/24/25 12:56 PM, Kory Maincent wrote: > > From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> > > > > This series brings support for budget evaluation strategy in the PSE > > subsystem. PSE controllers can set priorities to decide which ports should > > be turned off in case of special events like over-current. > > > > This patch series adds support for two budget evaluation strategy. > > 1. Static Method: > > > > This method involves distributing power based on PD classification. > > It’s straightforward and stable, the PSE core keeping track of the > > budget and subtracting the power requested by each PD’s class. > > > > Advantages: Every PD gets its promised power at any time, which > > guarantees reliability. > > > > Disadvantages: PD classification steps are large, meaning devices > > request much more power than they actually need. As a result, the power > > supply may only operate at, say, 50% capacity, which is inefficient and > > wastes money. > > > > 2. Dynamic Method: > > > > To address the inefficiencies of the static method, vendors like > > Microchip have introduced dynamic power budgeting, as seen in the > > PD692x0 firmware. This method monitors the current consumption per port > > and subtracts it from the available power budget. When the budget is > > exceeded, lower-priority ports are shut down. > > > > Advantages: This method optimizes resource utilization, saving costs. > > > > Disadvantages: Low-priority devices may experience instability. > > > > The UAPI allows adding support for software port priority mode managed from > > userspace later if needed. > > > > Patches 1-2: Add support for interrupt event report in PSE core, ethtool > > and ethtool specs. > > Patch 3: Adds support for interrupt and event report in TPS23881 driver. > > Patches 4,5: Add support for PSE power domain in PSE core and ethtool. > > Patches 6-8: Add support for budget evaluation strategy in PSE core, > > ethtool and ethtool specs. > > Patches 9-11: Add support for port priority and power supplies in PD692x0 > > drivers. > > Patches 12,13: Add support for port priority in TPS23881 drivers. > > > > Signed-off-by: Kory Maincent (Dent Project) <kory.maincent@bootlin.com> > > I'm sorry, even if this has been posted (just) before the merge window, > I think an uAPI extension this late is a bit too dangerous, please > repost when net-next will reopen after the merge window. Ok I will. Would it be possible to review the netlink part of the series? (patch 2, 7 and 8) Regard, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On Wed, 28 May 2025 15:17:15 +0200 Kory Maincent wrote: > Would it be possible to review the netlink part of the series? > (patch 2, 7 and 8) I'll read the other patches when you repost, but the API in abstract LGTM.
© 2016 - 2025 Red Hat, Inc.