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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Mar 2022 13:31:16 -0800 From: Jakub Kicinski <kuba@...nel.org> To: "Jonathan Lemon" <jonathan.lemon@...il.com> Cc: netdev@...r.kernel.org, richardcochran@...il.com, davem@...emloft.net, kernel-team@...com 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