user/sven/linux.git/drivers/base/dd.c, branch stable/6.9.y

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

2024-03-07T22:10:31Z

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:31Z

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:31Z

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:26Z

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:52Z

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:41Z

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

driver core: return bool from driver_probe_done

2023-06-05T16:55:20Z

bool is the most sensible return value for a yes/no return. Also add __init as this funtion is only called from the early boot code. Signed-off-by: Christoph Hellwig Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20230531125535.676098-2-hch@lst.de Signed-off-by: Jens Axboe

driver core: Don't require dynamic_debug for initcall_debug probe timing

2023-04-20T12:17:47Z

Don't require the use of dynamic debug (or modification of the kernel to add a #define DEBUG to the top of this file) to get the printk message about driver probe timing. This printk is only emitted when initcall_debug is enabled on the kernel commandline, and it isn't immediately obvious that you have to do something else to debug boot timing issues related to driver probe. Add a comment too so it doesn't get converted back to pr_debug(). Fixes: eb7fbc9fb118 ("driver core: Add missing '\n' in log messages") Cc: stable Cc: Christophe JAILLET Cc: Brian Norris Reviewed-by: Brian Norris Acked-by: Randy Dunlap Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20230412225842.3196599-1-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman

driver core: Make state_synced device attribute writeable

2023-03-10T08:06:22Z

If the file is written to and sync_state() hasn't been called for the device yet, then call sync_state() for the device independent of the state of its consumers. This is useful for supplier devices that have one or more consumers that don't have a driver but the consumers are in a state that don't use the resources supplied by the supplier device. This gives finer grained control than using the fw_devlink.sync_state=timeout kernel commandline parameter. Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20230304005355.746421-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

driver core: Add fw_devlink.sync_state command line param

2023-03-10T08:06:21Z

When all devices that could probe have finished probing (based on deferred_probe_timeout configuration or late_initcall() when !CONFIG_MODULES), this parameter controls what to do with devices that haven't yet received their sync_state() calls. fw_devlink.sync_state=strict is the default and the driver core will continue waiting on all consumers of a device to probe successfully before sync_state() is called for the device. This is the default behavior since calling sync_state() on a device when all its consumers haven't probed could make some systems unusable/unstable. When this option is selected, we also print the list of devices that haven't had sync_state() called on them by the time all devices the could probe have finished probing. fw_devlink.sync_state=timeout will cause the driver core to give up waiting on consumers and call sync_state() on any devices that haven't yet received their sync_state() calls. This option is provided for systems that won't become unusable/unstable as they might be able to save power (depends on state of hardware before kernel starts) if all devices get their sync_state(). Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20230304005355.746421-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman