From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: baochen.qiang@oss.qualcomm.com
Cc: ath11k@lists.infradead.org, ath12k@lists.infradead.org,
jjohnson@kernel.org, johannes@sipsolutions.net,
jtornosm@redhat.com, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 1/3] wifi: ath12k: fixes to improve MLO station stability
Date: Sat, 17 Oct 2026 10:04:43 +0200 [thread overview]
Message-ID: <20261017080444.41177-1-jtornosm@redhat.com> (raw)
In-Reply-To: <aaf175a7-86e0-4da2-a3fc-df87d906f800@oss.qualcomm.com>
Hi Baochen,
I agree that per-callback guards don't scale well long-term. Johannes
can comment better because both alternatives need mac80211 changes,
but let me share my thoughts.
Option 1 (recovery inside .start()) holds rtnl for ~1.3s, that seems
too long to hold.
Option 2 (split ieee80211_restart_hw() into early barrier + deferred
restart) looks like the right direction. It would benefit any driver
with async recovery, not just ath12k. But it is a mac80211 core change
and a bigger effort, and it still needs in_reconfig checks added to
callbacks that don't have them today (scan, for one), so the guarding
moves to mac80211 rather than disappearing.
In the meantime, the crashes this series fixes are real: without it,
an MLO firmware crash gives NULL derefs and 20+ second recovery. The
guards here cover the callbacks that actually run during that window,
not a speculative list.
I am happy to work on the mac80211 side (option 2), but would it make
sense for you to land this series as an interim fix while that is
worked out as a follow-up?
Thanks
Best regards
José Ignacio
next prev parent reply other threads:[~2026-10-17 8:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 17:49 [PATCH v2 0/3] " Jose Ignacio Tornos Martinez
2026-08-04 17:49 ` [PATCH v2 1/3] wifi: ath12k: fix MLO station firmware crash recovery Jose Ignacio Tornos Martinez
2026-10-15 5:51 ` Baochen Qiang
2026-10-17 8:04 ` Jose Ignacio Tornos Martinez [this message]
2026-10-17 9:33 ` Johannes Berg
2026-08-04 17:50 ` [PATCH v2 2/3] wifi: ath12k: prevent scan during firmware recovery Jose Ignacio Tornos Martinez
2026-08-04 17:50 ` [PATCH v2 3/3] wifi: ath12k: skip connection_loss_work for MLO beacon miss Jose Ignacio Tornos Martinez
2026-09-17 7:42 ` [PATCH v2 0/3] wifi: ath12k: fixes to improve MLO station stability Jose Ignacio Tornos Martinez
2026-10-13 16:44 ` Jose Ignacio Tornos Martinez
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=20261017080444.41177-1-jtornosm@redhat.com \
--to=jtornosm@redhat.com \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.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
all inboxes | Powered by JetHome®