Re: [PATCH v7 02/12] iommu: Add iris-vpu-bus to iommu_buses

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Adding a vendor-specific media driver virtual bus (`iris_vpu_bus_type`) to the core `iommu_buses` array is an architectural layering violation and abuses the device model.
--

commit 237441c1b5f7b6f9432bcd95591b1105966e57b0
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

iommu: Add iris-vpu-bus to iommu_buses

Add iris_vpu_bus_type to the iommu_buses array in the core IOMMU
subsystem so that the bus notifier callbacks are registered for
device addition and removal events.

> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index e8f13dcebbde5..fe51600953ceb 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -13,6 +13,7 @@
>  #include <linux/bug.h>
>  #include <linux/types.h>
>  #include <linux/init.h>
> +#include <linux/iris_vpu_bus.h>

[Severity: High]
Does this introduce a layering violation by pulling a vendor-specific media
driver header directly into the core IOMMU framework?

>  #include <linux/export.h>
>  #include <linux/slab.h>
>  #include <linux/errno.h>

[ ... ]

> @@ -200,6 +201,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
>  };

[Severity: High]
Is it appropriate to add an artificial software bus created inside a single
media driver to the system-level hardware interconnects list here?

The iommu_buses array is generally intended for system-level hardware
interconnects like PCI or Platform buses. Modifying the core framework to
accommodate a vendor driver's private bus seems to couple subsystems together
incorrectly.

Additionally, because CONFIG_QCOM_IRIS_VPU_BUS is defined as a bool in the
driver's Kconfig and registers its bus using a postcore_initcall, this forces
the custom bus code into the core kernel binary even when the media driver is
built as a loadable module, leading to kernel bloat and abusing core
initialization levels.

Can generic solutions be used instead, such as using standard platform_device
child nodes or creating a standardized context bus?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-glymur-v7-0-afaa55d11fe0@oss.qualcomm.com?part=2