From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from e3i207.smtp2go.com (e3i207.smtp2go.com [158.120.84.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7AFF136B046 for ; Tue, 17 Feb 2026 13:39:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.120.84.207 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771335552; cv=none; b=Ue8iOWHbpyC30/EsxGXGTXft4VsctWC2jxHvQtHK32WVn+N3h9ORpKagrLMyWHYMHG8RCb2KppzevPOdReSAuqkLU3NoA/PbvW1fayPJS5fKEB1iBH9/ltfB8bmrOczZomJDDDkZ62BeybduSMRKUNGIyJqT1z+4kGWDrWRpIDI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771335552; c=relaxed/simple; bh=5Mhe4SHmdFJJwuXBCn5tVcEJ/+LjMSjti1wjYkkdBF8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qfree9RRqJmeOkDb+QmhQASb4UqR1qLdaxn6ifddCNLk6i7mqs28WnRi7xdN6zFp0pBU7IBalhV34w10vLNFHQ7rUtDm7Twft5LKjph2FcjWX/WIY7fqyeZvPmXU9ieZkKjLKrglJGKkG53IDMk3eSgw3ZgcCiUB1GHwHOzORXg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt; spf=pass smtp.mailfrom=em510616.triplefau.lt; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b=eN5qOczd; arc=none smtp.client-ip=158.120.84.207 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=em510616.triplefau.lt Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b="eN5qOczd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=triplefau.lt; i=@triplefau.lt; q=dns/txt; s=s510616; t=1771334640; h=from : subject : to : message-id : date; bh=robDNmnieWjOptib6IYbtmkQe43LQOtTLbAFyHIKkKk=; b=eN5qOczdClNlybiKOyyOkooLHLjwhbVpbmcVmnowv5p05Ynl3gh3Af7UX5ENKAwfHH/DW GmZljNA5qOoZkkLfGlB8vmHYQaLG0tyChx3xZ7TorgHU3Dtmez/PD+9ClJkKf6Gk85PE4Qg Scfi0DaMqJmvFgrsg8nmAvSTTv7/rXa6QKjPQCTZHCgbgvOrdNzKUuyU7x1t/RGC222W6Be 4EwNJOgmRqqZQNP6rtPBxh0g9zt2hoeaRQ6W5SuKWgEvedUBlDQlRU+y66bDOV8cM05ZV35 AS5rIqXrpBku8QcDu7pGp/jxKhIHHUrauG3aegqtQo2orTZjM/cMz9h6zk1g== Received: from [10.12.239.196] (helo=localhost) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.99.1-S2G) (envelope-from ) id 1vsL3U-AIkwcC8mK9a-KauJ; Tue, 17 Feb 2026 13:23:56 +0000 Date: Tue, 17 Feb 2026 14:05:24 +0100 From: Remi Pommarel To: Johannes Berg Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH wireless] wifi: mac80211: Fix ADDBA update when HW supports reordering Message-ID: References: <5806bab7e46506d3c300ab4eb66989d42936aeb0.1771323902.git.repk@triplefau.lt> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 510616m:510616apGKSTK:510616sbru8S-D2W X-smtpcorp-track: S54aFebZHkP5.PV2bCWmyWgbY.d0mX0QCt3ev On Tue, Feb 17, 2026 at 12:30:08PM +0100, Johannes Berg wrote: > On Tue, 2026-02-17 at 11:36 +0100, Remi Pommarel wrote: > > Commit f89e07d4cf26 ("mac80211: agg-rx: refuse ADDBA Request with timeout > > update") added a check to fail when ADDBA update would change the > > timeout param. > > > > This param is kept in tid_ampdu_rx context which is only allocated on HW > > that do not set SUPPORTS_REORDERING_BUFFER. Because the timeout check > > was done regardless of this param, ADDBA update always failed on those > > HW. > > Seems like a legit problem, but > > > Fix this by only checking tid_ampdu_rx->timeout only when > > SUPPORTS_REORDERING_BUFFER is not set. > > that doesn't seem right? Especially the way you implemented it, it won't > even respond at all when it's an update and SUPPORTS_REORDERING_BUFFER > is set. I could be wrong but I think the patch format here make it difficult to read. If it's an update and SUPPORTS_REORDERING_BUFFER is set, the following "if" in the code (not fully visible in the diff here) will end calling drv_ampdu_action(). > > Seems we perhaps just need to store the timeout elsewhere? > That is another way of fixing that yes, but the question here is, don't we want the driver to decide if it wants to support timeout update ? > > @@ -374,14 +383,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta, > > goto end; > > } > > > > - ht_dbg_ratelimited(sta->sdata, > > - "unexpected AddBA Req from %pM on tid %u\n", > > - sta->sta.addr, tid); > > - > > - /* delete existing Rx BA session on the same tid */ > > - __ieee80211_stop_rx_ba_session(sta, tid, WLAN_BACK_RECIPIENT, > > - WLAN_STATUS_UNSPECIFIED_QOS, > > - false); > > } > > Also, nit, but this leaves a blank line at the end of the block. Sure will remove that if we finally decide to keep the fix as is. Thanks for the review. -- Remi