Re: [PATCH v2 02/13] drivers: base: Add generic dma context bus

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Apr 24, 2026 at 05:15:02PM +0530, Vishnu Reddy wrote:
> 
> On 4/24/2026 4:43 PM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 24, 2026 at 04:01:13PM +0530, Vishnu Reddy wrote:
> >> On 4/23/2026 7:07 PM, Greg Kroah-Hartman wrote:
> >>> On Thu, Apr 23, 2026 at 06:59:31PM +0530, Vishnu Reddy wrote:
> >>>> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >>>>
> >>>> When a driver needs to create virtual device at runtime and map it to
> >>>> an IOMMU context for memory isolation, there is no common bus available
> >>>> for this purpose. Each driver ends up implementing its own bus type,
> >>>> leading to duplicated logic across multiple drivers.
> >>>>
> >>>> host1x driver implemented its own bus type to attach an IOMMU context to
> >>>> a dynamically created device. The Iris VPU driver now has the same
> >>>> requirement. Rather than duplicating the same bus logic again, a shared
> >>>> bus type is introduced under drivers/base that multiple drivers can use
> >>>> directly.
> >>>>
> >>>> The bus takes care of creating a device and attaching the IOMMU context
> >>>> to it based on the client inputs.
> >>>>
> >>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> >>>> ---
> >>>>  drivers/base/Kconfig            |  3 ++
> >>>>  drivers/base/Makefile           |  1 +
> >>>>  drivers/base/dma_context_bus.c  | 77 +++++++++++++++++++++++++++++++++++++++++
> >>>>  include/linux/dma_context_bus.h | 26 ++++++++++++++
> >>>>  4 files changed, 107 insertions(+)
> >>> as you can not have a device on multiple busses at the same time, this
> >>> makes no sense to me at all.  "dma context" is a bus-specific thing, so
> >>> please add it to the bus that you are wanting it for.  It can't be a
> >>> generic bus as that just doesn't work.
> >>>
> >>> Or what am I missing here?
> >>>
> >>> And why is DMA somehow "special" here from any other hardware attribute?
> >> Let me give brief information which was discussed, in the initial series,
> >> the iris VPU used platform bus for dynamically created devices and we got
> >> the comment/suggestion from Robin to implement a proper bus_type with a
> >> .dma_configure callback.
> >>
> >> https://lore.kernel.org/all/02b3d0f5-f94c-43cd-93af-97cfcf7751b1@arm.com/
> >>
> >> based on the discussion, implemented the dma_context_bus and used for iris
> >> VPU devices instead of platform bus.
> > Why not make a irus_vpu_bus where you can do what you want?
> Initially iris_vpu_bus was introduced, and it was made generic based on the
> discussion,
> 
> https://lore.kernel.org/all/20260227-kaanapali-iris-v2-3-850043ac3933@oss.qualcomm.com/

I don't really see that request here, I see a "make this better and more
generic for other busses" but that does not mean "dump it into
drivers/bus/ for someone else to maintain" :)

> >> Here, the device have only one bus (dma_context_bus), not multiple buses.
> >>
> >> Regarding the "DMA" naming, the core operation of this bus is its
> >> .dma_configure callback, which calls of_dma_configure_id() to map the device
> >> to a corresponding IOMMU stream ID. The name "dma_context" reflects this
> >> purpose.
> >>
> >> I am open to suggestions from you or Robin or anyone else, if there is a
> >> better or preferred way to achieve this, I am happy to consider it and
> >> rework the implementation accordingly.
> > As there is only one user, just make this your own bus please and do all
> > of the needed bus operations for your devices there (i.e. don't hang an
> > "empty" device off of it.)
> The reasoning behind to make it generic was to have more users - host1x,
> Iris VPU, QDA on the generic context bus, instead of each of them having
> their own. Let me know if you suggest to have the iris_vpu_bus.

But you did not add such users here, so how would we know this?

And still, I have no idea what this bus really is doing.  Is it dynamic?
Is it self-describing?  Why not just use aux-bus?  What is it supposed
to be doing and used for?

still totally confused,

greg k-h