[0/8] iommu: The early demise of bus ops

  Hi all,

[ Christoph, Greg, Rafael; feel free to ignore all the IOMMU details,
 just a heads-up for some pretty trivial header motion in patch #6 ]

This is sort of an RFC, in the sense that the patches are functionally
ready but I don't expect that we necessarily want to merge all them
right away; at this point it's more for the sake of visibility and
checking if anyone strongly objects to the direction I'm taking. As such
I've based these patches on 6.2-rc3 and made no effort to integrate them
with the IOMMUFD-related work going on in parallel and/or already
queued, even though there is some functional intersection and almost
certain conflicts. If we reach a consensus that we would like any of
this for 6.3 I'll rebase as appropriate.

Patches #1-6 here work up to what I originally expected to be the
triumphant finale of the whole mission, but as it turns out is actually
feasible and convenient to get out of the way *before* getting into the
really fiddly bits of refactoring the DT/ACPI of_xlate stuff, ARM DMA
ops, and the iommu_domain_alloc() interface. Patch #8 is included here
as the precursor to another cleanup series for drivers that currently
have an awkward domain_finalise step in their .attach_dev op, but I'm
unlikely to start writing those patches for a while yet. Patch #7 is
also here nominally, but in fact I think it could already go anywhere
since the last rework of iommu_device_register().

Thanks,
Robin.


Robin Murphy (8):
  iommu: Decouple iommu_present() from bus ops
  iommu: Validate that devices match domains
  iommu: Factor out a "first device in group" helper
  iommu: Switch __iommu_domain_alloc() to device ops
  iommu/arm-smmu: Don't register fwnode for legacy binding
  iommu: Retire bus ops
  iommu: Clean up open-coded ownership checks
  iommu: Pass device through ops->domain_alloc

 drivers/iommu/amd/iommu.c                   |   3 +-
 drivers/iommu/apple-dart.c                  |   3 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   6 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  15 +--
 drivers/iommu/arm/arm-smmu/qcom_iommu.c     |  19 +--
 drivers/iommu/exynos-iommu.c                |   3 +-
 drivers/iommu/fsl_pamu_domain.c             |   3 +-
 drivers/iommu/intel/iommu.c                 |   3 +-
 drivers/iommu/iommu.c                       | 130 +++++++++++++-------
 drivers/iommu/ipmmu-vmsa.c                  |   3 +-
 drivers/iommu/msm_iommu.c                   |   3 +-
 drivers/iommu/mtk_iommu.c                   |  10 +-
 drivers/iommu/mtk_iommu_v1.c                |   6 +-
 drivers/iommu/omap-iommu.c                  |   3 +-
 drivers/iommu/rockchip-iommu.c              |   3 +-
 drivers/iommu/s390-iommu.c                  |   3 +-
 drivers/iommu/sprd-iommu.c                  |  11 +-
 drivers/iommu/sun50i-iommu.c                |   3 +-
 drivers/iommu/tegra-gart.c                  |   3 +-
 drivers/iommu/tegra-smmu.c                  |   3 +-
 drivers/iommu/virtio-iommu.c                |   6 +-
 include/acpi/acpi_bus.h                     |   2 +
 include/linux/device.h                      |   1 -
 include/linux/device/bus.h                  |   5 -
 include/linux/dma-map-ops.h                 |   1 +
 include/linux/iommu.h                       |   4 +-
 26 files changed, 139 insertions(+), 116 deletions(-)
  

On Thu, Jan 19, 2023 at 07:18:18PM +0000, Robin Murphy wrote:
> Hi all,
> 
> [ Christoph, Greg, Rafael; feel free to ignore all the IOMMU details,
>  just a heads-up for some pretty trivial header motion in patch #6 ]
> 
> This is sort of an RFC, in the sense that the patches are functionally
> ready but I don't expect that we necessarily want to merge all them
> right away; at this point it's more for the sake of visibility and
> checking if anyone strongly objects to the direction I'm taking.

Looks good to me

Is there anything beyond some typing preventing the removal of the bus
from the out-of-iommu callers?

> I've based these patches on 6.2-rc3 and made no effort to integrate them
> with the IOMMUFD-related work going on in parallel and/or already
> queued, even though there is some functional intersection and almost
> certain conflicts. If we reach a consensus that we would like any of
> this for 6.3 I'll rebase as appropriate.

I don't see a reason to wait..

Jason
  

Hi Robin,

On Thu, Jan 19, 2023 at 07:18:18PM +0000, Robin Murphy wrote:
> This is sort of an RFC, in the sense that the patches are functionally
> ready but I don't expect that we necessarily want to merge all them
> right away; at this point it's more for the sake of visibility and
> checking if anyone strongly objects to the direction I'm taking. As such
> I've based these patches on 6.2-rc3 and made no effort to integrate them
> with the IOMMUFD-related work going on in parallel and/or already
> queued, even though there is some functional intersection and almost
> certain conflicts. If we reach a consensus that we would like any of
> this for 6.3 I'll rebase as appropriate.

Thanks for doing this, I like the direction this is taking! I see no
strict reason to wait with this, but also no strict reason to hurry it
in.

I would say we have another week for this to get ready to be merged into
6.3, which means having a version based on iommu/core with the reviews
addressed and enough relevant Reviewed-by's.

Regards,

	Joerg