Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDUsubframe fails
From: Andreas Hartmann
Date: Mon Jan 07 2013 - 10:06:38 EST
Ben Hutchings wrote:
> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote:
>> On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote:
>>>> To be clear, I have all of these in the queue:
>>>> be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
>>>> 5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
>>>> ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
>>>> and I'm intending to drop/defer them all.
>>> Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches,
>>> or only patch 2.
>> No, actually all 3 patches have to be applied. Because last one, except
>> revert, include flag IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL setting in rt2x00
>> driver, which make patch 2 work.
> Andreas said that that after ab9d6e4ffe19 there was still a regression.
> But maybe he was confused. I know I'm confused.
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the
requirements of mac80211).
Both workarounds, mine and the new workaround from Stanislaw (which is
nothing more than a restricted version of my initial workaround), work
Let the peer do the aggregation handling. If it's not done by the peer,
the connection will break down.
The solution would be IMHO, to implement an own aggregation handling,
maybe the same way as it was done for carl9170, which had the same problem:
I prefer to have solutions (if one is known) instead of another workaround.
If I use my device as STA instead of an AP, it even works fine w/o
Stanislaws patch. Do you understand what I'm trying to say?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/