netdev - Re: [PATCH net-next 12/15] sfc_ef100: add EF100 to NIC-revision enumeration

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]

Date:   Wed, 1 Jul 2020 23:23:40 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     David Miller <davem@...emloft.net>, <kuba@...nel.org>
CC:     <linux-net-drivers@...arflare.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 12/15] sfc_ef100: add EF100 to NIC-revision
 enumeration

On 01/07/2020 20:44, David Miller wrote:
> Or is this code used as a library by two "drivers"?
Yes, it is; there will be a second module 'sfc_ef100.ko'which this
 file will be linked into and which will set efx->type to one with
 an EF100 revision.

Although tbh I have been wondering about another approach to
 ethtool_get_drvinfo: we could have a const char [] in each driver's
 non-common parts, holding KBUILD_MODNAME, which ethtool_common.c
 could just reference, rather than looking at efx->type->revision
 and relying on the rest of the driver to set it up right.
Since it looks like I'll need to respin this series anyway, I'll try
 that and see if it works — it seems cleaner to me.

-ed