linux-stable.git/drivers/base/dd.c, branch v6.11

driver core: make [device_]driver_attach take a const *

2024-06-20T10:51:42+00:00

Change device_driver_attach() and driver_attach() to take a const * to
struct device driver as neither of them modify the structure at all.

Also, for some odd reason, drivers/dma/idxd/compat.c had a duplicate
external reference to device_driver_attach(), so remove that to fix up
the build, it should never have had that there in the first place.

Cc: Rafael J. Wysocki 
Cc: Fenghua Yu 
Cc: Dave Jiang 
Cc: Vinod Koul 
Cc: Andy Shevchenko 
Cc: Petr Tesarik 
Cc: Alexander Lobakin 
Cc: dmaengine@vger.kernel.org
Link: https://lore.kernel.org/r/2024061401-rasping-manger-c385@gregkh
Signed-off-by: Greg Kroah-Hartman

driver core: mark async_driver as a const *

2024-06-13T14:44:00+00:00

Within struct device_private, mark the async_driver * as const as it is
never modified.  This requires some internal-to-the-driver-core
functions to also have their parameters marked as constant, and there is
one place where we cast _back_ from the const pointer to a real one, as
the driver core still wants to modify the structure in a number of
remaining places.

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

driver core: make driver_detach() take a const *

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

driver_detach() does not modify the driver itself, so make the pointer
constant.  In doing so, the function driver_allows_async_probing() also
needs to be changed so that the pointer type passes through to that
function properly.

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

driver core: make device_release_driver_internal() take a const *

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

Change device_release_driver_internal() to take a const struct
device_driver * as it is not modifying it at all.

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

device: core: Log warning for devices pending deferred probe on timeout

2024-03-07T22:10:31+00:00

Once the deferred probe timeout has elapsed it is very likely that the
devices that are still deferring probe won't ever be probed. Therefore
log the defer probe pending reason at the warning level instead to bring
attention to the issue.

Signed-off-by: "Nícolas F. R. A. Prado" 
Link: https://lore.kernel.org/r/20240305-device-probe-error-v1-3-a06d8722bf19@collabora.com
Signed-off-by: Greg Kroah-Hartman

driver: core: Use dev_* instead of pr_* so device metadata is added

2024-03-07T22:10:31+00:00

Use the dev_* instead of the pr_* functions to log the status of device
probe so that the log message gets the device metadata attached to it.

Signed-off-by: "Nícolas F. R. A. Prado" 
Link: https://lore.kernel.org/r/20240305-device-probe-error-v1-2-a06d8722bf19@collabora.com
Signed-off-by: Greg Kroah-Hartman

driver: core: Log probe failure as error and with device metadata

2024-03-07T22:10:31+00:00

Drivers can return -ENODEV or -ENXIO from their probe to reject a device
match, and return -EPROBE_DEFER if probe should be retried. Any other
error code is not expected during normal behavior and indicates an
issue occurred, so it should be logged at the error level.

Also make use of the device variant, dev_err(), so that the device
metadata is attached to the log message.

Signed-off-by: "Nícolas F. R. A. Prado" 
Link: https://lore.kernel.org/r/20240305-device-probe-error-v1-1-a06d8722bf19@collabora.com
Signed-off-by: Greg Kroah-Hartman

driver core: Emit reason for pending deferred probe

2023-12-07T02:35:26+00:00

Ending a boot log with

	platform 3f202000.mmc: deferred probe pending

is already a nice hint about the problem. Sometimes there is a more
detailed error indicator available, add that to the output.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20231122093332.274145-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman

driver core: Release all resources during unbind before updating device links

2023-10-21T21:17:52+00:00

This commit fixes a bug in commit 9ed9895370ae ("driver core: Functional
dependencies tracking support") where the device link status was
incorrectly updated in the driver unbind path before all the device's
resources were released.

Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Cc: stable 
Reported-by: Uwe Kleine-König 
Closes: https://lore.kernel.org/all/20231014161721.f4iqyroddkcyoefo@pengutronix.de/
Signed-off-by: Saravana Kannan 
Cc: Thierry Reding 
Cc: Yang Yingliang 
Cc: Andy Shevchenko 
Cc: Mark Brown 
Cc: Matti Vaittinen 
Cc: James Clark 
Acked-by: "Rafael J. Wysocki" 
Tested-by: Uwe Kleine-König 
Acked-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20231018013851.3303928-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman

driver core: Call dma_cleanup() on the test_remove path

2023-08-05T06:31:41+00:00

When test_remove is enabled really_probe() does not properly pair
dma_configure() with dma_remove(), it will end up calling dma_configure()
twice. This corrupts the owner_cnt and renders the group unusable with
VFIO/etc.

Add the missing cleanup before going back to re_probe.

Fixes: 25f3bcfc54bc ("driver core: Add dma_cleanup callback in bus_type")
Reported-by: Zenghui Yu 
Tested-by: Zenghui Yu 
Closes: https://lore.kernel.org/all/6472f254-c3c4-8610-4a37-8d9dfdd54ce8@huawei.com/
Signed-off-by: Jason Gunthorpe 
Reviewed-by: Kevin Tian 
Link: https://lore.kernel.org/r/0-v2-4deed94e283e+40948-really_probe_dma_cleanup_jgg@nvidia.com
Signed-off-by: Greg Kroah-Hartman