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

If userspace reads "uevent" device attribute at the same time as another
threads unbinds the device from its driver, change to dev

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

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

show more ...

driver core: introduce device_set_driver() helper

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

driver core: introduce device_set_driver() helper

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

show more ...

Revert "drivers: core: synchronize really_probe() and dev_uevent()"

This reverts commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0.

Probing a device can take arbitrary long time. In the field we obse

Revert "drivers: core: synchronize really_probe() and dev_uevent()"

This reverts commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0.

Probing a device can take arbitrary long time. In the field we observed
that, for example, probing a bad micro-SD cards in an external USB card
reader (or maybe cards were good but cables were flaky) sometimes takes
longer than 2 minutes due to multiple retries at various levels of the
stack. We can not block uevent_show() method for that long because udev
is reading that attribute very often and that blocks udev and interferes
with booting of the system.

The change that introduced locking was concerned with dev_uevent()
racing with unbinding the driver. However we can handle it without
locking (which will be done in subsequent patch).

There was also claim that synchronization with probe() is needed to
properly load USB drivers, however this is a red herring: the change
adding the lock was introduced in May of last year and USB loading and
probing worked properly for many years before that.

Revert the harmful locking.

Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: Introduce device_{add,remove}_of_node()

An of_node can be set to a device using device_set_node(), which does not
prevent any of_node and/or fwnode overwrites.

When adding an of_node o

driver core: Introduce device_{add,remove}_of_node()

An of_node can be set to a device using device_set_node(), which does not
prevent any of_node and/or fwnode overwrites.

When adding an of_node on an already present device, the following
operations need to be done:

- Attach the of_node only if no of_node is already attached

- Attach the of_node as a fwnode if no fwnode were already attached

This is the purpose of device_add_of_node(). device_remove_of_node()
reverts the operations done by device_add_of_node().

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Herve Codina <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Rob Herring (Arm) <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: core: fix device leak in __fw_devlink_relax_cycles()

Commit bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize
cycle detection logic") introduced a new struct device *con_dev a

drivers: core: fix device leak in __fw_devlink_relax_cycles()

Commit bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize
cycle detection logic") introduced a new struct device *con_dev and a
get_dev_from_fwnode() call to get it, but without adding a corresponding
put_device().

Closes: https://lore.kernel.org/all/20241204124826.2e055091@booty/
Fixes: bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize cycle detection logic")
Cc: [email protected]
Reviewed-by: Saravana Kannan <[email protected]>
Signed-off-by: Luca Ceresoli <[email protected]>
Link: https://lore.kernel.org/r/20250213-fix__fw_devlink_relax_cycles_missing_device_put-v2-1-8cd3b03e6a3f@bootlin.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

driver core: Move two simple APIs for finding child device to header

The following two APIs are for finding child device, and both only have
one line code in function body.
device_find_child_by_name

driver core: Move two simple APIs for finding child device to header

The following two APIs are for finding child device, and both only have
one line code in function body.
device_find_child_by_name()
device_find_any_child()

Move them to header as static inline function.

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: 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: Correct API device_for_each_child_reverse_from() prototype

For API device_for_each_child_reverse_from(..., const void *data,
int (*fn)(struct device *dev, const void *data))

- Type o

driver core: Correct API device_for_each_child_reverse_from() prototype

For API device_for_each_child_reverse_from(..., const void *data,
int (*fn)(struct device *dev, const void *data))

- Type of @data is const pointer, and means caller's data @*data is not
allowed to be modified, but that usually is not proper for such non
finding device iterating API.

- Types for both @data and @fn are not consistent with all other
for_each device iterating APIs device_for_each_child(_reverse)(),
bus_for_each_dev() and (driver|class)_for_each_device().

Correct its prototype by removing const from parameter types, then adapt
for various existing usages.

An dedicated typedef device_iter_t will be introduced as @fn() type for
various for_each device interating APIs later.

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: Correct parameter check for API device_for_each_child_reverse_from()

device_for_each_child_reverse_from() checks (!parent->p) for its
parameter @parent, and that is not consistent with

driver core: Correct parameter check for API device_for_each_child_reverse_from()

device_for_each_child_reverse_from() checks (!parent->p) for its
parameter @parent, and that is not consistent with other APIs of
its cluster as shown below:

device_for_each_child_reverse_from() // check (!parent->p)
device_for_each_child_reverse() // check (!parent || !parent->p)
device_for_each_child() // same above
device_find_child() // same above

Correct the API's parameter @parent check by (!parent || !parent->p).

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 ...

driver core: Introduce an device matching API device_match_type()

Introduce device_match_type() for purposes below:

- Test if a device matches with a specified device type.
- As argument of various

driver core: Introduce an device matching API device_match_type()

Introduce device_match_type() for purposes below:

- Test if a device matches with a specified device type.
- As argument of various device finding APIs to find a device with
specified type.

device_find_child() will use it to simplify operations later.

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: Remove match_any()

Static match_any() is now exactly same as API device_match_any().
Remove the former and use the later instead.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei

driver core: Remove match_any()

Static match_any() is now exactly same as API device_match_any().
Remove the former and use the later instead.

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: Simplify API device_find_child_by_name() implementation

Simplify device_find_child_by_name() implementation by both existing
API device_find_child() and device_match_name().

Reviewed-b

driver core: Simplify API device_find_child_by_name() implementation

Simplify device_find_child_by_name() implementation by both existing
API device_find_child() and device_match_name().

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: Constify API device_find_child() and adapt for various usages

Constify the following API:
struct device *device_find_child(struct device *dev, void *data,
int (*match)(struct device *

driver core: Constify API device_find_child() and adapt for various usages

Constify the following API:
struct device *device_find_child(struct device *dev, void *data,
int (*match)(struct device *dev, void *data));
To :
struct device *device_find_child(struct device *dev, const void *data,
device_match_t match);
typedef int (*device_match_t)(struct device *dev, const void *data);
with the following reasons:

- Protect caller's match data @*data which is for comparison and lookup
and the API does not actually need to modify @*data.

- Make the API's parameters (@match)() and @data have the same type as
all of other device finding APIs (bus|class|driver)_find_device().

- All kinds of existing device match functions can be directly taken
as the API's argument, they were exported by driver core.

Constify the API and adapt for various existing usages.

BTW, various subsystem changes are squashed into this commit to meet
'git bisect' requirement, and this commit has the minimal and simplest
changes to complement squashing shortcoming, and that may bring extra
code improvement.

Reviewed-by: Alison Schofield <[email protected]>
Reviewed-by: Takashi Sakamoto <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]> # for drivers/pwm
Signed-off-by: Zijun Hu <[email protected]>
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: base: Don't match devices with NULL of_node/fwnode/etc

of_find_device_by_node(), bus_find_device_by_of_node(),
bus_find_device_by_fwnode(), ..., all produce arbitrary results when
provided

drivers: base: Don't match devices with NULL of_node/fwnode/etc

of_find_device_by_node(), bus_find_device_by_of_node(),
bus_find_device_by_fwnode(), ..., all produce arbitrary results when
provided with a NULL of_node, fwnode, ACPI handle, etc. This is
counterintuitive, and the source of a few bugs, such as the one fixed by
commit 5c8418cf4025 ("PCI/pwrctrl: Unregister platform device only if
one actually exists").

It's hard to imagine a good reason that these device_match_*() APIs
should return 'true' for a NULL argument. Augment these to return 0
(false).

Reviewed-by: Rob Herring (Arm) <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Acked-by: David Gow <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: core: fw_devlink: Fix excess parameter description in docstring

Replace the parameter name 'con' with 'con_handle' in the docstring of
__fw_devlink_relax_cycles() to resolve the kernel-doc

drivers: core: fw_devlink: Fix excess parameter description in docstring

Replace the parameter name 'con' with 'con_handle' in the docstring of
__fw_devlink_relax_cycles() to resolve the kernel-doc warning about an
excess parameter description.

Address the following warning:
./drivers/base/core.c:1994: warning: Excess function parameter 'con' description in '__fw_devlink_relax_cycles'

Reported-by: Stephen Rothwell <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Amit Vadhavana <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: core: fw_devlink: Make the error message a bit more useful

It would make it easier to debugs issues similar to the ones
reported[1][2] recently where some devices didn't have the fwnode set

drivers: core: fw_devlink: Make the error message a bit more useful

It would make it easier to debugs issues similar to the ones
reported[1][2] recently where some devices didn't have the fwnode set.

[1] - https://lore.kernel.org/all/7b995947-4540-4b17-872e-e107adca4598@notapiano/
[2] - https://lore.kernel.org/all/[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 core: fw_devlink: Stop trying to optimize cycle detection logic

In attempting to optimize fw_devlink runtime, I introduced numerous cycle
detection bugs by foregoing cycle detection logic und

driver core: fw_devlink: Stop trying to optimize cycle detection logic

In attempting to optimize fw_devlink runtime, I introduced numerous cycle
detection bugs by foregoing cycle detection logic under specific
conditions. Each fix has further narrowed the conditions for optimization.

It's time to give up on these optimization attempts and just run the cycle
detection logic every time fw_devlink tries to create a device link.

The specific bug report that triggered this fix involved a supplier fwnode
that never gets a device created for it. Instead, the supplier fwnode is
represented by the device that corresponds to an ancestor fwnode.

In this case, fw_devlink didn't do any cycle detection because the cycle
detection logic is only run when a device link is created between the
devices that correspond to the actual consumer and supplier fwnodes.

With this change, fw_devlink will run cycle detection logic even when
creating SYNC_STATE_ONLY proxy device links from a device that is an
ancestor of a consumer fwnode.

Reported-by: Tomi Valkeinen <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
Cc: stable <[email protected]>
Tested-by: Tomi Valkeinen <[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 core: constify devlink class

The devlink class object is never modified and can be made constant.

Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Rafael J. Wyso

driver core: constify devlink class

The devlink class object is never modified and can be made constant.

Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Saravana Kannan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "driver core: Fix uevent_show() vs driver detach race"

This reverts commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c.

This commit causes a regression, so revert it for now until it can come
b

Revert "driver core: Fix uevent_show() vs driver detach race"

This reverts commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c.

This commit causes a regression, so revert it for now until it can come
back in a way that works for everyone.

Link: https://lore.kernel.org/all/172790598832.1168608.4519484276671503678.stgit@dwillia2-xfh.jf.intel.com/
Fixes: 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")
Cc: stable <[email protected]>
Cc: Ashish Sangwan <[email protected]>
Cc: Namjae Jeon <[email protected]>
Cc: Dirk Behme <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

cxl/port: Fix use-after-free, permit out-of-order decoder shutdown

In support of investigating an initialization failure report [1],
cxl_test was updated to register mock memory-devices after the mo

cxl/port: Fix use-after-free, permit out-of-order decoder shutdown

In support of investigating an initialization failure report [1],
cxl_test was updated to register mock memory-devices after the mock
root-port/bus device had been registered. That led to cxl_test crashing
with a use-after-free bug with the following signature:

cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1
cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1
cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0
1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1
[..]
cxld_unregister: cxl decoder14.0:
cxl_region_decode_reset: cxl_region region3:
mock_decoder_reset: cxl_port port3: decoder3.0 reset
2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1
cxl_endpoint_decoder_release: cxl decoder14.0:
[..]
cxld_unregister: cxl decoder7.0:
3) cxl_region_decode_reset: cxl_region region3:
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI
[..]
RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core]
[..]
Call Trace:
<TASK>
cxl_region_decode_reset+0x69/0x190 [cxl_core]
cxl_region_detach+0xe8/0x210 [cxl_core]
cxl_decoder_kill_region+0x27/0x40 [cxl_core]
cxld_unregister+0x5d/0x60 [cxl_core]

At 1) a region has been established with 2 endpoint decoders (7.0 and
14.0). Those endpoints share a common switch-decoder in the topology
(3.0). At teardown, 2), decoder14.0 is the first to be removed and hits
the "out of order reset case" in the switch decoder. The effect though
is that region3 cleanup is aborted leaving it in-tact and
referencing decoder14.0. At 3) the second attempt to teardown region3
trips over the stale decoder14.0 object which has long since been
deleted.

The fix here is to recognize that the CXL specification places no
mandate on in-order shutdown of switch-decoders, the driver enforces
in-order allocation, and hardware enforces in-order commit. So, rather
than fail and leave objects dangling, always remove them.

In support of making cxl_region_decode_reset() always succeed,
cxl_region_invalidate_memregion() failures are turned into warnings.
Crashing the kernel is ok there since system integrity is at risk if
caches cannot be managed around physical address mutation events like
CXL region destruction.

A new device_for_each_child_reverse_from() is added to cleanup
port->commit_end after all dependent decoders have been disabled. In
other words if decoders are allocated 0->1->2 and disabled 1->2->0 then
port->commit_end only decrements from 2 after 2 has been disabled, and
it decrements all the way to zero since 1 was disabled previously.

Link: http://lore.kernel.org/[email protected] [1]
Cc: [email protected]
Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware")
Reviewed-by: Jonathan Cameron <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Dave Jiang <[email protected]>
Cc: Alison Schofield <[email protected]>
Cc: Ira Weiny <[email protected]>
Cc: Zijun Hu <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Reviewed-by: Ira Weiny <[email protected]>
Link: https://patch.msgid.link/172964782781.81806.17902885593105284330.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Ira Weiny <[email protected]>

show more ...

driver core: Add device probe log helper dev_warn_probe()

Some drivers can still provide their functionality to a certain extent
even when some of their resource acquisitions eventually fail. In su

driver core: Add device probe log helper dev_warn_probe()

Some drivers can still provide their functionality to a certain extent
even when some of their resource acquisitions eventually fail. In such
cases, emitting errors isn't the desired action, but warnings should be
emitted instead.

To solve this, introduce dev_warn_probe() as a new device probe log helper,
which behaves identically as the already existing dev_err_probe(), while it
produces warnings instead of errors. The intended use is with the resources
that are actually optional for a particular driver.

While there, copyedit the kerneldoc for dev_err_probe() a bit, to simplify
its wording a bit, and reuse it as the kerneldoc for dev_warn_probe(), with
the necessary wording adjustments, of course.

Signed-off-by: Dragan Simic <[email protected]>
Tested-by: Hélène Vulquin <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://patch.msgid.link/2be0a28538bb2a3d1bcc91e2ca1f2d0dc09146d9.1727601608.git.dsimic@manjaro.org
Signed-off-by: Mark Brown <[email protected]>

show more ...

Revert "driver core: don't always lock parent in shutdown"

This reverts commit ba6353748e71bd1d7e422fec2b5c2e2dfc2e3bd9.

The series is being reverted before -rc1 as there are still reports of
locku

Revert "driver core: don't always lock parent in shutdown"

This reverts commit ba6353748e71bd1d7e422fec2b5c2e2dfc2e3bd9.

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: David Jeffery <[email protected]>
Cc: Keith Busch <[email protected]>
Cc: Laurence Oberman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Sagi Grimberg <[email protected]>
Cc: Stuart Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "driver core: separate function to shutdown one device"

This reverts commit 95dc7565253a8564911190ebd1e4ffceb4de208a.

The series is being reverted before -rc1 as there are still reports of
l

Revert "driver core: separate function to shutdown one device"

This reverts commit 95dc7565253a8564911190ebd1e4ffceb4de208a.

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: David Jeffery <[email protected]>
Cc: Keith Busch <[email protected]>
Cc: Laurence Oberman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Sagi Grimberg <[email protected]>
Cc: Stuart Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "driver core: shut down devices asynchronously"

This reverts commit 8064952c65045f05ee2671fe437770e50c151776.

The series is being reverted before -rc1 as there are still reports of
lockups o

Revert "driver core: shut down devices asynchronously"

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: David Jeffery <[email protected]>
Cc: Keith Busch <[email protected]>
Cc: Laurence Oberman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Sagi Grimberg <[email protected]>
Cc: Stuart Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...