On Tue, 2 Sep 2025 16:43:14 +0200 Kory Maincent wrote:

quoted

On Fri, 29 Aug 2025 18:28:46 +0200 Kory Maincent wrote:  

quoted

+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?

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.