Re: [PATCH v5 02/14] iommu: Add iris-vpu-bus to iommu_buses

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Improper Abstraction and Architectural Violation
- [Medium] Technical Inaccuracy in Commit Message
--

commit 61e281d574bca776edc5305b6c70e207b44fa3e0
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

iommu: Add iris-vpu-bus to iommu_buses

This commit adds the iris_vpu_bus_type to the iommu_buses array in the core
IOMMU subsystem. This allows the bus to register notifier callbacks for
device addition and removal to set up the IOMMU context.

> Add iris-vpu-bus to iommu_buses[] to register the bus notifier callbacks
> for device add and removal events. This ensures that when a device is
> registered on iris-vpu-bus, the notifier triggers dma_configure(),
> which sets up the IOMMU context for that device.

Is this description of the notifier sequence accurate?

Looking at iommu_bus_notifier() in drivers/iommu/iommu.c, the
BUS_NOTIFY_ADD_DEVICE event actually triggers iommu_probe_device(), which
establishes the IOMMU group.

The dma_configure() routine is invoked separately by the driver core,
specifically via really_probe() in drivers/base/dd.c, during driver binding.

Could the commit message be updated to reflect the actual device model flow?

> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index fccdbaf6dbd57..903a8bd118be6 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c

[ ... ]

> @@ -179,6 +180,9 @@ static const struct bus_type * const iommu_buses[] = {
>  #ifdef CONFIG_CDX_BUS
>  	&cdx_bus_type,
>  #endif
> +#ifdef CONFIG_QCOM_IRIS_VPU_BUS
> +	&iris_vpu_bus_type,
> +#endif
>  };
>  
>  /*

Does modifying the generic IOMMU framework's iommu_buses[] array to include
a vendor-specific bus violate abstraction boundaries?

It appears the driver creates a custom bus type (iris_vpu_bus_type) purely
to provide a custom .dma_configure callback for passing an iommu_fid. 

Could standard Linux device model methodologies be used instead, such as
instantiating child platform_device nodes or utilizing the auxiliary_bus
framework, to avoid tight coupling between the core IOMMU subsystem and
vendor-specific driver details?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509-glymur-v5-0-7fbb340c5dbd@oss.qualcomm.com?part=2