[snokvist]

What this is

On the 8822B (Jaguar2), set_channel_bw writes the BW20 RX DFIR set at every channel width. The vendor phydm_rxdfirpar_by_bw_8822b switches it by width. The 8821C path in the same file already does. This PR makes the 8822B path match the vendor function.

What changed

HalJaguar2::set_channel_bw now picks the RX DFIR from bw:

Width	0x948[29:28]	0x94c[29:28]	0xc20[31] = 0xe20[31]
40 MHz	1	0	0
80 MHz	2	1	0
20 / 10 / 5 MHz	2	2	1 (unchanged)

Verification

Hardware: an 8812BU (8822B cut 3, RFE 3) on USB 3, ch36 primary.

• Post-DFIR band, measured through the LA ring. Noise-floor width at −6 dB, fixed gain (IGI 0x30, OFDM CCA off), median PSD of 3 × 16384 samples:

  	master	this PR
  BW40, LA 40 MS/s	±10.6 MHz	±19.9 MHz
  BW80, LA 80 MS/s	±11 MHz, 47 % adjacent duplicate samples	±38 MHz, 0.01 % duplicates

  With the BW20 set, 0xc20[31] = 1 forces the narrow path whatever 0x948/0x94c hold.

• rxdemo, 20 MHz frames. DEVOURER_BW=40/80, 15 s × 2 rounds against the ambient 20 MHz AP on the primary channel. Frame counts are within noise of master: 16/15 and 15/15 at BW40, 19/16 and 21/13 at BW80. There is no regression for primary-channel 20 MHz frames.

• ctest: 100 % passed (83, 2 skipped as on master).

Not verified

I have no 40/80 MHz-wide transmitter on the bench, so frame-level reception of wide-band PPDUs is not measured here. The vendor code and the existing comment above this block, "the RX DFIR must match the bandwidth", are the argument that it matters for them.

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Select 8822B RX DFIR settings by channel width

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Select vendor RX filter settings for 40 and 80 MHz instead of always using 20 MHz settings.
• Preserve the existing filter settings for 20, 10, and 5 MHz.

Diagram

graph TD
  W["Channel width"] --> D{"Width?"} -->|40 MHz| F40["40 MHz set"] --> R["RX DFIR registers"] --> O["Post-DFIR signal"]
  D -->|80 MHz| F80["80 MHz set"] --> R
  D -->|20/10/5 MHz| F20["20 MHz set"] --> R

Loading

High-Level Assessment

Keep the selection local to the 8822B channel-width path: it follows the vendor's per-width values while leaving narrow-width behavior unchanged. Sharing the 8821C implementation would obscure chip-specific register differences.

Files changed (1) +19 / -6

Bug fix (1) +19 / -6

HalJaguar2.cppChoose 8822B RX DFIR register values by bandwidth +19/-6

Choose 8822B RX DFIR register values by bandwidth

• Replaces unconditional 20 MHz RX DFIR writes with vendor values for 40 and 80 MHz. Retains the previous values for 20, 10, and 5 MHz, and documents the measured post-filter bandwidth difference.

src/jaguar2/HalJaguar2.cpp

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit a51ca61 ⚖️ Balanced

Results up to commit a51ca61

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[snokvist]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit a51ca61

[josephnef]

Reviewed against the vendor source and tested on air. Approving.

Code. The per-width values for 0x948/0x94c/0xc20/0xe20 match phydm_rxdfirpar_by_bw_8822b exactly, including the 20/10/5 MHz fallthrough.

On-air A/B (your "Not verified" gap). An 8812EU (Jaguar3, master txdemo) sent real HT40 / VHT80 frames on ch36 to an 8812BU (8822B cut 3, CF-924AC 0bda:b812), which received at the same width. 1500 frames per cell, 2 reps, master and this PR alternating. Delivery = canonical-SA hits / frames sent:

Rate	master	this PR
MCS1/40	83.2 %	86.7 %
MCS4/40	35.0 %	86.8 %
MCS7/40	0.1 %	98.6 %
VHT1SS MCS1/80	0.0 %	96.0 %
VHT1SS MCS4/80	0.0 %	95.8 %
VHT1SS MCS7/80	0.0 %	96.8 %

Control: MCS7 at 20 MHz, where both builds write the same registers, gave 34/54 % on master and 63/44 % on this PR. That is run-to-run scatter on this pair, not a regression. MCS7 also does worse at 20 MHz than at 40 MHz here, which I haven't explained; it is the same on both builds.

So frame-level reception of wide PPDUs on the 8822B was broken on master: nothing at 80 MHz, and a cliff at 40 MHz that we had blamed on this adapter's margin. This fixes both.

Nit, non-blocking: the code comment says ±37 MHz, the PR body says ±38.