public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Pavan Chebbi <pavan.chebbi@broadcom.com>,
	Michael Chan <mchan@broadcom.com>,
	Potnuri Bharat Teja <bharat@chelsio.com>
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: PCI VPD checksum ambiguity
Date: Tue, 1 Apr 2025 23:51:07 +0200	[thread overview]
Message-ID: <b37b02ec-59fb-4b3b-8e51-ae866eb8ecc9@gmail.com> (raw)
In-Reply-To: <20250401205544.GA1620308@bhelgaas>

On 01.04.2025 22:55, Bjorn Helgaas wrote:
> Hi,
> 
> The PCIe spec is ambiguous about how the VPD checksum should be
> computed, and resolving this ambiguity might break drivers.
> 
> PCIe r6.0 sec 6.27 says only the VPD-R list should be included in the
> checksum:
> 
>   One VPD-R (10h) tag is used as a header for the read-only keywords.
>   The VPD-R list (including tag and length) must checksum to zero.
> 

This requirement I don't find in the PCI 3.0 spec, not sure with which
version it was added. Interestingly this doesn't even require the
presence of a RV keyword. Or the presence of the RV keyword is
implicitly assumed.

Maybe this part isn't meant literally. I can imagine they wanted to
clarify that checksum calculation excludes the VPD-W area.
And unfortunately they weren't precise enough, and introduced the
ambiguity you found.


> But sec 6.27.2.2 says "all bytes in VPD ... up to the checksum byte":
> 
>   RV   The first byte of this item is a checksum byte. The checksum is
>        correct if the sum of all bytes in VPD (from VPD address 0 up
>        to and including this byte) is zero.
> 

This one can be found identically in the PCI v3.0 spec already:

The checksum is correct if the sum of all bytes in VPD (from
VPD address 0 up to and including this byte) is zero.

I don't think they want to break backwards-compatibility, therefore
this requirement should still be valid.

> These are obviously different unless VPD-R happens to be the first
> item in VPD.  But sec 6.27 and 6.27.2.1 suggest that the Identifier
> String item should be the first item, preceding the VPD-R list:
> 
>   The first VPD tag is the Identifier String (02h) and provides the
>   product name of the device. [6.27]
> 
>   Large resource type Identifier String (02h)
> 
>     This tag is the first item in the VPD storage component. It
>     contains the name of the add-in card in alphanumeric characters.
>     [6.27.2.1, Table 6-23]
> 
> I think pci_vpd_check_csum() follows sec 6.27.2.2: it sums all the
> bytes in the buffer up to and including the checksum byte of the RV
> keyword.  The range starts at 0, not at the beginning of the VPD-R
> read-only list, so it likely includes the Identifier String.
> 
> As far as I can tell, only the broadcom/tg3 and chelsio/cxgb4/t4
> drivers use pci_vpd_check_csum().  Of course, other drivers might
> compute the checksum themselves.
> 
> Any thoughts on how this spec ambiguity should be resolved?
> 
> Any idea how devices in the field populate their VPD?
> 
> Can you share any VPD dumps from devices that include an RV keyword
> item?
> 

I have only very dated devices which likely date back to before
the existence of PCIe r6.0. So their VPD dump may not really help.

IIRC there's an ongoing discussion regarding making VPD content
user-readable on mlx5 devices. Maybe check with the Mellanox/Nvidia
guys how they interpret the spec and implemented VPD checksumming.

> Bjorn


  reply	other threads:[~2025-04-01 21:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01 20:55 PCI VPD checksum ambiguity Bjorn Helgaas
2025-04-01 21:51 ` Heiner Kallweit [this message]
2025-04-01 22:35   ` Bjorn Helgaas
2025-04-02 10:33     ` Pavan Chebbi
2025-04-07 22:22       ` Bjorn Helgaas
2025-04-10 16:21 ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b37b02ec-59fb-4b3b-8e51-ae866eb8ecc9@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=bharat@chelsio.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pavan.chebbi@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox