netdev - Re: [PATCH net-next 1/2] ptp: ocp: add nvmem interface for accessing eeprom

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

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 <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.