b43: ac rev1 captured packets with ampdu

[Alessio Ferri]

Il giorno Sat, 10 Oct 2026 12:59:10 +0000
"andreas.wendleder" <andreas.wendleder at proton.me> ha scritto:

> Hi Alessio,
> 
> Three findings on the MacBookAir6,1 (2.4 GHz, ucode 832.127), all
> thanks to your code and captures:
> 
> 1. RX level. Your rxgainctrl write 0x1726 = 0x000c is worth 26 dB
> here. With it my remaining PHY table replay is gone. 2. Second TX
> chain. The chipcontrol |= 0x8 at the end of your fem2_sub1_setup is
> what turns on TX on core 1. I had ported the two PHY writes but not
> that one: core 1 did not radiate and MCS 8–15 failed completely. The
> bit survives a module reload, so it only shows after a cold boot. 3.
> A-MPDU TX works, with the microcode building the aggregates as in
> your notes. What it needed beyond 0x45c0 and the cache info:
>    - the frame's seq_ctrl in the header's sequence field;
>    - cache info bytes 0–1 zero when encrypting in software. The stock
> 50 04 makes the microcode encrypt again: the AP acks the frame and
> drops it;
>    - session frames reported to mac80211 with
> IEEE80211_TX_STAT_AMPDU, or minstrel_ht ignores them;
>    - the attempt count of a status (word 2, bits 7:0) divided by its
> MPDU count;
>    - a requeue in the driver for MPDUs the microcode reports unacked.
> It gives up after a few attempts, and without the requeue TCP
> collapses.
> 
>    Result: about 30 Mbit/s up at HT20 over 15 minutes, against 20 at
> legacy rates.
> 
> One question: my TX gain sits at index 64 of
> acphy_txgain_epa_2g_2069rev4 (the reset value), and going to index 96
> collapses the link at 1 m from the AP. Have you seen what a healthy
> board transmits with on 2.4 GHz, or is there more to the PA/FEM setup
> than fem2_sub1_setup?
> 
> Thanks, Andreas

Increasing bits density per air time cause transmission power to drop,
as the modulation is more sensitive to distortion. By raising the index
you reduce power, so it works better near the device and much worse
from afar.