lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250902134844.7e3593b9@kernel.org>
Date: Tue, 2 Sep 2025 13:48:44 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Kory Maincent <kory.maincent@...tlin.com>
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>, 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
Subject: Re: [PATCH net-next v2 4/4] net: pse-pd: pd692x0: Add devlink
 interface for configuration save/reset

On Tue, 2 Sep 2025 13:42:12 -0700 Jakub Kicinski wrote:
> On Tue, 2 Sep 2025 16:43:14 +0200 Kory Maincent wrote:
> > > Sorry for not offering a clear alternative, but I'm not aware of any
> > > precedent for treating devlink params as action triggers. devlink params
> > > should be values that can be set and read, which is clearly not
> > > the case here:    
> > 
> > Ok.
> > We could save the configuration for every config change and add a reset-conf
> > action to devlink reload uAPI? The drawback it that it will bring a bit of
> > latency (about 110ms) for every config change.
> > 
> > Or adding a new devlink uAPI like a devlink conf but maybe we don't have enough
> > cases to add such generic new uAPI.
> > Or get back to the first proposition to use sysfs. 
> > 
> > What do you think?  
> 
> If you are asking for my real preference, abstracting away whether it's
> doable and justifiable amount of effort for you -- I'd explore using
> flags in the ethtool header to control whether setting is written to
> the flash.

PS. failing that the less uAPI the better. Tho, given that the whole
point here is giving user the ability to write the flash -- asking for
uAPI-light approach feels contradictory.

Taking a step back -- the "save to flash" is something that OEM FW
often supports. But for Linux-based control the "save to flash" should
really be equivalent to updating some user space config. When user
configures interfaces in OpenWRT we're not flashing them into the
device tree... Could you perhaps explain what makes updating the
in-flash config a high-priority requirement for PoE?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ