Re: [PATCH 00/10] carl9170: 802.11n compliance and driver improvements

[Jeff Johnson <jeff.johnson@oss.qualcomm.com>]

On 3/12/2026 3:37 AM, Masi Osmani wrote:
> The carl9170 driver for Atheros AR9170-based USB WiFi adapters has been
> effectively unmaintained since 2016.  While the hardware shipped as
> Draft-N certified, several 802.11n capabilities were never advertised
> to mac80211, diagnostic counters were left as TODO stubs, and some
> hardware features were never wired up.
> 
> This series addresses these gaps in 10 independent patches, ordered
> from simple HT capability flags to more involved PHY programming:
> 
> Patches 1-3: HT capability corrections
>   - Enable SGI_20 (was only SGI_40)
>   - Advertise RX STBC (1 spatial stream)
>   - Document the SMPS handler (replacing bare TODO)
> 
> Patches 4-5: Diagnostic counters
>   - Wire up the RX dropped frame counter
>   - Track PHY errors via debugfs
> 
> Patch 6: TX power calibration
>   - Replace hardcoded 18 dBm with per-channel EEPROM values
> 
> Patch 7: Recovery hardening
>   - Add exponential backoff to prevent restart storms
> 
> Patch 8: Antenna diversity
>   - Enable fast antenna diversity for 2-chain devices
> 
> Patch 9: DFS radar detection
>   - Program radar registers, call ieee80211_radar_detected()
> 
> Patch 10: Runtime IQ calibration
>   - Periodic I/Q recalibration via existing stat_work timer
> 
> All patches are individually compile-tested and have been verified
> on real hardware (AVM Fritz!WLAN USB Stick N, AR9001U) running
> kernel 6.18.12.  Each patch applies and compiles independently on
> top of the previous ones.
> 
> The ath9k PCI driver for the same chipset family serves as the
> primary reference for register programming and capability flags.
> 
> Masi Osmani (10):
>   carl9170: mac80211: enable Short Guard Interval for 20 MHz
>   carl9170: mac80211: advertise RX STBC capability
>   carl9170: mac80211: document spatial multiplexing power save handler
>   carl9170: rx: wire up dropped frame counter
>   carl9170: rx: track PHY errors via debugfs
>   carl9170: phy: populate per-channel TX power from EEPROM
>   carl9170: main: add exponential restart backoff
>   carl9170: phy: enable antenna diversity for 2-chain devices
>   carl9170: fw: enable DFS radar detection
>   carl9170: phy: add periodic runtime IQ calibration
> 
>  drivers/net/wireless/ath/carl9170/carl9170.h |   5 +
>  drivers/net/wireless/ath/carl9170/debug.c    |   2 +
>  drivers/net/wireless/ath/carl9170/fw.c       |   3 +
>  drivers/net/wireless/ath/carl9170/main.c     |  45 ++++-
>  drivers/net/wireless/ath/carl9170/phy.c      | 194 +++++++++++++++++++
>  drivers/net/wireless/ath/carl9170/rx.c       |  23 ++-
>  6 files changed, 261 insertions(+), 11 deletions(-)
> 
> --
> 2.51.0
> 
> 

In addition to the 10 patches in this series you then posted an additional set
of 2 patches (labeled 11/12 and 12/12) and then another set of patches
(labeled 13/16..16/16). This disjoint labeling makes it hard to track the
patches in patchwork since they aren't all associated to the same series:
https://patchwork.kernel.org/project/linux-wireless/list/?submitter=220736

In addition, the 3 separated disjoint series aren't threaded together in my
e-mail client.

Likewise, posting an update to one patch is not handled well either:
[PATCH v2 07/16] carl9170: main: add exponential restart backoff

When adding to a series or updating one or more patches in a series it is a
best practice to send a new version of the entire series so that the current
state of all patches in the series is captured.

That said, 3 of 16 the patches were ACKed by Christian so I've picked up those
three patches into my 'pending' branch:
carl9170: mac80211: document spatial multiplexing power save handler
carl9170: rx: track PHY errors via debugfs
carl9170: cmd: downgrade transient register I/O errors to wiphy_dbg

Note that I added a wifi: prefix to all to align with the wireless patch style
as previously reminded by Johannes:
<https://lore.kernel.org/linux-wireless/9d093d8a8df188c99b9b652bb56a5c1faecef6c7.camel@sipsolutions.net/>

See:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/log/?h=pending

Once you see those have been accepted I suggest you rebase your work on the
ath.git main branch and then post a v3 series containing all of the remaining
patches, incorporating any feedback and experience gained since they were
originally posted.

/jeff