git: 2f176a2b2010 - main - pciconf: Fix up pciconf -lc output

[John Baldwin]

On 6/1/21 8:56 AM, David Bright wrote:
> The branch main has been updated by dab:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=2f176a2b20107f7a9132242223e9eef657400514
> 
> commit 2f176a2b20107f7a9132242223e9eef657400514
> Author:     David Bright <dab at FreeBSD.org>
> AuthorDate: 2021-05-24 19:02:43 +0000
> Commit:     David Bright <dab at FreeBSD.org>
> CommitDate: 2021-06-01 15:55:44 +0000
> 
>      pciconf: Fix up pciconf -lc output
>      
>      The pciconf command fails to emit newlines when particular ecap field
>      values are seen. Fix them up. This has been seen on several systems at
>      $JOB. The documentation for PCI capabilities says that capability
>      type 0 should not be used once the spec for PCI capabilities was
>      published, but that seems more wishful-thinking than reality. pciconf
>      also chooses not to print fields related to field values that are
>      zero, but it seems several of these fields are zero on actual
>      hardware.
>      
>      Reviewed by:    vangyzen, imp, Bret Ketchum (Bret.Ketchum at dell.com)
>      Sponsored by:   Dell EMC Isilon
>      Submitted by:   Robert Herndon (Robert.Herndon at dell.com)
>      Differential Revision: https://reviews.freebsd.org/D30441

Are the ecap registers actually valid for version 1 in this case?  That is,
should we treat version 0 as being version 1?  The current checks are just
defensive coding for not parsing something unless we know it is valid.
If the only version 0 caps in practice are always compatible with version 1
we could just treat 0 as if it were 1.

-- 
John Baldwin