From: "Christian König" <christian.koenig@amd.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-buf: add no-op stubs when CONFIG_DMA_SHARED_BUFFER is disabled
Date: Thu, 27 Nov 2025 09:07:06 +0100 [thread overview]
Message-ID: <8d5ae067-e1bf-46a7-9137-d5936197ad5c@amd.com> (raw)
In-Reply-To: <6202945f4af2d10e0fb6602b25ff9cb454c1ee85.1764229204.git.viresh.kumar@linaro.org>
On 11/27/25 08:40, Viresh Kumar wrote:
> Move several dma-buf function declarations under
> CONFIG_DMA_SHARED_BUFFER and provide static inline no-op implementations
> for the disabled case to allow the callers to build when the feature is
> not compiled in.
Good point, but which driver actually needs that?
At least the whole DRM subsystem selects CONFIG_DMA_SHARED_BUFFER and others (like V4L) usually don't compile their whole infrastructure when that option isn't selected.
In other words there should be a concrete example of what breaks in the commit message.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> include/linux/dma-buf.h | 116 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 116 insertions(+)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d58e329ac0e7..06e494d8f6b0 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -568,6 +568,7 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> return !!dmabuf->ops->pin;
> }
>
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> struct device *dev);
> struct dma_buf_attachment *
> @@ -609,4 +610,119 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
> void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
> struct dma_buf *dma_buf_iter_begin(void);
> struct dma_buf *dma_buf_iter_next(struct dma_buf *dmbuf);
> +
> +#else
> +static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> + struct device *dev)
> +{
> + return NULL;
This should probably be an ERR_PTR(-EOPNOTSUPP);
> +}
> +
> +static inline struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> + const struct dma_buf_attach_ops *importer_ops,
> + void *importer_priv)
> +{
> + return NULL;
Same here, ERR_PTR(-EOPNOTSUPP).
> +}
> +
> +static inline void dma_buf_detach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach) { }
> +
> +static inline int dma_buf_pin(struct dma_buf_attachment *attach)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void dma_buf_unpin(struct dma_buf_attachment *attach) { }
> +
> +static inline struct dma_buf *
> +dma_buf_export(const struct dma_buf_export_info *exp_info)
> +{
> + return NULL;
> +}
> +
> +
> +static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +
> +static inline struct dma_buf *dma_buf_get(int fd)
> +{
> + return NULL;
And here ERR_PTR(-EINVAL).
> +}
> +
> +static inline void dma_buf_put(struct dma_buf *dmabuf) { }
> +
> +static inline struct sg_table *
> +dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction)
> +{
> + return NULL;
ERR_PTR(-EINVAL)
> +}
> +
> +static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *,
> + struct sg_table *,
> + enum dma_data_direction) { }
> +
> +static inline void dma_buf_move_notify(struct dma_buf *dma_buf) { }
> +
> +static inline int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
> + enum dma_data_direction dir)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
> + enum dma_data_direction dir)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline struct sg_table *
> +dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
> + enum dma_data_direction direction)
> +{
> + return NULL;
ERR_PTR(-EINVAL)
> +}
> +
> +static inline void
> +dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
> + struct sg_table *sg_table,
> + enum dma_data_direction direction) { }
> +
> +static inline int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
> + unsigned long)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)
> +{ }
> +
> +static inline int dma_buf_vmap_unlocked(struct dma_buf *dmabuf,
> + struct iosys_map *map)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf,
> + struct iosys_map *map) { }
> +
> +static inline struct dma_buf *dma_buf_iter_begin(void)
> +{
> + return NULL;
> +}
> +
> +static inline struct dma_buf *dma_buf_iter_next(struct dma_buf *dmbuf)
> +{
> + return NULL;
> +}
Those two are only for BPF and not driver use.
Regards,
Christian.
> +#endif /* CONFIG_DMA_SHARED_BUFFER */
> #endif /* __DMA_BUF_H__ */
next prev parent reply other threads:[~2025-11-27 8:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 7:40 [PATCH] dma-buf: add no-op stubs when CONFIG_DMA_SHARED_BUFFER is disabled Viresh Kumar
2025-11-27 8:07 ` Christian König [this message]
2025-11-27 8:23 ` Viresh Kumar
2025-11-27 10:26 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d5ae067-e1bf-46a7-9137-d5936197ad5c@amd.com \
--to=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox