Message-ID: <20250903145540.42c51417@kmaincent-XPS-13-7390>
Date: Wed, 3 Sep 2025 14:55:40 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, 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>, 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>
Subject: Re: [PATCH net-next v2 4/4] net: pse-pd: pd692x0: Add devlink
 interface for configuration save/reset

On Wed, 3 Sep 2025 12:59:42 +0200
Oleksij Rempel <o.rempel@...gutronix.de> wrote:

> On Wed, Sep 03, 2025 at 11:10:25AM +0200, Kory Maincent wrote:
> > On Wed, 3 Sep 2025 09:10:28 +0200
> > Oleksij Rempel <o.rempel@...gutronix.de> wrote:
> >   
> > > On Tue, Sep 02, 2025 at 01:48:44PM -0700, Jakub Kicinski wrote:  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> > > 
> > > I think the main use case question is: what happens if the application
> > > CPU reboots?
> > > Do we go back to “safe defaults”? But what are safe defaults - that can
> > > vary a lot between systems.  
> > 
> > In case of CPU reboot, the port matrix will be flashed, which means the
> > controller is restarted and the ports get disconnected.
> > Therefore indeed we will go back to default settings.
> >    
> > > In many setups, if the CPU reboots it also means the bridge is down, so
> > > there is no packet forwarding. In that case, does it even make sense to
> > > keep providing PoE power if the networking part is non-functional?  
> > 
> > It depends, we might not want to reboot the Powered Devices if the switch
> > reboot. I don't currently have specific case in mind which could need this
> > behavior.
> > Mainly, the Dent Project final aim was to support mainline all the features
> > supported in their poed tool.
> > https://github.com/dentproject/poed/blob/main/dentos-poe-agent/opt/poeagent/docs/Userguide
> >   
> > > Another angle: does it make sense to overwrite the hardware power-on
> > > defaults each time the system starts? Or should we rather be able to
> > > read back the stored defaults from the hardware into the driver and work
> > > with them?  
> > 
> > Yes that is one of the design proposition, but we will still need a way to
> > reset the conf as said before.
> >   
> > > Does anyone here have field experience with similar devices? How are
> > > these topics usually handled outside of my bubble?  
> > 
> > Kyle any field experience on this?  
> 
> 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.
> 
> So the question is how to communicate and control this:
> 
> Option A - Vendor tool writes a fixed config to NVM (EEPROM)
> Pro: matches "pre-designed, don't touch" model; PDs come up early
> without Linux.
> Con: needs extra vendor tooling; hard to keep in sync with what
> userspace shows; Linux may not know what is in NVM unless we
> read/reflect it.
> 
> Option B - Do all changes in RAM, then one explicit "commit to NVM"
> Pro: one write; predictable latency hit only on commit; maps to a
> "transaction/commit" model.
> Con: what if the controller discarded some changes during the session?
> We would need a clear commit status and a way to report which settings
> actually stuck.
> 
> Option C - Write-through: every change also goes to NVM
> Pro: if the system resets, config is always up to date.
> Con: adds about 50-110 ms per change on this hardware; may be too slow
> for interactive tools or batch reconfig.
> 
> From API side, if write-through is possible on this hardware, we can
> likely make this per-port and per-setting:
> 
> ethtool per-port setters can take a "persist=1" flag. Driver applies the
> change and also writes it to NVM for that port.

The thing is, as it is not per port save if we use one time this ethtool flag
all the other ports configurations will also be saved. This could mislead users
by letting them believe they can save configuration for one specific port
without saving all the other ports config.
I think saving the config to NVM globally on each config change is a better
idea.

> If a particular setting (bit/field) cannot be persisted by the
> controller/NVM, the driver returns an error for the whole request. Userspace
> then knows persistence is not supported for that item.
>
> Factory reset:
> If hardware supports per-port defaults in NVM, provide a per-port
> factory_reset op.
>
> Do PD692x0 supports per-port save/restore functionality?

No it is not per port but at the PSE controller level for both.

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

Powered by blists - more mailing lists