On Tue, 2 Sep 2025 16:43:14 +0200 Kory Maincent 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? 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.
