Message-ID: <20250922182002.6948586f@kmaincent-XPS-13-7390>
Date: Mon, 22 Sep 2025 18:20:02 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jiri Pirko
 <jiri@...nulli.us>, Simon Horman <horms@...nel.org>, Jonathan Corbet
 <corbet@....net>, Donald Hunter <donald.hunter@...il.com>,
 kernel@...gutronix.de, Dent Project <dentproject@...uxfoundation.org>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, Maxime Chevallier
 <maxime.chevallier@...tlin.com>, linux-doc@...r.kernel.org, Kyle Swenson
 <kyle.swenson@....tech>, Luka Perkov <luka.perkov@...tura.hr>, Robert Marko
 <robert.marko@...tura.hr>, Sridhar Rao <srao@...uxfoundation.org>
Subject: Re: [PATCH net-next v3 0/5] net: pse-pd: pd692x0: Add permanent
 configuration management support

Hello Jakub,

On Wed, 17 Sep 2025 14:19:12 -0700
Jakub Kicinski <kuba@...nel.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

Powered by blists - more mailing lists