[PATCH v4 0/4] device_schedule_reprobe(): core helper and conversions

[Daniel Golle]

iwlwifi and hci_h5 re-probe their own device from a work item in module
text ending in module_put(THIS_MODULE), which a concurrent rmmod can
race, and nothing ties the re-probe to the binding that asked for it.
btintel_pcie re-probes synchronously from its own reset work. This
series adds device_schedule_reprobe() to the driver core and converts
all three.

Tested on an Intel AX101 with patches 1 to 3, PROVE_LOCKING and
DEBUG_OBJECTS_WORK: a re-probe, and an unbind, rmmod, PCI removal,
suspend and reboot with one pending. The unbind and the removals
cancelled it, and it ran after resume. The stock iwlwifi code undid
the unbind, and rmmod with its work held just past module_put() oopsed
in lockdep. Patches 3 and 4 are untested for lack of hardware.

Changes since v3 [4]:
 - patch 1 was reworked as patch 3/6 of the mxl862xx devlink flash
   series, v13 to v19 [5][6], which netdev has deferred until this
   lands; its history summarises the changes
 - patch 1: Hans de Goede's tags dropped [7]; patch 3 keeps his, its
   code being unchanged, but a re-test would be welcome
 - patches 2 and 3: Fixes: tags
 - patches 2 to 4: commit messages updated; rebased onto bluetooth-next

Changes since v2 [3]:
 - patch 1: use dev_err_probe() for the re-probe error path so a
   re-probe deferred at resume no longer logs a spurious error; pick up
   Hans de Goede's Tested-by/Reviewed-by
 - patch 3: pick up Hans de Goede's Tested-by/Reviewed-by
 - patch 4: rebased onto bluetooth-next, whose btintel_pcie has four
   dump workers rather than the single one the v2 mainline snapshot had
 - base the series on bluetooth-next instead of v7.2-rc7 so the
   bluetooth patches apply for their maintainers

Changes since the RFC (v1) [1]:
 - pin the parent device across the deferred work and re-lock it across
   device_attach() on need_parent_lock buses (found reviewing the
   mxl862xx posting [2])
 - schedule the work on system_dfl_wq instead of the deprecated
   system_unbound_wq
 - thread the series properly (the RFC's patches were unthreaded)
 - drop RFC status

[1] https://lore.kernel.org/all/anpxFdwNxk0XwPjQ@xxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/cover.1786922210.git.daniel@xxxxxxxxxxxxxx/
[3] https://lore.kernel.org/all/cover.1787185594.git.daniel@xxxxxxxxxxxxxx/
[4] https://lore.kernel.org/all/cover.1787281239.git.daniel@xxxxxxxxxxxxxx/
[5] https://lore.kernel.org/all/cover.1788783126.git.daniel@xxxxxxxxxxxxxx/
[6] https://lore.kernel.org/all/cover.1791035885.git.daniel@xxxxxxxxxxxxxx/
[7] https://lore.kernel.org/all/aqlPPyblTK8c6-zZ@xxxxxxxxxxxxxx/

---
On LLM use: device_schedule_reprobe() was designed and first
implemented by hand. Its later revisions answer AI review (Sashiko on
the mxl862xx postings, and local runs of the same prompts); an LLM
helped reproduce those findings and draft the changes and changelogs.
Every decision and the final review were mine; the Assisted-by tag on
patch 1 records this.

Daniel Golle (4):
  driver core: add device_schedule_reprobe()
  wifi: iwlwifi: use device_schedule_reprobe()
  Bluetooth: hci_h5: use device_schedule_reprobe()
  Bluetooth: btintel_pcie: use device_schedule_reprobe() after reset

 drivers/base/base.h                           |   4 +
 drivers/base/dd.c                             | 171 ++++++++++++++++++
 drivers/bluetooth/btintel_pcie.c              |  47 +++--
 drivers/bluetooth/hci_h5.c                    |  43 +----
 .../net/wireless/intel/iwlwifi/iwl-trans.c    |  40 +---
 include/linux/device.h                        |   2 +
 6 files changed, 208 insertions(+), 99 deletions(-)


base-commit: 185c11232d5f586489bb3b74e6bcc7a6560ddd40
-- 
2.56.0