linux/drivers/cdx, branch v6.17

cdx: Fix off-by-one error in cdx_rpmsg_probe()

2025-08-19T10:55:16Z

In cdx_rpmsg_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'cdx_rpmsg_id_table[0].name' to 'chinfo.name'. Use the destination buffer size instead to ensure the name is copied correctly. Cc: stable Fixes: 2a226927d9b8 ("cdx: add rpmsg communication channel for CDX") Signed-off-by: Thorsten Blum Link: https://lore.kernel.org/r/20250806090512.121260-2-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman

cdx: Fix missing GENERIC_MSI_IRQ on compile test

2025-07-16T12:17:31Z

CDX_BUS driver uses msi_setup_device_data() which is selected by GENERIC_MSI_IRQ, thus compile testing without the latter failed: /usr/bin/ld: drivers/cdx/cdx.o: in function `cdx_probe': build/drivers/cdx/cdx.c:314: undefined reference to `msi_setup_device_data' Reported-by: Randy Dunlap Closes: https://lore.kernel.org/all/b2c54a12-480c-448a-8b90-333cb03d9c14@infradead.org/ Fixes: 7f81907b7e3f ("cdx: Enable compile testing") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250716064903.52397-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman

cdx: controller: Drop unneeded driver.pm NULL assignment

2025-07-01T10:18:07Z

Struct driver in platform_driver is zero-ed so there is no need to assign its 'pm' member to NULL. Signed-off-by: Krzysztof Kozlowski Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20250502-cdx-clean-v3-5-6aaa5b369fc5@linaro.org Signed-off-by: Greg Kroah-Hartman

cdx: controller: Do not open-code module_platform_driver()

2025-07-01T10:18:07Z

Replace standard platform_driver_register() boilerplate with module_platform_driver() to make code smaller. Signed-off-by: Krzysztof Kozlowski Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20250502-cdx-clean-v3-4-6aaa5b369fc5@linaro.org Signed-off-by: Greg Kroah-Hartman

cdx: controller: Drop useless probe success message

2025-07-01T10:18:07Z

Drivers should be silent on probe success, unless they print some useful information. Printing "hey I probed" is not useful and kernel already gives mechanism to investigate that (e.g. sysfs, tracing, initcall debug). Signed-off-by: Krzysztof Kozlowski Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20250502-cdx-clean-v3-3-6aaa5b369fc5@linaro.org Signed-off-by: Greg Kroah-Hartman

cdx: controller: Simplify with dev_err_probe()

2025-07-01T10:18:07Z

Simplify printing probe failures and handling deferred probe with dev_err_probe(). Signed-off-by: Krzysztof Kozlowski Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20250502-cdx-clean-v3-2-6aaa5b369fc5@linaro.org Signed-off-by: Greg Kroah-Hartman

cdx: Enable compile testing

2025-07-01T10:18:07Z

There is no code limited to ARM64 or OF/Devicetree in the CDX bus driver, so CDX_BUS can be compile tested on all platforms. CDX_CONTROLLER on the other hand selects REMOTEPROC which depends on HAS_DMA, so add that dependency for compile testing. Signed-off-by: Krzysztof Kozlowski Acked-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20250502-cdx-clean-v3-1-6aaa5b369fc5@linaro.org Signed-off-by: Greg Kroah-Hartman

irqdomain: cdx: Switch to of_fwnode_handle()

2025-04-25T13:53:38Z

of_node_to_fwnode() is irqdomain's reimplementation of the "officially" defined of_fwnode_handle(). The former is in the process of being removed, so use the latter instead. Signed-off-by: Jiri Slaby (SUSE) Cc: Nipun Gupta Cc: Nikhil Agarwal Acked-by: Nipun Gupta Link: https://lore.kernel.org/r/20250415104734.106849-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

Merge branches 'apple/dart', 'arm/smmu/updates', 'arm/smmu/bindings', 'rockchip', 's390', 'core', 'intel/vt-d' and 'amd/amd-vi' into next

2025-03-20T08:11:09Z

iommu: Get DT/ACPI parsing into the proper probe path

2025-03-11T13:05:43Z

In hindsight, there were some crucial subtleties overlooked when moving {of,acpi}_dma_configure() to driver probe time to allow waiting for IOMMU drivers with -EPROBE_DEFER, and these have become an ever-increasing source of problems. The IOMMU API has some fundamental assumptions that iommu_probe_device() is called for every device added to the system, in the order in which they are added. Calling it in a random order or not at all dependent on driver binding leads to malformed groups, a potential lack of isolation for devices with no driver, and all manner of unexpected concurrency and race conditions. We've attempted to mitigate the latter with point-fix bodges like iommu_probe_device_lock, but it's a losing battle and the time has come to bite the bullet and address the true source of the problem instead. The crux of the matter is that the firmware parsing actually serves two distinct purposes; one is identifying the IOMMU instance associated with a device so we can check its availability, the second is actually telling that instance about the relevant firmware-provided data for the device. However the latter also depends on the former, and at the time there was no good place to defer and retry that separately from the availability check we also wanted for client driver probe. Nowadays, though, we have a proper notion of multiple IOMMU instances in the core API itself, and each one gets a chance to probe its own devices upon registration, so we can finally make that work as intended for DT/IORT/VIOT platforms too. All we need is for iommu_probe_device() to be able to run the iommu_fwspec machinery currently buried deep in the wrong end of {of,acpi}_dma_configure(). Luckily it turns out to be surprisingly straightforward to bootstrap this transformation by pretty much just calling the same path twice. At client driver probe time, dev->driver is obviously set; conversely at device_add(), or a subsequent bus_iommu_probe(), any device waiting for an IOMMU really should *not* have a driver already, so we can use that as a condition to disambiguate the two cases, and avoid recursing back into the IOMMU core at the wrong times. Obviously this isn't the nicest thing, but for now it gives us a functional baseline to then unpick the layers in between without many more awkward cross-subsystem patches. There are some minor side-effects like dma_range_map potentially being created earlier, and some debug prints being repeated, but these aren't significantly detrimental. Let's make things work first, then deal with making them nice. With the basic flow finally in the right order again, the next step is probably turning the bus->dma_configure paths inside-out, since all we really need from bus code is its notion of which device and input ID(s) to parse the common firmware properties with... Acked-by: Bjorn Helgaas # pci-driver.c Acked-by: Rob Herring (Arm) # of/device.c Signed-off-by: Robin Murphy Reviewed-by: Lorenzo Pieralisi Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/e3b191e6fd6ca9a1e84c5e5e40044faf97abb874.1740753261.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel