Re: [PATCH kernel 1/9] pci/tsm: Add TDISP report blob and helpers to parse it

[Alexey Kardashevskiy]

On 26/2/26 13:34, dan.j.williams@xxxxxxxxx wrote:
> Alexey Kardashevskiy wrote:
> [..]
> > I cannot easily see from these what the sizes are. And how many of each.
>
> Same as any other offset+bitmask code, the size is encoded in the accessor.
>
> Arnd caught that I misspoke when I said offset+bitfield.
> > > > #define  PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_TABLE BIT(0)
> > > #define  PCI_TSM_DEVIF_REPORT_MMIO_ATTR_MSIX_PBA BIT(1)
> > > #define  PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_NON_TEE BIT(2)
> > > #define  PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3)
> > > #define  PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16)
> > > #define  PCI_TSM_DEVIF_REPORT_MMIO_SIZE (16)
> > > #define PCI_TSM_DEVIF_REPORT_BASE_SIZE(nr_mmio) (16 + nr_mmio * PCI_TSM_DEVIF_REPORT_MMIO_SIZE)
> > >
> > > Any strong feelings one way or the other? I have a mild preference for
> > > this offset+bitfields approach.
> >
> >
> > My variant is just like this (may be need to put it in the comment):
> >
> > tdi_report_header
> > tdi_report_mmio_range[]
> > tdi_report_footer
>
> Does the kernel have any use for the footer besides conveying it to
> userspace?

PCIe says:

Example of such device specific information include:
• A network device may include receive-side scaling (RSS) related information such as the RSS hash and
mappings to the virtual station interface (VSI) queues, etc.
• A NVMe device may include information about the associated name spaces, mapping of name space to
command queue-pair mappings, etc.
• Accelerators may report capabilities such as algorithms supported, queue depths, etc


Sounds to me like something the device driver would be interested in.

> > imho easier on eyes. I can live with either if the majority votes for it. Thanks.
>
> Aneesh also already has 'structs+bitmask', I will switch to that.

oh I just found it, more or less my version :) I can add pci_tdisp_ prefixes, should I? Thanks,


--
Alexey