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

[Alexey Kardashevskiy <aik@amd.com>]

On 26/2/26 13:34, dan.j.williams@intel.com 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