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

[Dmitry Baryshkov]

On Fri, Apr 24, 2026 at 03:34:38PM +0200, Greg Kroah-Hartman wrote:
> 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@xxxxxxxxxxxxxxxx>
> > >>>>>>
> > >>>>>> 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@xxxxxxxxxxxxxxxx>
> > >>>>>> Signed-off-by: Ekansh Gupta <ekansh.gupta@xxxxxxxxxxxxxxxx>
> > >>>>>> Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
> > >>>>>> Signed-off-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
> > >>>>>> ---
> > >>>>>>  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@xxxxxxx/
> > >>>>
> > >>>> 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@xxxxxxxxxxxxxxxx/
> > > 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.

Unfortunately, it is a pattern of IOMMU-only devices. All the actual
programmig is done through IO region associated with the main device,
while subdevices are mostly used for DMA buffer allocation.

> 
> 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 :)
> 
-- 
With best wishes
Dmitry