linux/drivers/base/platform.c, branch v6.15

platform: Fix race condition during DMA configure at IOMMU probe time

2025-05-01T16:00:58Z

To avoid a race between the IOMMU probing thread and the device driver async probing thread during configuration of the platform DMA, update `platform_dma_configure()` to read `dev->driver` once and test if it's NULL before using it. This ensures that we don't de-reference an invalid platform driver pointer if the device driver is asynchronously bound while configuring the DMA. Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Signed-off-by: Will McVicker Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20250424180420.3928523-1-willmcvicker@google.com Signed-off-by: Greg Kroah-Hartman

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

platform: Make platform_bus_type constant

2024-09-03T11:00:50Z

Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the platform_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Kunwu Chan Link: https://lore.kernel.org/r/20240823075544.144426-1-kunwu.chan@linux.dev Signed-off-by: Greg Kroah-Hartman

driver core: platform: Switch to use kmemdup_array()

2024-07-04T10:02:38Z

Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240606164926.3031358-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

driver core: have match() callback in struct bus_type take a const *

2024-07-03T13:16:54Z

In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki Reviewed-by: Alex Elder Acked-by: Sumit Garg Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman

driver core: platform: fix ups for constant struct device_driver

2024-06-13T14:43:46Z

Fix up a few places in the platform core code that can easily handle struct device_driver being constant. This is part of the work to make all struct device_driver pointers be constant. Cc: Rafael J. Wysocki Link: https://lore.kernel.org/r/20240611130103.3262749-8-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

platform: Make platform_driver::remove() return void

2024-05-27T08:34:35Z

struct platform_driver::remove returning an integer made driver authors expect that returning an error code was proper error handling. However the driver core ignores the error and continues to remove the device because there is nothing the core could do anyhow and reentering the remove callback again is only calling for trouble. To prevent such wrong assumptions, change the return type of the remove callback to void. This was prepared by introducing an alternative remove callback returning void and converting all drivers to that. So .remove() can be changed without further changes in drivers. This corresponds to step b) of the plan outlined in commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value"). Signed-off-by: Uwe Kleine-König

driver core: platform: Annotate struct irq_affinity_devres with __counted_by

2023-10-07T16:13:09Z

Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct irq_affinity_devres. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: "Gustavo A. R. Silva" Cc: linux-hardening@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by: Kees Cook Reviewed-by: "Gustavo A. R. Silva" Link: https://lore.kernel.org/r/20231006201749.work.432-kees@kernel.org Signed-off-by: Greg Kroah-Hartman

driver core: platform: Unify the firmware node type check

2023-10-05T09:12:59Z

OF and ACPI currently are using asymmetrical APIs to check for the firmware node type. Unify them by using is_*_node() against struct fwnode_handle pointer. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20231003142122.3072824-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

driver core: platform: Use temporary variable in platform_device_add()

2023-10-05T09:12:59Z

With the temporary variable for the struct device pointer the code looks better and slightly easier to read and parse by human being. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20231003142122.3072824-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman