Re: [RFC PATCH 0/4] device_schedule_reprobe(): core helper and conversions
Hans de Goede <[email protected]>
| Newsgroups | org.kernel.vger.linux-bluetooth,dev.linux.lists.driver-core,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
Hi Greg, On 11-Aug-26 04:33, Greg Kroah-Hartman wrote: > On Tue, Aug 11, 2026 at 01:47:17AM +0100, Daniel Golle wrote: >> Three in-tree drivers (iwlwifi, hci_h5, btintel_pcie) schedule a >> deferred re-probe of their own device from a work item in module >> text. > > That's a mess, why? Why not fix that up to not do that? Thousands of > other kernel drivers do not do that, what makes these so special? I can only speak for the hci_h5 driver where I added the reprobe code-path. The problem is some of the Bluetooth HCI devices using hci_h5 loose all state during system-suspend. This means that the HCI and the Bluetooth core end up being out of sync. So we basically need to tear down and re-build everything including e.g. the firmware upload which happens at probe(). Doing a full reprobe is by far the easiest way to do this. I suspect the other 4 users + the pending driver which triggered this are similar. Sure we can do the whole tear-down + setup from some worker scheduled at resume, while keep the driver attached but if we need to duplicate that over 4 drivers + the pending driver which triggers this then IMHO those 5 users are a pattern which deserves having some helper to do this through the existing probe() + remove(), rather then requiring those 5 drivers to open code this themselves. Note that we already have device_reprobe(), which has 15 existing users. This series just adds a helper to do a device_reprobe() from a worker in a safe way. Regards, Hans > >> The hand-rolled copies share two bug classes: the work function >> ends with module_put(THIS_MODULE), > > That's broken as-is. a module should NEVER be calling > module_get(THIS_MODULE) either. > >> racing a concurrent rmmod freeing >> the module text (the race module_put_and_kthread_exit() exists to >> close for kthreads), and nothing synchronizes the deferred detach >> against device_shutdown() or an administrative unbind. > > yeah, that's a mess, don't do that. > > Fix up the original drivers please, let's not encourage others to copy > this broken scheme. > > Also, your patches were not threaded properly :( > > thanks, > > greg k-h