Re: [PATCH v10 2/4] dma-buf: add optional get_pci_tph() callback

["Christian König" <christian.koenig@amd.com>]

On 7/1/26 19:53, Zhiping Zhang wrote:
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index d504c636dc29..7a4c9b0d5dab 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1144,6 +1144,31 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
>>>  }
>>>  EXPORT_SYMBOL_NS_GPL(dma_buf_unpin, "DMA_BUF");
>>>
>>> +/**
>>> + * dma_buf_get_pci_tph - Retrieve PCIe TLP Processing Hint (TPH) metadata
>>> + * @dmabuf: DMA buffer to query
>>> + * @extended: false for 8-bit ST, true for 16-bit Extended ST
>>> + * @steering_tag: returns the raw steering tag for the requested namespace
>>> + * @ph: returns the TPH processing hint
>>> + *
>>> + * Wrapper for the optional &dma_buf_ops.get_pci_tph callback.
>>> + *
>>> + * Must be called with &dma_buf.resv held. Returns -EOPNOTSUPP if the
>>> + * exporter does not implement the callback or has no metadata for the
>>> + * requested namespace.
>>
>> Please add something like this:
>>
>> * The returned information is only valid till the next invalidate_mappings() callback from the exporter and should be re-queried when a new mapping is created after invalidation.
>>
> 
> Thanks, Will do in v11!
> 
>> Apart from that it looks good to me, but I still think we need some kind of example that this works for other DMA-buf users as well.
>>
>> Just demonstrating that this also works with some simple FPGA or similar PCIe endpoint should be sufficient.
>>
>> Regards,
>> Christian.
>>
> 
> On v10, I have validated a second importer: another vendor's NIC
> (driver not upstream yet, so locally patched to
> call dma_buf_get_pci_tph). A PCIe analyzer confirms the TLP steering
> tag matches the exporter's for both mlx5/ConnectX-8
> and this second NIC — two unrelated importer drivers exercising the
> API end-to-end.

That sounds like it would be sufficient, yes.

Thanks,
Christian.

> 
> Thanks,
> Zhiping