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

[Vishnu Reddy <busanna.reddy@oss.qualcomm.com>]

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.

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.

>
> still totally confused,
>
> greg k-h