linux.git/drivers/base/driver.c, branch v6.18.21

driver core: Introduce device_iter_t for device iterating APIs

2025-01-10T14:26:12+00:00

There are several for_each APIs which has parameter with type below:
int (*fn)(struct device *dev, void *data)
They iterate over various device lists and call @fn() for each device
with caller provided data @*data, and they usually need to modify @*data.

Give the type an dedicated typedef with advantages shown below:
typedef int (*device_iter_t)(struct device *dev, void *data)

- Shorter API declarations and definitions
- Prevent further for_each APIs from using bad parameter type

So introduce device_iter_t and apply it to various existing APIs below:
bus_for_each_dev()
(class|driver)_for_each_device()
device_for_each_child(_reverse|_reverse_from)().

Reviewed-by: Jonathan Cameron 
Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20250105-class_fix-v6-7-3a2f1768d4d4@quicinc.com
Signed-off-by: Greg Kroah-Hartman

driver core: Move true expression out of if condition in 3 device finding APIs

2025-01-10T14:26:12+00:00

For bus_find_device(), driver_find_device(), and device_find_child(), all
of their function body have pattern below:

{
	struct klist_iter i;
	struct device *dev;

	...
	while ((dev = next_device(&i)))
		if (match(dev, data) && get_device(dev))
			break;
	...
}

The expression 'get_device(dev)' in the if condition always returns true
since @dev != NULL.

Move the expression to if body to make logic of these APIs more clearer.

Reviewed-by: Fan Ni 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20250105-class_fix-v6-3-3a2f1768d4d4@quicinc.com
Signed-off-by: Greg Kroah-Hartman

drivers/base: Introduce device_match_t for device finding APIs

2024-09-03T10:48:51+00:00

There are several drivers/base APIs for finding a specific device, and
they currently use the following good type for the @match parameter:
int (*match)(struct device *dev, const void *data)

Since these operations do not modify the caller-provided @*data, this
type is worthy of a dedicated typedef:
typedef int (*device_match_t)(struct device *dev, const void *data)

Advantages of using device_match_t:
 - Shorter API declarations and definitions
 - Prevent further APIs from using a bad type for @match

So introduce device_match_t and apply it to the existing
(bus|class|driver|auxiliary)_find_device() APIs.

Signed-off-by: Zijun Hu 
Link: https://lore.kernel.org/r/20240813-dev_match_api-v3-1-6c6878a99b9f@quicinc.com
Signed-off-by: Greg Kroah-Hartman

driver core: make driver_find_device() take a const *

2024-07-10T07:41:57+00:00

The function driver_find_device() does not modify the struct
device_driver structure directly, so it is safe to be marked as a
constant pointer type.  As that is fixed up, also change the function
signature on the inline functions that call this, which are:
	driver_find_device_by_name()
	driver_find_device_by_of_node()
	driver_find_device_by_devt()
	driver_find_next_device()
	driver_find_device_by_acpi_dev()

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/2024070849-broken-front-9eb5@gregkh
Signed-off-by: Greg Kroah-Hartman

driver core: make driver_[create|remove]_file take a const *

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

The functions driver_create_file() and driver_remove_file() 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/2024070844-volley-hatchling-c812@gregkh
Signed-off-by: Greg Kroah-Hartman

driver core: driver: mark driver_add/remove_groups constant

2024-06-13T14:43:51+00:00

driver_add_groups() and driver_remove_groups should take a constant
pointer as the structure is not modified, so make the change.

Cc: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/20240611130103.3262749-9-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: create bus_is_registered()

2023-02-09T09:43:35+00:00

A local function to the driver core to determine if a bus really is
registered with the kernel or not.  To be used only by the driver core
code, as part of the driver registration path as it's not really "safe"
because the bus could be unregistered instantly after being called.

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/20230208111330.439504-17-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: move driver_find() to bus.c

2023-02-09T09:43:31+00:00

This function really is a bus function, not a driver one, so move it
from driver.c to bus.c so that we can clean up some internal bus logic
easier.

Cc: "Rafael J. Wysocki" 
Link: https://lore.kernel.org/r/20230208111330.439504-15-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: fix driver_set_override() issue with empty strings

2022-09-05T11:01:34+00:00

Python likes to send an empty string for some sysfs files, including the
driver_override field.  When commit 23d99baf9d72 ("PCI: Use
driver_set_override() instead of open-coding") moved the PCI core to use
the driver core function instead of hand-rolling their own handler, this
showed up as a regression from some userspace tools, like DPDK.

Fix this up by actually looking at the length of the string first
instead of trusting that userspace got it correct.

Fixes: 23d99baf9d72 ("PCI: Use driver_set_override() instead of open-coding")
Cc: Krzysztof Kozlowski 
Cc: Bjorn Helgaas 
Cc: "Rafael J. Wysocki" 
Cc: Andy Shevchenko 
Cc: stable 
Reported-by: Stephen Hemminger 
Tested-by: Huisong Li 
Reviewed-by: Stephen Hemminger 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20220901163734.3583106-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

driver core: Extend deferred probe timeout on driver registration

2022-05-19T17:32:33+00:00

The deferred probe timer that's used for this currently starts at
late_initcall and runs for driver_deferred_probe_timeout seconds. The
assumption being that all available drivers would be loaded and
registered before the timer expires. This means, the
driver_deferred_probe_timeout has to be pretty large for it to cover the
worst case. But if we set the default value for it to cover the worst
case, it would significantly slow down the average case. For this
reason, the default value is set to 0.

Also, with CONFIG_MODULES=y and the current default values of
driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing
drivers will cause their consumer devices to always defer their probes.
This is because device links created by fw_devlink defer the probe even
before the consumer driver's probe() is called.

Instead of a fixed timeout, if we extend an unexpired deferred probe
timer on every successful driver registration, with the expectation more
modules would be loaded in the near future, then the default value of
driver_deferred_probe_timeout only needs to be as long as the worst case
time difference between two consecutive module loads.

So let's implement that and set the default value to 10 seconds when
CONFIG_MODULES=y.

Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Rob Herring 
Cc: Linus Walleij 
Cc: Will Deacon 
Cc: Ulf Hansson 
Cc: Kevin Hilman 
Cc: Thierry Reding 
Cc: Mark Brown 
Cc: Pavel Machek 
Cc: Geert Uytterhoeven 
Cc: Yoshihiro Shimoda 
Cc: Paul Kocialkowski 
Cc: linux-gpio@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Reviewed-by: Mark Brown 
Acked-by: Rob Herring 
Signed-off-by: Saravana Kannan 
Link: https://lore.kernel.org/r/20220429220933.1350374-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman