netdev - Re: [PATCH v8 net-next 5/5] net: ena: Add PHC documentation

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: <20250402092344.5a12a26a@kernel.org>
Date: Wed, 2 Apr 2025 09:23:44 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Andrew Lunn <andrew@...n.ch>, David Arinzon <darinzon@...zon.com>, David
 Miller <davem@...emloft.net>, netdev@...r.kernel.org, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
 <horms@...nel.org>, Richard Cochran <richardcochran@...il.com>, "Woodhouse,
 David" <dwmw@...zon.com>, "Machulsky, Zorik" <zorik@...zon.com>,
 "Matushevsky, Alexander" <matua@...zon.com>, Saeed Bshara
 <saeedb@...zon.com>, "Wilson, Matt" <msw@...zon.com>, "Liguori, Anthony"
 <aliguori@...zon.com>, "Bshara, Nafea" <nafea@...zon.com>, "Schmeilin,
 Evgeny" <evgenys@...zon.com>, "Belgazal, Netanel" <netanel@...zon.com>,
 "Saidi, Ali" <alisaidi@...zon.com>, "Herrenschmidt, Benjamin"
 <benh@...zon.com>, "Kiyanovski, Arthur" <akiyano@...zon.com>, "Dagan, Noam"
 <ndagan@...zon.com>, "Bernstein, Amit" <amitbern@...zon.com>, "Agroskin,
 Shay" <shayagr@...zon.com>, "Ostrovsky, Evgeny" <evostrov@...zon.com>,
 "Tabachnik, Ofir" <ofirt@...zon.com>, "Machnikowski, Maciek"
 <maciek@...hnikowski.net>, Rahul Rameshbabu <rrameshbabu@...dia.com>, Gal
 Pressman <gal@...dia.com>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Subject: Re: [PATCH v8 net-next 5/5] net: ena: Add PHC documentation

On Tue, 01 Apr 2025 09:46:35 +0100 David Woodhouse wrote:
> On Tue, 2025-04-01 at 09:02 +0100, David Woodhouse wrote:
> > 
> > I think the sysfs control is the best option here.  
> 
> Actually, it occurs to me that the best option is probably a module
> parameter. If you have to take the network down and up to change the
> mode, why not just unload and reload the module?

We have something called devlink params, which support "configuration
modes" (= what level of reset is required to activate the new setting).
Maybe devlink param with cmode of "driver init" would be the best fit?

Module params are annoying because they are scoped to code / module not
instances of the device.