summaryrefslogtreecommitdiff
path: root/drivers/iommu
AgeCommit message (Collapse)Author
2026-02-26iommu: Validate device tree node in dev_iommu_enablePeng Fan
Similar to pinctrl_select_state(), add dev_has_ofnode() check before doing the real work. Device(scmi_base.0) does not have a real device node, ofnode_null() is assigned as the device tree node for scmi base protocol device: 'commit 7eb4eb541c14 ("firmware: scmi: install base protocol to SCMI agent")' However with recent update in 'commit 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")', SPL panic in fdt_check_node_offset_()->fdt_next_tag(), because offset is -1 and SPL_OF_LIBFDT_ASSUME_MASK is 0xFF. So need to validate device tree node. Reported-by: Ye Li <[email protected]> Closes: https://lore.kernel.org/u-boot/[email protected]/ Signed-off-by: Peng Fan <[email protected]>
2025-10-30iommu: qcom-smmu: Introduce sc7180 compatible stringGeorge Chan
Add basic compatible string for sc7180 family soc. Signed-off-by: Vitalii Skorkin <[email protected]> Co-developed-by: George Chan <[email protected]> Signed-off-by: George Chan <[email protected]> Reviewed-by: Casey Connolly <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Casey Connolly <[email protected]>
2025-10-29iommu: qcom-smmu: Add qcom,sm6350-smmu-500 compatibleLuca Weiss
This SoC doesn't have the generic compatible. Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Luca Weiss <[email protected]>
2025-06-14iommu: qcom-smmu: add missing linux/bug.h header for WARN_ONChristian Marangi
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 <[email protected]>
2024-11-24Merge patch series "Fix device removal order for Apple dart iommu"Tom Rini
Janne Grunau <[email protected]> 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/[email protected]
2024-11-24iommu: apple: Mark device with DM_FLAG_VITALJanne Grunau
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 <[email protected]> Signed-off-by: Janne Grunau <[email protected]>
2024-11-20iommu: qcom-smmu: handle running in el2Caleb Connolly
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 <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-11-20iommu: qcom-smmu: allow SID 0Caleb Connolly
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 <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-11-11iommu: apple: Manage IOVA separately from global LMB mem mapJanne Grunau
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 <[email protected]>
2024-09-06iommu: qcom-smmu: add sc7280-smmu-500 compatibleCaleb Connolly
This soc doesn't have the generic compatible. Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Caleb Connolly <[email protected]>
2024-09-03sandbox: iommu: remove lmb allocation in the driverSughosh Ganu
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 <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-09-03lmb: make LMB memory map persistent and globalSughosh Ganu
The current LMB API's for allocating and reserving memory use a per-caller based memory view. Memory allocated by a caller can then be overwritten by another caller. Make these allocations and reservations persistent using the alloced list data structure. Two alloced lists are declared -- one for the available(free) memory, and one for the used memory. Once full, the list can then be extended at runtime. [sjg: Use a stack to store pointer of lmb struct when running lmb tests] Signed-off-by: Sughosh Ganu <[email protected]> Signed-off-by: Simon Glass <[email protected]> [sjg: Optimise the logic to add a region in lmb_add_region_flags()]
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2024-05-07iommu: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <[email protected]>
2024-04-23iommu: qcom-smmu: add qcom generic compatibleCaleb Connolly
With the exception of SDM845, most other Qualcomm SoCs have the Qualcomm specific (but not SoC) specific SMMU compatible string. Add it here so we can match those without having to add individual SoCs to the list here. Signed-off-by: Caleb Connolly <[email protected]>
2024-03-22iommu: qcom-smmu: fix debuggingCaleb Connolly
The priv struct was wrong in dump_boot_mappings(). Causing errors when compiling with -DDEBUG. Fix this. Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Caleb Connolly <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mattijs Korpershoek <[email protected]>
2024-01-18iommu: dont fail silentlyCaleb Connolly
When attempting to probe a device which has an associated IOMMU, if the IOMMU device can't be found (no driver, disabled driver, driver failed to probe, etc) then we currently fail to probe the device with no discernable error. If we fail to hook the device up to its IOMMU, we should make sure that the user knows about it. Write some better error messages for dev_iommu_enable() to facilitate this. Signed-off-by: Caleb Connolly <[email protected]>
2023-12-21iommu: add qcom-hyp-smmuCaleb Connolly
Add a basic implementation of the ARM SMMU. This driver is intended for use on Qualcomm platforms where the SMMU has been configured by a previous bootloader, cannot be turned off, and doesn't support BYPASS streams. It keeps all existing stream mappings and only creates new ones for stream ids that aren't already configured. This driver is necessary to support peripherals that perform DMA which weren't configured by the previous stage bootloader (for example USB). It works by allocating a context bank using identity mapping (as U-Boot doesn't use virtual addresses). Signed-off-by: Caleb Connolly <[email protected]>
2023-12-21iommu: add a connect opCaleb Connolly
Add an optional iommu callback to be invoked before a device probes. This can be used to configure the IOMMU in preparation for the device (e.g. by allocating a context bank) Signed-off-by: Caleb Connolly <[email protected]>
2023-12-21iommu: fix compilation when CONFIG_PCI disabledCaleb Connolly
The dev_pci_iommu_enable() function is only available when CONFIG_PCI is enabled, replace the runtime check with a preprocessor one to fix compilation with pci disabled. Signed-off-by: Caleb Connolly <[email protected]>
2023-01-27iommu: Implement mapping IOMMUs for PCI devicesMark Kettenis
Systems such as Apple's M1 and M2 SoCs may have separate IOMMUs for each PCIe root port. In this case the right IOMMU for a PCI device behind a particular root port is described by an "iommu-map" property in the device tree. Parse this property and use it to find the right IOMMU device for PCI devices. Signed-off-by: Mark Kettenis <[email protected]>
2023-01-27iommu: apple: Implement DMA mapping operations for Apple DARTMark Kettenis
Implement translation table support for all the variations of Apple's DART IOMMU that can be found on Apple's M1 and M2 SoCs. Signed-off-by: Mark Kettenis <[email protected]>
2023-01-27test: Add test for IOMMU uclass map/unmap opsMark Kettenis
Test that the map and unmap operations work for devices that have DMA translated by an IOMMU and devices that don't have DMA translated by an IOMMU. Signed-off-by: Mark Kettenis <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2023-01-27iommu: Add DMA mapping operationsMark Kettenis
In order to support IOMMUs in non-bypass mode we need device ops to map and unmap DMA memory. The map operation enters a mapping for a region specified by CPU address and size into the translation table of the IOMMU and returns a DMA address suitable for programming the device to do DMA. The unmap operation removes this mapping from the translation table of the IOMMU. Signed-off-by: Mark Kettenis <[email protected]>
2022-07-25iommu: Add M2 support to Apple DART driverJanne Grunau
"apple,t8112-dart" uses an incompatible register interface but still offers the same functionality. This DART is found on the M2 and M1 Pro/Max/Ultra SoCs. Signed-off-by: Janne Grunau <[email protected]> Reviewed-by: Mark Kettenis <[email protected]>
2022-02-21iommu: Add M1 Pro/Max support to Apple DART driverJanne Grunau
For the purpose of this driver (activating bypass mode) t6000-dart and t8103-dart are fully compatible. Signed-off-by: Janne Grunau <[email protected]> Reviewed-by: Mark Kettenis <[email protected]>
2021-10-31iommu: Add Apple DART driverMark Kettenis
The DART is an IOMMU that is used on Apple's M1 SoC. This driver configures the DART such that it operates in bypass mode which is enough to support DMA for the USB3 ports integrated on the SoC. Signed-off-by: Mark Kettenis <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2021-10-31test: Add tests for IOMMU uclassMark Kettenis
Add a set of tests for the IOMMU uclass. Signed-off-by: Mark Kettenis <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2021-10-31iommu: Add IOMMU uclassMark Kettenis
This uclass is intended to manage IOMMUs on systems where the IOMMUs are not in bypass mode by default. In that case U-Boot cannot ignore the IOMMUs if it wants to use devices that need to do DMA and sit behind such an IOMMU. This initial IOMMU uclass implementation does not implement and device ops and is intended for IOMMUs that have a bypass mode that does not require address translation. Support for IOMMUs that do require address translation is planned and device ops will be defined when support for such IOMMUs will be added. Signed-off-by: Mark Kettenis <[email protected]> Reviewed-by: Simon Glass <[email protected]>