[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220307133116.24815d64@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
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