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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The newly added dma-buf API `dma_buf_get_pci_tph()` and its corresponding `get_pci_tph` callback are missing from the centralized dma-buf locking convention documentation.
--

commit aa25de1b77cd2b1778e96e6bffe1b1b6ce39fd9c
Author: Zhiping Zhang <zhipingz@meta.com>

dma-buf: add optional get_pci_tph() callback

This commit adds an optional get_pci_tph callback to dma_buf_ops and a
corresponding wrapper function dma_buf_get_pci_tph() for importers. These
allow importers to retrieve PCIe TLP Processing Hint (TPH) metadata for
peer-to-peer DMA. Both the callback and the wrapper require the dma-buf
reservation lock to be held.

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d504c636dc294..7a4c9b0d5dab4 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.
> + */
> +int dma_buf_get_pci_tph(struct dma_buf *dmabuf, bool extended,
> +			u16 *steering_tag, u8 *ph)
> +{
> +	dma_resv_assert_held(dmabuf->resv);

[Severity: Low]
This isn't a bug, but should dma_buf_get_pci_tph() be added to the list of
functions in the "DOC: locking convention" block earlier in this file?

The centralized documentation block serves as a single source of truth for
importers by listing all functions that require the dma-buf reservation lock,
such as dma_buf_pin() and dma_buf_vmap(). Adding this new function to that
list would help keep the locking documentation complete.

> +
> +	if (!dmabuf->ops->get_pci_tph)
> +		return -EOPNOTSUPP;
> +
> +	return dmabuf->ops->get_pci_tph(dmabuf, extended, steering_tag, ph);
> +}
> +EXPORT_SYMBOL_NS_GPL(dma_buf_get_pci_tph, "DMA_BUF");

[ ... ]

> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d1203da56fc5f..53b2686ad8fc6 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
[ ... ]
> @@ -113,6 +113,26 @@ struct dma_buf_ops {
>  	 */
>  	void (*unpin)(struct dma_buf_attachment *attach);
>  
> +	/**
> +	 * @get_pci_tph:
> +	 *
> +	 * Retrieve PCIe TLP Processing Hint (TPH) steering metadata for
> +	 * this buffer so an importer can program a matching ST/PH hint on
> +	 * outbound TLPs targeting the exporter for peer-to-peer DMA.
> +	 *
> +	 * @dmabuf: DMA buffer for which to retrieve TPH metadata
> +	 * @extended: false for 8-bit ST, true for 16-bit Extended ST
> +	 * @steering_tag: Returns the raw TPH steering tag for the requested
> +	 *                namespace
> +	 * @ph: Returns the TPH processing hint (2-bit value)
> +	 *
> +	 * Optional callback for dma_buf_get_pci_tph(). Called with
> +	 * &dma_buf.resv held. Returns 0 on success or -EOPNOTSUPP when
> +	 * the exporter has no metadata for the requested namespace.
> +	 */
> +	int (*get_pci_tph)(struct dma_buf *dmabuf, bool extended,
> +			   u16 *steering_tag, u8 *ph);

[Severity: Low]
Similarly, should &dma_buf_ops.get_pci_tph() be appended to the list of
callbacks in the same "DOC: locking convention" block?

The existing documentation explicitly calls out exporter callbacks that are
invoked with the locked dma-buf reservation, so updating it here would keep
the locking contract documentation consistent.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630224328.3218796-1-zhipingz@meta.com?part=2