[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <76e53d3ef853fc963e7243194d7538d34a224a3a.camel@sipsolutions.net>
Date: Thu, 21 Jul 2022 16:43:46 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Linus Lüssing <linus.luessing@...3.blue>
Cc: "David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Toke Høiland-Jørgensen <toke@...e.dk>,
Kalle Valo <kvalo@...nel.org>, Felix Fietkau <nbd@....name>,
Simon Wunderlich <sw@...onwunderlich.de>,
Sven Eckelmann <sven@...fation.org>,
ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Linus Lüssing <ll@...onwunderlich.de>
Subject: Re: [PATCH] mac80211: Fix wrong channel bandwidths reported for
aggregates
On Tue, 2022-07-19 at 00:28 +0200, Linus Lüssing wrote:
>
> Therefore fixing this within mac80211: For an aggergated AMPDU only
> update the RX "last_rate" variable from the last sub-frame of an
> aggregate. In theory, without hardware bugs, rate/bandwidth info
> should be the same for all sub-frames of an aggregate anyway.
>
What if other drivers do it only on the first? :)
I'd be more inclined to squeeze in a "RATE_INVALID" flag or so somewhere
there in the rx status, and make it depend on that.
johannes
Powered by blists - more mailing lists