From: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org,
Hari Naraayana Desikan Kannan <hnaraaya@qti.qualcomm.com>
Subject: Re: [PATCH wireless-next] wifi: mac80211: Fix ADDBA request rejection after MLD link removal
Date: Mon, 11 May 2026 16:02:16 +0530 [thread overview]
Message-ID: <0935f5fb-13cc-48a2-9aad-26e6a29538db@oss.qualcomm.com> (raw)
In-Reply-To: <cf877993914f9cee95fd5da1d9e57c838319a085.camel@sipsolutions.net>
On 5/11/2026 3:41 PM, Johannes Berg wrote:
> On Mon, 2026-05-11 at 15:40 +0530, Manish Dharanenthiran wrote:
>>
>> Even-then, if there is a actual change, it goes to invoke the UPDATE.
>> For the driver(s) which didn't implement the UPDATE yet, should we use
>> additional flags to notify the UPDATE support or returning a failure
>> from driver should be suffice?
>
> I hope drivers would refuse unknown operations, so I think returning a
> failure is fine. We can quickly review the drivers that handle this to
> make sure, but I'd prefer not to have a feature flag.
>
> johannes
Quickly checked the drivers which sets 'SUPPORTS_REORDERING_BUFFER',
- ath11k/ath12k drivers silently returns a failure if the 'op' is not
handled.
- Intel drivers do a 'WARN_ON_ONCE(1)' as default. Would need a change
to avoid calling warning for UPDATE operation.
- And Mediatek drivers return success as default. (I guess, this
should be fine, but would request comment from them about keeping this
behavior for UPDATE operation)
prev parent reply other threads:[~2026-05-11 10:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 6:51 [PATCH wireless-next] wifi: mac80211: Fix ADDBA request rejection after MLD link removal Manish Dharanenthiran
2026-04-27 10:00 ` Johannes Berg
2026-04-29 14:09 ` Manish Dharanenthiran
2026-05-07 18:26 ` Johannes Berg
2026-05-11 6:26 ` Manish Dharanenthiran
2026-05-11 8:46 ` Johannes Berg
2026-05-11 10:10 ` Manish Dharanenthiran
2026-05-11 10:11 ` Johannes Berg
2026-05-11 10:32 ` Manish Dharanenthiran [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=0935f5fb-13cc-48a2-9aad-26e6a29538db@oss.qualcomm.com \
--to=manish.dharanenthiran@oss.qualcomm.com \
--cc=hnaraaya@qti.qualcomm.com \
--cc=johannes@sipsolutions.net \
--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