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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dc253b7be5082d5623ae8865d5d75eb3df788516.camel@infradead.org>
Date: Tue, 01 Apr 2025 09:46:35 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Andrew Lunn <andrew@...n.ch>, David Arinzon <darinzon@...zon.com>
Cc: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
 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, 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?

I understand there's a policy about that too, because we don't want
bespoke module parameters changing the behaviour of network devices,
which ought to be uniform. But this isn't changing the behaviour of the
network device per se.

Think of it as three drivers. One for the PCI device itself, which
registers one or two auxdevs (depending on a module option). This
module option is not on the network device driver. Then there's the
netdev and the PTP which bind to those auxdevs.

Now in *practice*, actually using auxdev is overkill and not consistent
with what other network+PTP drivers do, and I think it should remain in
a single driver. I'm using the separation to explain why a module
parameter wouldn't be conceptually on the "network" device, and why we
should consider this one of the cases where "policy" is just a
euphemism for not doing our own thinking.

Just put a module param on the PCI device driver and have done with it.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)