All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Li <enderaoelyther@gmail.com>
To: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] wifi: iwlegacy: unregister the LED if 3945 hardware registration fails
Date: Thu, 29 Oct 2026 17:43:37 +0800	[thread overview]
Message-ID: <20261029094336.19250-2-enderaoelyther@gmail.com> (raw)
In-Reply-To: <20261029081955.GA10212@wp.pl>

Hi Stanislaw,

On Thu, Oct 29, 2026 at 09:19:55AM +0100, Stanislaw Gruszka wrote:
> On Wed, Oct 28, 2026 at 10:23:28PM +0800, Zhao Li wrote:
> > il3945_setup_mac() registers the LED before the mac80211 hardware, but
> > its registration error path does not call il_leds_exit(). The analogous
> > 4965 failure releases the driver and reaches its existing remove cleanup.
>
> Could you explain exacly how this is fixed in 4965?
> I do not see this in the code.

There is no il_leds_exit() in the 4965 error path itself. The caller
handles it: il4965_mac_setup_register() runs from the firmware callback,
and a failure there unbinds the driver.

  il4965_ucode_callback()
    il4965_mac_setup_register()   /* il_leds_init(), register_hw fails */
    goto out_unbind
      complete(&il->_4965.firmware_loading_complete)
      device_release_driver(&il->pci_dev->dev)
        il4965_pci_remove()
          il_leds_exit(il)
          ...
          ieee80211_free_hw(il->hw)

il4965_pci_probe() returns success after submitting the asynchronous
firmware request. If the callback reaches device_release_driver()
before probe finishes, the device lock serializes unbind with probe.
The callback completes firmware_loading_complete before unbinding,
and il4965_pci_remove() unregisters the LED regardless of
mac80211_registered.

3945 calls il3945_setup_mac() directly from il3945_pci_probe(), and the
probe error labels never call il_leds_exit(). ieee80211_free_hw() then
frees the il_priv that embeds il->led while the LED is still on
leds_list, so the next led_trigger_register() takes the trigger_lock of
a freed LED.

That should have been in the changelog. I'll send a v2 that spells out
the 4965 path; the code change stays the same.

Thanks,
Zhao

      reply	other threads:[~2026-10-29  9:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 14:23 [PATCH] wifi: iwlegacy: unregister the LED if 3945 hardware registration fails Zhao Li
2026-10-29  8:19 ` Stanislaw Gruszka
2026-10-29  9:43   ` Zhao Li [this message]

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=20261029094336.19250-2-enderaoelyther@gmail.com \
    --to=enderaoelyther@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stf_xl@wp.pl \
    --cc=wey-yi.w.guy@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.