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

Message-ID: <0B9D1A8D-C56F-4B7C-BC62-31633003D7AC@gmail.com>
Date:   Sun, 06 Mar 2022 14:53:42 -0800
From:   "Jonathan Lemon" <jonathan.lemon@...il.com>
To:     "Jakub Kicinski" <kuba@...nel.org>
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 4 Mar 2022, at 19:11, Jakub Kicinski wrote:

> On Fri, 04 Mar 2022 08:50:02 -0800 Jonathan Lemon wrote:
>>> And AFAIU the company delivering the card writes / assembles the
>>> firmware, you can't take FW load from company A and flash it onto
>>> company B's card, no?
>>
>> Nope.  There are currently 3 designs, and 3 firmware variants.
>> I’m looking for a way to tell them apart, especially since the
>> firmware file must match the card.  Suggestions?
>>
>> [root@...ecard net-next]# devlink dev info
>> pci/0000:02:00.0:
>>   driver ptp_ocp
>>   serial_number fc:c2:3d:2e:d7:c0
>>   versions:
>>       fixed:
>>         board.manufacture GOTHAM
>>         board.id RSH04940
>>       running:
>>         fw 21
>> pci/0000:65:00.0:
>>   driver ptp_ocp
>>   serial_number 4e:75:6d:00:00:00
>>   versions:
>>       fixed:
>>         board.manufacture O2S
>>         board.id R3006G000100
>>       running:
>>         fw 9
>> pci/0000:b3:00.0:
>>   driver ptp_ocp
>>   serial_number 3d:00:00:0e:37:73
>>   versions:
>>       fixed:
>>         board.manufacture CLS
>>         board.id R4006G000101
>>       running:
>>         fw 32773
>
> Thanks for the output!
>
> 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.

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?
—
Jonathan