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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 7 Mar 2022 13:31:16 -0800
From:   Jakub Kicinski <>
To:     "Jonathan Lemon" <>
Subject: Re: [PATCH net-next 1/2] ptp: ocp: add nvmem interface for
 accessing eeprom

On Sun, 06 Mar 2022 14:53:42 -0800 Jonathan Lemon wrote:
> > In my limited experience the right fit here would be PCI Subsystem
> > Vendor ID. This will also allow lspci to pretty print the vendor
> > name like:
> >
> > 30:00.0 Dunno controller: OCP Time Card whatever (Vendor X)  
> Unfortunately, that’s not going to work for a while, until the
> relevant numbers get through the PCI approval body.

There's no approval for sub ids. Vendor whose ID is used can 
do whatever they want there.

> I believe that board.manufacture is correct.  In this particular
> example, the 3 boards are fabbed in 3 different locations, but
> there are 2 “vendors”.
> So what this does is identify the contractor who assembled the
> particular board.  Isn’t that what this is intended for?

Not really, as I explained this field is to differentiate _identical_
board designs delivered by different fabs. I did not see that case in
your example output. The point of devlink info is to expose the
information not covered in standard PCI device fields, so the industry
standard approach takes precedence.

Powered by blists - more mailing lists