driver core: Introduce device_iter_t for device iterating APIs

There are several for_each APIs which has parameter with type below:
int (*fn)(struct device *dev, void *data)
They iterate over variou

driver core: Introduce device_iter_t for device iterating APIs

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 <[email protected]>
Signed-off-by: Zijun Hu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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

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

{

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

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 <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Zijun Hu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers/base: Introduce device_match_t for device finding APIs

There are several drivers/base APIs for finding a specific device, and
they currently use the following good type for the @match parame

drivers/base: Introduce device_match_t for device finding APIs

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: make driver_find_device() take a const *

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

driver core: make driver_find_device() take a const *

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" <[email protected]>
Link: https://lore.kernel.org/r/2024070849-broken-front-9eb5@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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

The functions driver_create_file() and driver_remove_file() do not
modify the struct device_driver structure directly, so they are safe t

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

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" <[email protected]>
Link: https://lore.kernel.org/r/2024070844-volley-hatchling-c812@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: driver: mark driver_add/remove_groups constant

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

Cc: Raf

driver core: driver: mark driver_add/remove_groups constant

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: create bus_is_registered()

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 th

driver core: create bus_is_registered()

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" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: move driver_find() to bus.c

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: "Raf

driver core: move driver_find() to bus.c

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" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: fix driver_set_override() issue with empty strings

Python likes to send an empty string for some sysfs files, including the
driver_override field. When commit 23d99baf9d72 ("PCI: Use
d

driver core: fix driver_set_override() issue with empty strings

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 <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: stable <[email protected]>
Reported-by: Stephen Hemminger <[email protected]>
Tested-by: Huisong Li <[email protected]>
Reviewed-by: Stephen Hemminger <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: Extend deferred probe timeout on driver registration

The deferred probe timer that's used for this currently starts at
late_initcall and runs for driver_deferred_probe_timeout seconds.

driver core: Extend deferred probe timeout on driver registration

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 <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Ulf Hansson <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Yoshihiro Shimoda <[email protected]>
Cc: Paul Kocialkowski <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Mark Brown <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver: platform: Add helper for safer setting of driver_override

Several core drivers and buses expect that driver_override is a
dynamically allocated memory thus later they can kfree() it.

Howeve

driver: platform: Add helper for safer setting of driver_override

Several core drivers and buses expect that driver_override is a
dynamically allocated memory thus later they can kfree() it.

However such assumption is not documented, there were in the past and
there are already users setting it to a string literal. This leads to
kfree() of static memory during device release (e.g. in error paths or
during unbind):

kernel BUG at ../mm/slub.c:3960!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
(kfree) from [<c058da50>] (platform_device_release+0x88/0xb4)
(platform_device_release) from [<c0585be0>] (device_release+0x2c/0x90)
(device_release) from [<c0a69050>] (kobject_put+0xec/0x20c)
(kobject_put) from [<c0f2f120>] (exynos5_clk_probe+0x154/0x18c)
(exynos5_clk_probe) from [<c058de70>] (platform_drv_probe+0x6c/0xa4)
(platform_drv_probe) from [<c058b7ac>] (really_probe+0x280/0x414)
(really_probe) from [<c058baf4>] (driver_probe_device+0x78/0x1c4)
(driver_probe_device) from [<c0589854>] (bus_for_each_drv+0x74/0xb8)
(bus_for_each_drv) from [<c058b48c>] (__device_attach+0xd4/0x16c)
(__device_attach) from [<c058a638>] (bus_probe_device+0x88/0x90)
(bus_probe_device) from [<c05871fc>] (device_add+0x3dc/0x62c)
(device_add) from [<c075ff10>] (of_platform_device_create_pdata+0x94/0xbc)
(of_platform_device_create_pdata) from [<c07600ec>] (of_platform_bus_create+0x1a8/0x4fc)
(of_platform_bus_create) from [<c0760150>] (of_platform_bus_create+0x20c/0x4fc)
(of_platform_bus_create) from [<c07605f0>] (of_platform_populate+0x84/0x118)
(of_platform_populate) from [<c0f3c964>] (of_platform_default_populate_init+0xa0/0xb8)
(of_platform_default_populate_init) from [<c01031f8>] (do_one_initcall+0x8c/0x404)

Provide a helper which clearly documents the usage of driver_override.
This will allow later to reuse the helper and reduce the amount of
duplicated code.

Convert the platform driver to use a new helper and make the
driver_override field const char (it is not modified by the core).

Reviewed-by: Rafael J. Wysocki <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: base: Convert to printk alias functions

The file mixes printk calls together with calls to pr_*().
Covert to printk alias functions to unify the code.

Signed-off-by: Matthias Brugger <mbru

drivers: base: Convert to printk alias functions

The file mixes printk calls together with calls to pr_*().
Covert to printk alias functions to unify the code.

Signed-off-by: Matthias Brugger <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

device.h: move 'struct driver' stuff out to device/driver.h

device.h has everything and the kitchen sink when it comes to struct
device things, so split out the struct driver things things to a
sepa

device.h: move 'struct driver' stuff out to device/driver.h

device.h has everything and the kitchen sink when it comes to struct
device things, so split out the struct driver things things to a
separate .h file to make things easier to maintain and manage over time.

Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Saravana Kannan <[email protected]>
Cc: Heikki Krogerus <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver_find_device: Unify the match function with class_find_device()

The driver_find_device() accepts a match function pointer to
filter the devices for lookup, similar to bus/class_find_device().

driver_find_device: Unify the match function with class_find_device()

The driver_find_device() accepts a match function pointer to
filter the devices for lookup, similar to bus/class_find_device().
However, there is a minor difference in the prototype for the
match parameter for driver_find_device() with the now unified
version accepted by {bus/class}_find_device(), where it doesn't
accept a "const" qualifier for the data argument. This prevents
us from reusing the generic match functions for driver_find_device().

For this reason, change the prototype of the driver_find_device() to
make the "match" parameter in line with {bus/class}_find_device()
and adjust its callers to use the const qualifier. Also, we could
now promote the "data" parameter to const as we pass it down
as a const parameter to the match functions.

Cc: Corey Minyard <[email protected]>
Cc: Russell King <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Peter Oberparleiter <[email protected]>
Cc: Sebastian Ott <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Nehal Shah <[email protected]>
Cc: Shyam Sundar S K <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver-core: return EINVAL error instead of BUG_ON()

I triggerd the BUG_ON() in driver_register() when booting a domU Xen
domain. Since there was no contextual information logged, I needed to
attach

driver-core: return EINVAL error instead of BUG_ON()

I triggerd the BUG_ON() in driver_register() when booting a domU Xen
domain. Since there was no contextual information logged, I needed to
attach kgdb to determine the culprit (the wmi-bmof driver in my
case). The BUG_ON() was added in commit f48f3febb2cb ("driver-core: do
not register a driver with bus_type not registered").

Instead of running into a BUG_ON() we print an error message
identifying the, likely faulty, driver but continue booting.

Signed-off-by: Florian Schmaus <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: base: omit redundant interations

When error happens, these interators return the error, no interation should
be continued, so make the change for getting out of while immediately.

Signed-o

drivers: base: omit redundant interations

When error happens, these interators return the error, no interation should
be continued, so make the change for getting out of while immediately.

Signed-off-by: Gimcuan Hui <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: Remove redundant license text

Now that the SPDX tag is in all driver core files, that identifies the
license in a specific and legally-defined manner. So the extra GPL text
wording can

driver core: Remove redundant license text

Now that the SPDX tag is in all driver core files, that identifies the
license in a specific and legally-defined manner. So the extra GPL text
wording can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text. And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Johannes Berg <[email protected]>
Cc: "Luis R. Rodriguez" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: add SPDX identifiers to all driver core files

It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the driver core fi

driver core: add SPDX identifiers to all driver core files

It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the driver core files files with the correct SPDX license
identifier based on the license text in the file itself. The SPDX
identifier is a legally binding shorthand, which can be used instead of
the full boiler plate text.

This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.

Cc: Johannes Berg <[email protected]>
Cc: "Luis R. Rodriguez" <[email protected]>
Cc: William Breathitt Gray <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Kate Stewart <[email protected]>
Cc: Philippe Ombredanne <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: add missing blank line after declaration

Found using checkpatch.pl
Signed-off-by: Lavinia Tache <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Revert "core: platform: add warning if driver has no owner"

This is too noisy at the moment, triggered by codepaths not accessed on
our test-systems. Needs more investigation.

Signed-off-by: Wolfra

Revert "core: platform: add warning if driver has no owner"

This is too noisy at the moment, triggered by codepaths not accessed on
our test-systems. Needs more investigation.

Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

core: platform: add warning if driver has no owner

Commit 9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register") introduced a codepath which could result into
drivers havi

core: platform: add warning if driver has no owner

Commit 9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register") introduced a codepath which could result into
drivers having no owner. This went unnoticed for months, so add a
warning in case this happens again somewhere else somewhen.

Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: add #include <linux/sysfs.h> to core files.

This is needed to fix the build on sh systems.

Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Greg Kroah-Hartman <gr

driver core: add #include <linux/sysfs.h> to core files.

This is needed to fix the build on sh systems.

Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

sysfs: add sysfs_create/remove_groups()

These functions are being open-coded in 3 different places in the driver
core, and other driver subsystems will want to start doing this as well,
so move it t

sysfs: add sysfs_create/remove_groups()

These functions are being open-coded in 3 different places in the driver
core, and other driver subsystems will want to start doing this as well,
so move it to the sysfs core to keep it all in one place, where we know
it is written properly.

Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: bus_type: add drv_groups

attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add drv_gr

driver core: bus_type: add drv_groups

attribute groups are much more flexible than just a list of attributes,
due to their support for visibility of the attributes, and binary
attributes. Add drv_groups to struct bus_type which should be used
instead of drv_attrs.

drv_attrs will be removed from the structure soon.

Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: don't trigger uevent after failure

Do not send the uevent if driver_add_groups failed.

Reported-by: Ming Lei <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]

driver core: don't trigger uevent after failure

Do not send the uevent if driver_add_groups failed.

Reported-by: Ming Lei <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...