[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250902164314.12ce43b4@kmaincent-XPS-13-7390>
Date: Tue, 2 Sep 2025 16:43:14 +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>, 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 Mon, 1 Sep 2025 13:31:00 -0700
Jakub Kicinski <kuba@...nel.org> wrote:
> On Fri, 29 Aug 2025 18:28:46 +0200 Kory Maincent wrote:
> > +The ``PD692x0`` drivers implement the following driver-specific parameters.
> > +
> > +.. list-table:: Driver-specific parameters implemented
> > + :widths: 5 5 5 85
> > +
> > + * - Name
> > + - Type
> > + - Mode
> > + - Description
> > + * - ``save_conf``
> > + - bool
> > + - runtime
> > + - Save the current configuration to non-volatile memory using ``1``
> > + attribute value.
> > + * - ``reset_conf``
> > + - bool
> > + - runtime
> > + - Reset the current and saved configuration using ``1`` attribute
> > + value.
>
> 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?
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists