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

[Vishnu Reddy]

On 4/24/2026 7:04 PM, 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.
>
> 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 :)

Creating a dedicated bus for iris_vpu is indeed possible, and we had actually
explored this direction in a one of the series. A patch implementing an
iris_vpu bus was posted earlier here,
https://lore.kernel.org/all/20260313-kaanapali-iris-v3-3-9c0d1a67af4b@xxxxxxxxxxxxxxxx/

I'll bring back that approach. Before that, I'll wait a few days to gather any
further opinions or suggestions from anyone else. Then, I'll proceed with
posting the next revision with the iris_vpu bus in place.

>> 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