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

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

On Fri, Apr 24, 2026 at 06:12:09PM +0530, Vishnu Reddy wrote:
> 
> On 4/24/2026 5:25 PM, Greg Kroah-Hartman wrote:
> > 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?
> 
> This bus will allow users to create a dynamic device and map to IOMMU stream
> ID via .dma_configure callback which calls the of_dma_confgure_id() based on
> the user inputs. This bus is under the iommu_buses list to register for bus
> notifier callbacks for iommu_probe_device() and iommu_release_device() during
> add and remove.

But a device is nothing on its own.  You can not just have a random
'struct device' hanging out there that does nothing but iommu, right?
It should be doing something else that is very "bus" specific.

Again, why not create a bus for your hardware type and have that control
the bindings of drivers to the devices, like it should be done.  You
better not be creating platform devices for these things :)

> auxilary bus don't have the .dma_callback and bus notifier callbacks where it
> can do iommu_probe_device() and iommu_release_device(). iommu_release_device(),
> being a static api, need to be called from bus notifier callbacks which should
> be under the list of iommu_buses.

True, because aux bus devices don't do that directly, they are "sharing"
resources with their parent device and something has to mediate for it.
So yes, you are right, that is not a good idea.  Make a custom bus type
instead please.

thanks,

greg k-h