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]
Date: Thu, 7 Mar 2024 10:22:37 +0200
From: Louis Peens <louis.peens@...igine.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Miller <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
	Fei Qin <fei.qin@...igine.com>, netdev@...r.kernel.org,
	oss-drivers@...igine.com
Subject: Re: [PATCH net-next v2 2/4] nfp: update devlink device info output

On Wed, Feb 28, 2024 at 08:34:58PM -0800, Jakub Kicinski wrote:
> On Wed, 28 Feb 2024 09:51:38 +0200 Louis Peens wrote:
> > +   * - ``part_number``
> > +     - fixed
> > +     - Part number of the entire product
> 
> Belongs in the previous patch..
> 
> >     * - ``fw.bundle_id``
> >       - stored, running
> >       - Firmware bundle id
> > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > index 635d33c0d6d3..5b41338d55c4 100644
> > --- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > +++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
> > @@ -159,7 +159,8 @@ static const struct nfp_devlink_versions_simple {
> >  	{ DEVLINK_INFO_VERSION_GENERIC_BOARD_ID,	"assembly.partno", },
> >  	{ DEVLINK_INFO_VERSION_GENERIC_BOARD_REV,	"assembly.revision", },
> >  	{ DEVLINK_INFO_VERSION_GENERIC_BOARD_MANUFACTURE, "assembly.vendor", },
> > -	{ "board.model", /* code name */		"assembly.model", },
> > +	{ DEVLINK_INFO_VERSION_GENERIC_BOARD_MODEL,	"assembly.model", },
> 
> Ah, it is the code name. I don't understand why you're trying to make
> this generic. I never seen other vendors report code names for boards.
> 
Mostly expanded on this in my previous reply of patch 1, but yes, I
agree. Should have pushed back on review of V1 where moving it to
VERSION_GENERIC was suggested. The one alternative is to still make it
generic, but give it a better name to make it clear that it is a
codename. Still, I don't know if that is generally helpful, happy to
keep it driver only.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ