Linux wireless drivers development
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Miri Korenblit <miriam.rachel.korenblit@intel.com>,
	Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
	Hans de Goede <hansg@kernel.org>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: [PATCH v4 0/4] device_schedule_reprobe(): core helper and conversions
Date: Sat, 17 Oct 2026 09:55:17 +0100	[thread overview]
Message-ID: <cover.1792203271.git.daniel@makrotopia.org> (raw)

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@makrotopia.org/
[2] https://lore.kernel.org/all/cover.1786922210.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/all/cover.1787185594.git.daniel@makrotopia.org/
[4] https://lore.kernel.org/all/cover.1787281239.git.daniel@makrotopia.org/
[5] https://lore.kernel.org/all/cover.1788783126.git.daniel@makrotopia.org/
[6] https://lore.kernel.org/all/cover.1791035885.git.daniel@makrotopia.org/
[7] https://lore.kernel.org/all/aqlPPyblTK8c6-zZ@makrotopia.org/

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

             reply	other threads:[~2026-10-17  8:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  8:55 Daniel Golle [this message]
2026-10-17  8:56 ` [PATCH v4 1/4] driver core: add device_schedule_reprobe() Daniel Golle
2026-10-17  8:56 ` [PATCH v4 2/4] wifi: iwlwifi: use device_schedule_reprobe() Daniel Golle
2026-10-17  8:56 ` [PATCH v4 3/4] Bluetooth: hci_h5: " Daniel Golle
2026-10-17  8:57 ` [PATCH v4 4/4] Bluetooth: btintel_pcie: use device_schedule_reprobe() after reset Daniel Golle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1792203271.git.daniel@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=emmanuel.grumbach@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hansg@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=miriam.rachel.korenblit@intel.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox