linux-toradex.git/drivers/base/base.h, branch v6.19

rust: device: introduce Device::drvdata()

2025-10-29T17:18:02+00:00

In C dev_get_drvdata() has specific requirements under which it is valid
to access the returned pointer. That is, drivers have to ensure that

  (1) for the duration the returned pointer is accessed the driver is
      bound and remains to be bound to the corresponding device,

  (2) the returned void * is treated according to the driver's private
      data type, i.e. according to what has been passed to
      dev_set_drvdata().

In Rust, (1) can be ensured by simply requiring the Bound device
context, i.e. provide the drvdata() method for Device only.

For (2) we would usually make the device type generic over the driver
type, e.g. Device, where ::Data is the type of
the driver's private data.

However, a device does not have a driver type known at compile time and
may be bound to multiple drivers throughout its lifetime.

Hence, in order to be able to provide a safe accessor for the driver's
device private data, we have to do the type check on runtime.

This is achieved by letting a driver assert the expected type, which is
then compared to a type hash stored in struct device_private when
dev_set_drvdata() is called.

Example:

	// `dev` is a `&Device`.
	let data = dev.drvdata::()?;

There are two aspects to note:

  (1) Technically, the same check could be achieved by comparing the
      struct device_driver pointer of struct device with the struct
      device_driver pointer of the driver struct (e.g. struct
      pci_driver).

      However, this would - in addition the pointer comparison - require
      to tie back the private driver data type to the struct
      device_driver pointer of the driver struct to prove correctness.

      Besides that, accessing the driver struct (stored in the module
      structure) isn't trivial and would result into horrible code and
      API ergonomics.

  (2) Having a direct accessor to the driver's private data is not
      commonly required (at least in Rust): Bus callback methods already
      provide access to the driver's device private data through a &self
      argument, while other driver entry points such as IRQs,
      workqueues, timers, IOCTLs, etc. have their own private data with
      separate ownership and lifetime.

      In other words, a driver's device private data is only relevant
      for driver model contexts (such a file private is only relevant
      for file contexts).

Having that said, the motivation for accessing the driver's device
private data with Device::drvdata() are interactions between
drivers. For instance, when an auxiliary driver calls back into its
parent, the parent has to be capable to derive its private data from the
corresponding device (i.e. the parent of the auxiliary device).

Reviewed-by: Alice Ryhl 
Reviewed-by: Greg Kroah-Hartman 
[ * Remove unnecessary `const _: ()` block,
  * rename type_id_{store,match}() to {set,match}_type_id(),
  * assert size_of::() >= size_of::(),
  * add missing check in case Device::drvdata() is called from probe().

  - Danilo ]
Signed-off-by: Danilo Krummrich

PM: sleep: Do not wait on SYNC_STATE_ONLY device links

2025-09-27T12:10:51+00:00

Device links with DL_FLAG_SYNC_STATE_ONLY should not affect system
suspend and resume, and functions like device_reorder_to_tail() and
device_link_add() don't try to reorder the consumers with that flag.

However, dpm_wait_for_consumers() and dpm_wait_for_suppliers() don't
check thas flag before triggering dpm_wait(), leading to potential hang
during suspend/resume.

This can be reproduced on MT8186 Corsola Chromebook with devicetree like:

usb-a-connector {
        compatible = "usb-a-connector";
        port {
                usb_a_con: endpoint {
                        remote-endpoint = <&usb_hs>;
                };
        };
};

usb_host {
        compatible = "mediatek,mt8186-xhci", "mediatek,mtk-xhci";
        port {
                usb_hs: endpoint {
                        remote-endpoint = <&usb_a_con>;
                };
        };
};

In this case, the two nodes form a cycle and a SYNC_STATE_ONLY devlink
between usb_host (supplier) and usb-a-connector (consumer) is created.

Address this by exporting device_link_flag_is_sync_state_only() and
making dpm_wait_for_consumers() and dpm_wait_for_suppliers() use it
when deciding if dpm_wait() should be called.

Fixes: 05ef983e0d65a ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Signed-off-by: Pin-yen Lin 
Link: https://patch.msgid.link/20250926102320.4053167-1-treapking@chromium.org
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki

PM: core: Add two macros for walking device links

2025-09-06T15:16:32+00:00

Add separate macros for walking links to suppliers and consumers of a
device to help device links users to avoid exposing the internals of
struct dev_links_info in their code and possible coding mistakes related
to that.

Accordingly, use the new macros to replace open-coded device links list
walks in the core power management code.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Ulf Hansson 
Acked-by: Greg Kroah-Hartman 
Link: https://patch.msgid.link/1944671.tdWV9SEqCh@rafael.j.wysocki

driver core: fix potential NULL pointer dereference in dev_uevent()

2025-04-15T15:04:35+00:00

If userspace reads "uevent" device attribute at the same time as another
threads unbinds the device from its driver, change to dev->driver from a
valid pointer to NULL may result in crash. Fix this by using READ_ONCE()
when fetching the pointer, and take bus' drivers klist lock to make sure
driver instance will not disappear while we access it.

Use WRITE_ONCE() when setting the driver pointer to ensure there is no
tearing.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20250311052417.1846985-3-dmitry.torokhov@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: introduce device_set_driver() helper

2025-04-15T15:04:35+00:00

In preparation to closing a race when reading driver pointer in
dev_uevent() code, instead of setting device->driver pointer directly
introduce device_set_driver() helper.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Masami Hiramatsu (Google) 
Link: https://lore.kernel.org/r/20250311052417.1846985-2-dmitry.torokhov@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: add a faux bus for use when a simple device/bus is needed

2025-02-13T15:58:51+00:00

Many drivers abuse the platform driver/bus system as it provides a
simple way to create and bind a device to a driver-specific set of
probe/release functions.  Instead of doing that, and wasting all of the
memory associated with a platform device, here is a "faux" bus that
can be used instead.

Reviewed-by: Jonathan Cameron 
Reviewed-by: Danilo Krummrich 
Reviewed-by: Lyude Paul 
Reviewed-by: Thomas Weißschuh 
Reviewed-by: Zijun Hu 
Link: https://lore.kernel.org/r/2025021026-atlantic-gibberish-3f0c@gregkh
Signed-off-by: Greg Kroah-Hartman

Revert "driver core: shut down devices asynchronously"

2024-09-25T09:01:27+00:00

This reverts commit 8064952c65045f05ee2671fe437770e50c151776.

The series is being reverted before -rc1 as there are still reports of
lockups on shutdown, so it's not quite ready for "prime time."

Reported-by: Andrey Skvortsov 
Link: https://lore.kernel.org/r/ZvMkkhyJrohaajuk@skv.local
Cc: Christoph Hellwig 
Cc: David Jeffery 
Cc: Keith Busch 
Cc: Laurence Oberman 
Cc: Nathan Chancellor 
Cc: Sagi Grimberg 
Cc: Stuart Hayes 
Signed-off-by: Greg Kroah-Hartman

driver core: shut down devices asynchronously

2024-09-03T11:06:43+00:00

Add code to allow asynchronous shutdown of devices, ensuring that each
device is shut down before its parents & suppliers.

Only devices with drivers that have async_shutdown_enable enabled will be
shut down asynchronously.

This can dramatically reduce system shutdown/reboot time on systems that
have multiple devices that take many seconds to shut down (like certain
NVMe drives). On one system tested, the shutdown time went from 11 minutes
without this patch to 55 seconds with the patch.

Signed-off-by: Stuart Hayes 
Signed-off-by: David Jeffery 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Keith Busch 
Tested-by: Keith Busch 
Link: https://lore.kernel.org/r/20240822202805.6379-4-stuart.w.hayes@gmail.com
Signed-off-by: Greg Kroah-Hartman

driver core: Remove unused parameter for virtual_device_parent()

2024-07-31T12:55:13+00:00

Function struct kobject *virtual_device_parent(struct device *dev)
does not use its parameter @dev, and the kobject returned also has
nothing deal with specific device, so remove the unused parameter.

Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20240725-virtual_kobj_fix-v1-1-36335cae4544@quicinc.com
Signed-off-by: Greg Kroah-Hartman

driver core: module: make module_[add|remove]_driver take a const *

2024-07-10T07:46:02+00:00

The functions module_add_driver() and module_remove_driver() do not
modify the struct device_driver structure directly, so they are safe to
be marked as a constant pointer type.

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/2024070850-entering-grandson-205e@gregkh
Signed-off-by: Greg Kroah-Hartman