From: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>

This patch series introduces a new devlink-conf uAPI to manage device
configuration stored in non-volatile memory. This provides a standardized
interface for devices that need to persist configuration changes across
reboots. The uAPI is designed to be generic and can be used by any device
driver that manages persistent configuration storage.

The permanent configuration allows settings to persist across device
resets and power cycles, providing better control over PSE behavior
in production environments.

The new uAPI support is preceded by 3 patches that do house keeping.

Signed-off-by: Kory Maincent (Dent Project) <kory.maincent@bootlin.com>
---
Changes in v3:
- Move on from devlink param to new devlink conf uAPI. This new uAPI
  manage device configuration stored in non-volatile memory.
- Link to v2: https://lore.kernel.org/r/20250829-feature_poe_permanent_conf-v2-0-8bb6f073ec23@bootlin.com

Changes in v2:
- Move from sysfs interface to devlink interface for the permanent
  configuration support
- Remove the __free macro from pd692x0 driver following net policy.
- Link to v1: https://lore.kernel.org/r/20250822-feature_poe_permanent_conf-v1-0-dcd41290254d@bootlin.com

---
Kory Maincent (5):
      net: pse-pd: pd692x0: Replace __free macro with explicit kfree calls
      net: pse-pd: pd692x0: Separate configuration parsing from hardware setup
      docs: devlink: Sort table of contents alphabetically
      devlink: Add devlink-conf uAPI for NV memory management
      net: pse-pd: pd692x0: Add devlink interface for configuration save/reset

 Documentation/netlink/specs/devlink.yaml          |  23 ++
 Documentation/networking/devlink/devlink-conf.rst |  22 ++
 Documentation/networking/devlink/index.rst        |  22 +-
 Documentation/networking/devlink/pd692x0.rst      |  24 ++
 MAINTAINERS                                       |   3 +
 drivers/net/pse-pd/pd692x0.c                      | 280 ++++++++++++++++++----
 include/net/devlink.h                             |  20 ++
 include/uapi/linux/devlink.h                      |   4 +
 net/devlink/Makefile                              |   3 +-
 net/devlink/conf.c                                |  31 +++
 net/devlink/netlink.c                             |   2 +-
 net/devlink/netlink_gen.c                         |  20 +-
 net/devlink/netlink_gen.h                         |   3 +-
 13 files changed, 400 insertions(+), 57 deletions(-)
---
base-commit: c237892eba83664b7265c46ffe3865a876e720ed
change-id: 20250813-feature_poe_permanent_conf-ec640dace1f2

Best regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Mon, 15 Sep 2025 19:06:25 +0200 Kory Maincent wrote:
> This patch series introduces a new devlink-conf uAPI to manage device
> configuration stored in non-volatile memory. This provides a standardized
> interface for devices that need to persist configuration changes across
> reboots. The uAPI is designed to be generic and can be used by any device
> driver that manages persistent configuration storage.
> 
> The permanent configuration allows settings to persist across device
> resets and power cycles, providing better control over PSE behavior
> in production environments.

I'm still unclear on the technical justification for this.
"There's a tool in another project which does it this way"
is not usually sufficient upstream. For better or worse we
like to re-implement things from first principles.

Could you succinctly explain why "saving config" can't be implemented
by some user space dumping out ethtool configuration, saving it under
/etc, and using that config after reboot. A'la iptables-save /
iptables-restore?

(I'll apply patch 3 now, looks like a nice cleanup)

On Tue, 16 Sep 2025 16:54:40 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Mon, 15 Sep 2025 19:06:25 +0200 Kory Maincent wrote:
> > This patch series introduces a new devlink-conf uAPI to manage device
> > configuration stored in non-volatile memory. This provides a standardized
> > interface for devices that need to persist configuration changes across
> > reboots. The uAPI is designed to be generic and can be used by any device
> > driver that manages persistent configuration storage.
> > 
> > The permanent configuration allows settings to persist across device
> > resets and power cycles, providing better control over PSE behavior
> > in production environments.  
> 
> I'm still unclear on the technical justification for this.
> "There's a tool in another project which does it this way"
> is not usually sufficient upstream. For better or worse we
> like to re-implement things from first principles.
> 
> Could you succinctly explain why "saving config" can't be implemented
> by some user space dumping out ethtool configuration, saving it under
> /etc, and using that config after reboot. A'la iptables-save /
> iptables-restore?

I think the only reason to save the config in the NVM instead of the userspace
is to improve boot time. As Oleksij described:
> I can confirm a field case from industrial/medical gear. Closed system,
> several modules on SPE, PoDL for power. Requirement: power the PDs as
> early as possible, even before Linux. The box boots faster if power-up
> and Linux init run in parallel. In this setup the power-on state is
> pre-designed by the product team and should not be changed by Linux at
> runtime.

He told me that he also had added support for switches in Barebox for the
same reason, the boot time. I don't know if it is a reasonable reason to add it
in Linux.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Wed, 17 Sep 2025 11:46:55 +0200 Kory Maincent wrote:
> > On Mon, 15 Sep 2025 19:06:25 +0200 Kory Maincent wrote:  
> > > This patch series introduces a new devlink-conf uAPI to manage device
> > > configuration stored in non-volatile memory. This provides a standardized
> > > interface for devices that need to persist configuration changes across
> > > reboots. The uAPI is designed to be generic and can be used by any device
> > > driver that manages persistent configuration storage.
> > > 
> > > The permanent configuration allows settings to persist across device
> > > resets and power cycles, providing better control over PSE behavior
> > > in production environments.    
> > 
> > I'm still unclear on the technical justification for this.
> > "There's a tool in another project which does it this way"
> > is not usually sufficient upstream. For better or worse we
> > like to re-implement things from first principles.
> > 
> > Could you succinctly explain why "saving config" can't be implemented
> > by some user space dumping out ethtool configuration, saving it under
> > /etc, and using that config after reboot. A'la iptables-save /
> > iptables-restore?  
> 
> I think the only reason to save the config in the NVM instead of the userspace
> is to improve boot time. As Oleksij described:
> > I can confirm a field case from industrial/medical gear. Closed system,
> > several modules on SPE, PoDL for power. Requirement: power the PDs as
> > early as possible, even before Linux. The box boots faster if power-up
> > and Linux init run in parallel. In this setup the power-on state is
> > pre-designed by the product team and should not be changed by Linux at
> > runtime.  
> 
> He told me that he also had added support for switches in Barebox for the
> same reason, the boot time. I don't know if it is a reasonable reason to add it
> in Linux.

Right, subjectively I focused on the last sentence of Oleksij's reply.
I vote we leave it out for now.

Hello Jakub,

On Wed, 17 Sep 2025 14:19:12 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Wed, 17 Sep 2025 11:46:55 +0200 Kory Maincent wrote:
> > > On Mon, 15 Sep 2025 19:06:25 +0200 Kory Maincent wrote:    
>  [...]  
> > > 
> > > I'm still unclear on the technical justification for this.
> > > "There's a tool in another project which does it this way"
> > > is not usually sufficient upstream. For better or worse we
> > > like to re-implement things from first principles.
> > > 
> > > Could you succinctly explain why "saving config" can't be implemented
> > > by some user space dumping out ethtool configuration, saving it under
> > > /etc, and using that config after reboot. A'la iptables-save /
> > > iptables-restore?    
> > 
> > I think the only reason to save the config in the NVM instead of the
> > userspace is to improve boot time. As Oleksij described:  
> > > I can confirm a field case from industrial/medical gear. Closed system,
> > > several modules on SPE, PoDL for power. Requirement: power the PDs as
> > > early as possible, even before Linux. The box boots faster if power-up
> > > and Linux init run in parallel. In this setup the power-on state is
> > > pre-designed by the product team and should not be changed by Linux at
> > > runtime.    
> > 
> > He told me that he also had added support for switches in Barebox for the
> > same reason, the boot time. I don't know if it is a reasonable reason to
> > add it in Linux.  
> 
> Right, subjectively I focused on the last sentence of Oleksij's reply.
> I vote we leave it out for now.

I would like to restart the discussion as I have one more argument besides the
boot time optimization coming from Luka Perkov in CC.

According to him, not having this feature supported also brings an issue across
reboot:
"When a network switch reboots, any devices receiving Power over
Ethernet (PoE) from that switch will lose power unless the PoE
configuration is persisted across the reboot cycle. This creates a
significant operational impact: WiFi access points and other
PoE-powered devices will experience an unplanned hard power loss,
forcing them offline without any opportunity for graceful shutdown.

The critical issue is not the impact on the switch itself, but rather
the cascading effect on all dependent infrastructure. Without
kernel-level persistence of PoE settings, a simple switch reboot
(whether for maintenance, updates, or recovery) forces all connected
PoE devices into an abrupt power cycle. This results in extended
downtime as these devices must complete their full boot sequence once
power is restored, rather than remaining operational throughout the
switch's reboot process."

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Mon, 22 Sep 2025 18:20:02 +0200 Kory Maincent wrote:
> > > I think the only reason to save the config in the NVM instead of the
> > > userspace is to improve boot time. As Oleksij described:    
> > > 
> > > He told me that he also had added support for switches in Barebox for the
> > > same reason, the boot time. I don't know if it is a reasonable reason to
> > > add it in Linux.    
> > 
> > Right, subjectively I focused on the last sentence of Oleksij's reply.
> > I vote we leave it out for now.  
> 
> I would like to restart the discussion as I have one more argument besides the
> boot time optimization coming from Luka Perkov in CC.
> 
> According to him, not having this feature supported also brings an issue across
> reboot:
> "When a network switch reboots, any devices receiving Power over
> Ethernet (PoE) from that switch will lose power unless the PoE
> configuration is persisted across the reboot cycle. This creates a
> significant operational impact: WiFi access points and other
> PoE-powered devices will experience an unplanned hard power loss,
> forcing them offline without any opportunity for graceful shutdown.
> 
> The critical issue is not the impact on the switch itself, but rather
> the cascading effect on all dependent infrastructure. Without
> kernel-level persistence of PoE settings, a simple switch reboot
> (whether for maintenance, updates, or recovery) forces all connected
> PoE devices into an abrupt power cycle. This results in extended
> downtime as these devices must complete their full boot sequence once
> power is restored, rather than remaining operational throughout the
> switch's reboot process."

Any sort of hot reset that maintains the pre-existing configuration 
and doesn't issue resets is orthogonal to storing the configuration
into the flash.

On Mon, 22 Sep 2025 11:02:20 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Mon, 22 Sep 2025 18:20:02 +0200 Kory Maincent wrote:
>  [...]  
> > > 
> > > Right, subjectively I focused on the last sentence of Oleksij's reply.
> > > I vote we leave it out for now.    
> > 
> > I would like to restart the discussion as I have one more argument besides
> > the boot time optimization coming from Luka Perkov in CC.
> > 
> > According to him, not having this feature supported also brings an issue
> > across reboot:
> > "When a network switch reboots, any devices receiving Power over
> > Ethernet (PoE) from that switch will lose power unless the PoE
> > configuration is persisted across the reboot cycle. This creates a
> > significant operational impact: WiFi access points and other
> > PoE-powered devices will experience an unplanned hard power loss,
> > forcing them offline without any opportunity for graceful shutdown.
> > 
> > The critical issue is not the impact on the switch itself, but rather
> > the cascading effect on all dependent infrastructure. Without
> > kernel-level persistence of PoE settings, a simple switch reboot
> > (whether for maintenance, updates, or recovery) forces all connected
> > PoE devices into an abrupt power cycle. This results in extended
> > downtime as these devices must complete their full boot sequence once
> > power is restored, rather than remaining operational throughout the
> > switch's reboot process."  
> 
> Any sort of hot reset that maintains the pre-existing configuration 
> and doesn't issue resets is orthogonal to storing the configuration
> into the flash.

Indeed if the switch reboot and the PSE lose its power supply, the devices will
in any cases face a power loss. While if the PSE does not lose its power the
configuration won't be reset whether there is a permanent configuration or
not. We just need to detect during the boot if the port matrix has already
been flashed to not reconfigure all the ports.  
This argument is indeed not relevant.

Luka any other arguments in favor of permanent configuration support?

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com