linux.git/drivers/base/platform.c, branch v7.2-rc1

driver core: platform: set mod_name in driver registration

2026-06-08T21:28:24+00:00

Pass KBUILD_MODNAME through the driver registration macro so that the
driver core can create the module symlink in sysfs for built-in drivers,
and fixup all callers.

The Rust platform adapter is updated to pass the module name through to
the new parameter.

Tested on qemu with:
- x86 defconfig + CONFIG_RUST
- arm64 defconfig + CONFIG_RUST + CONFIG_CORESIGHT stuff

Examples after this patch:

    /sys/bus/platform/drivers/...
        coresight-itnoc/module		-> coresight_tnoc
        coresight-static-tpdm/module	-> coresight_tpdm
        coresight-catu-platform/module	-> coresight_catu
        serial8250/module		-> 8250
        acpi-ged/module			-> acpi
        vmclock/module			-> ptp_vmclock

Co-developed-by: Rahul Bukte 
Signed-off-by: Rahul Bukte 
Signed-off-by: Shashank Balaji 
Link: https://patch.msgid.link/20260518-acpi_mod_name-v5-4-705ccc430885@sony.com
Signed-off-by: Danilo Krummrich

Merge tag 'v7.1-rc5' into driver-core-next

2026-05-25T00:40:57+00:00

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich

driver core: platform: remove software node on release()

2026-05-13T22:09:09+00:00

If we pass a software node to a newly created device using struct
platform_device_info, it will not be removed when the device is
released. This may happen when a module creating the device is removed
or on failure in platform_device_add().

When we try to reuse that software node in a subsequent call to
platform_device_register_full(), it will fail with -EBUSY.

Provide a wrapper around the existing platform_device_release() that
additionally calls device_remove_software_node() and use it to replace
the former if we end up adding a software node.

While at it: check all three possible situations in which two software
nodes for a single platform device can be created/assigned in
platform_device_register_full() and bail-out early.

Fixes: 0fc434bc2c45 ("driver core: platform: allow attaching software nodes when creating devices")
Signed-off-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260513-swnode-remove-on-dev-unreg-v6-1-f9c58939df27@oss.qualcomm.com
Signed-off-by: Danilo Krummrich

driver core: Replace dev->of_node_reused with dev_of_node_reused()

2026-04-26T21:50:20+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.

Cc: Johan Hovold 
Acked-by: Mark Brown 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Signed-off-by: Douglas Anderson 
Reviewed-by: Johan Hovold 
Acked-by: Manivannan Sadhasivam  # PCI_PWRCTRL
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Link: https://patch.msgid.link/20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid
Signed-off-by: Danilo Krummrich

Merge tag 'v7.0-rc5' into driver-core-next

2026-03-22T22:13:33+00:00

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich

driver core: platform: use generic driver_override infrastructure

2026-03-17T19:30:57+00:00

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
Reported-by: Gui-Dong Han 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
Reviewed-by: Greg Kroah-Hartman 
Link: https://patch.msgid.link/20260303115720.48783-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich

driver core: platform: fix various formatting issues

2026-03-02T11:13:43+00:00

Make checkpatch happy. This helps when checkpatch is set up as an
automatic linter.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260214025246.2095239-4-dmitry.torokhov@gmail.com
Signed-off-by: Danilo Krummrich

driver core: platform: allow attaching software nodes when creating devices

2026-03-02T11:13:43+00:00

Extend platform_device_info structure with an optional pointer to a
software node to be used as a secondary firmware node for the device
being created. If software node has not been registered yet it will be
automatically registered.

This reduces boilerplate needed when switching legacy board code to
static device properties/GPIO references.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Bartosz Golaszewski 
Link: https://patch.msgid.link/20260214025246.2095239-3-dmitry.torokhov@gmail.com
Signed-off-by: Danilo Krummrich

platform: Add firmware-agnostic irq and affinity retrieval interface

2025-10-27T16:16:32+00:00

Expand platform_get_irq_optional() to also return an affinity if available,
renaming it to platform_get_irq_affinity() in the process.

platform_get_irq_optional() is preserved with its current semantics by
calling into the new helper with a NULL affinity pointer.

Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Tested-by: Will Deacon 
Reviewed-by: Jonathan Cameron 
Link: https://patch.msgid.link/20251020122944.3074811-5-maz@kernel.org

driver core: platform: Drop dev_pm_domain_detach() call

2025-07-07T18:41:21+00:00

On the Renesas RZ/G3S (and other Renesas SoCs, e.g., RZ/G2{L, LC, UL}),
clocks are managed through PM domains. These PM domains, registered on
behalf of the clock controller driver, are configured with
GENPD_FLAG_PM_CLK. In most of the Renesas drivers used by RZ SoCs, the
clocks are enabled/disabled using runtime PM APIs. The power domains may
also have power_on/power_off support implemented. After the device PM
domain is powered off any CPU accesses to these domains leads to system
aborts.

During probe, devices are attached to the PM domain controlling their
clocks and power. Similarly, during removal, devices are detached from the
PM domain.

The detachment call stack is as follows:

device_driver_detach() ->
  device_release_driver_internal() ->
    __device_release_driver() ->
      device_remove() ->
        platform_remove() ->
          dev_pm_domain_detach()

During driver unbind, after the device is detached from its PM domain,
the device_unbind_cleanup() function is called, which subsequently
invokes devres_release_all(). This function handles devres resource
cleanup.

If runtime PM is enabled in driver probe via devm_pm_runtime_enable(),
the cleanup process triggers the action or reset function for disabling
runtime PM. This function is pm_runtime_disable_action(), which leads
to the following call stack of interest when called:

pm_runtime_disable_action() ->
  pm_runtime_dont_use_autosuspend() ->
    __pm_runtime_use_autosuspend() ->
      update_autosuspend() ->
        rpm_idle()

The rpm_idle() function attempts to resume the device at runtime.
However, at the point it is called, the device is no longer part of a PM
domain (which manages clocks and power states). If the driver implements
its own runtime PM APIs for specific functionalities - such as the
rzg2l_adc driver - while also relying on the power domain subsystem for
power management, rpm_idle() will invoke the driver's runtime PM API.
However, since the device is no longer part of a PM domain at this point,
the PM domain's runtime PM APIs will not be called. This leads to system
aborts on Renesas SoCs.

Another identified case is when a subsystem performs various cleanups
using device_unbind_cleanup(), calling driver-specific APIs in the
process. A known example is the thermal subsystem, which may call driver-
specific APIs to disable the thermal device. The relevant call stack in
this case is:

device_driver_detach() ->
  device_release_driver_internal() ->
    device_unbind_cleanup() ->
      devres_release_all() ->
        devm_thermal_of_zone_release() ->
          thermal_zone_device_disable() ->
            thermal_zone_device_set_mode() ->
              struct thermal_zone_device_ops::change_mode()

At the moment the driver-specific change_mode() API is called, the
device is no longer part of its PM domain. Accessing its registers
without proper power management leads to system aborts.

Drop the call to dev_pm_domain_detach() from the platform bus remove
function and rely on the newly introduced call in device_unbind_cleanup().

This ensures the same effect, but the call now occurs after all
driver-specific devres resources have been freed.

Signed-off-by: Claudiu Beznea 
Reviewed-by: Ulf Hansson 
Link: https://patch.msgid.link/20250703112708.1621607-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Rafael J. Wysocki