u-boot.git/drivers/iommu, branch v2026.01

iommu: qcom-smmu: Introduce sc7180 compatible string

2025-10-30T17:04:51Z

Add basic compatible string for sc7180 family soc. Signed-off-by: Vitalii Skorkin Co-developed-by: George Chan Signed-off-by: George Chan Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20251021-sc7180-minor-v1-1-9fe33c73365e@gmail.com Signed-off-by: Casey Connolly

iommu: qcom-smmu: Add qcom,sm6350-smmu-500 compatible

2025-10-29T11:27:33Z

This SoC doesn't have the generic compatible. Reviewed-by: Neil Armstrong Signed-off-by: Luca Weiss

iommu: qcom-smmu: add missing linux/bug.h header for WARN_ON

2025-06-14T15:11:10Z

The WARN macro requires inclusion of linux/bug.h header. It does currently work as bitfield.h includes it indirectly but this will change when bitfield.h will be synced with new Linux version. Explicitly include the header to fix future compilation error. Signed-off-by: Christian Marangi

Merge patch series "Fix device removal order for Apple dart iommu"

2024-11-24T21:41:32Z

Janne Grunau says: Starting with v2024.10 dev_iommu_dma_unmap calls during device removal trigger a NULL pointer dereference in the Apple dart iommu driver. The iommu device is removed before its user. The sparsely used DM_FLAG_VITAL flag is intended to describe this dependency. Add it to the driver. Adding this flag is unfortunately not enough since the boot routines except the arm one simply remove all drivers. Add and use a new function which calls dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL); dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL); to ensure this order dependency is head consistently. Link: https://lore.kernel.org/r/20241123-iommu_apple_dart_ordering-v2-0-cc2ade6dde97@jannau.net

iommu: apple: Mark device with DM_FLAG_VITAL

2024-11-24T21:41:28Z

Avoids NULL pointer dereferences in apple_dart_unmap when the iommu device is removed before its user. U-boot's device model does not track dependencies between devices. Observed on a M1 Ultra Mac Studio with v2024.10. Acked-by: Mark Kettenis Signed-off-by: Janne Grunau

iommu: qcom-smmu: handle running in el2

2024-11-20T16:57:58Z

We only need to configure the SMMU when running in EL1. In EL2 the hypervisor isn't running so peripherals can just do DMA as they wish. Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly

iommu: qcom-smmu: allow SID 0

2024-11-20T16:57:58Z

It turns out this is a very real stream ID. Who woulda thought? Drop the 0 check on the SID, there's no reason for it to be there in the first place. Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly

iommu: apple: Manage IOVA separately from global LMB mem map

2024-11-11T13:26:44Z

There is no overlap between the IOVA space managed by the iommu (here the 32-bit address space) and physical RAM on Apple silicon systems. The RAM starts at 0x10_0000_0000 or 0x100_0000_0000 so it's not possible to manage the IOVA with the global memory LMB and use 1:1 translation. In addition each device has its own iommu and does not need to share the address space with all other devices. This should not be problem for u-boot's limited use and hardware support. Restore the private per instance LMB IOVA map. Fixes: ed17a33fed2 ("lmb: make LMB memory map persistent and global") Signed-off-by: Janne Grunau

iommu: qcom-smmu: add sc7280-smmu-500 compatible

2024-09-06T08:47:47Z

This soc doesn't have the generic compatible. Reviewed-by: Neil Armstrong Reviewed-by: Simon Glass Signed-off-by: Caleb Connolly

sandbox: iommu: remove lmb allocation in the driver

2024-09-03T20:08:50Z

The sandbox iommu driver uses the LMB module to allocate a particular range of memory for the device virtual address(DVA). This used to work earlier since the LMB memory map was caller specific and not global. But with the change to make the LMB allocations global and persistent, adding this memory range has other side effects. On the other hand, the sandbox iommu test expects to see this particular value of the DVA. Use the DVA address directly, instead of mapping it in the LMB memory map, and then have it allocated. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass