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
