ath12k: board specific SAR table and coex settings on a devicetree platform (WCN7880)

ath12k: board specific SAR table and coex settings on a devicetree platform (WCN7880)

[Vladyslav Tymoshchuk]

Hi Jeff,

I am porting mainline to the OnePlus Pad 3 (SM8750, WCN7880 hw2.0 over
PCIe, firmware WLAN.GNG.1.0-03342). Wi-Fi works on a local branch, and I
would like to ask how you want two board specific settings to reach the
firmware before I send anything beyond the WCN7880 support itself. Both
are handled by the vendor stack today, and both are properties of the
board, not of the chip.

1. SAR table selection

The board data of this tablet has SAR V2 tables. The stock user space
always selects one of them per chain (index 6 for both chains): the
vendor driver sends WMI_SAR_LIMITS_CMDID with SAR enabled as V2 and the
table index in each row. Without that selection the firmware runs at
the target and regulatory power of the board data, which is above the
SAR level the device was certified with.

On ACPI laptops ath12k takes the BIOS SAR table from the DSM and sends
WMI_PDEV_SET_BIOS_SAR_TABLE_CMDID. A devicetree board has no such source,
and ath12k has no set_sar_specs, unlike ath11k (enabled for the AHB
WCN6750 in 2023). The limits the device was certified with live in the
board data as table indices, not as dBm values that user space could
hand over through NL80211_CMD_SET_SAR_SPECS.

Which of these would you accept?
  a) a devicetree property of the wifi node with the default SAR V2
     table index, in the spirit of qcom,calibration-variant selecting
     the board data;
  b) set_sar_specs in ath12k as in ath11k, with user space providing
     limits per frequency range (the board would then need its limits
     as dBm values from somewhere else);
  c) something else you have in mind.

On my branch the WMI parts (the SAR capability in the service ready
ext event, the SAR V2 limits command, the SAR2 result event) are
generic; only the index comes from a module parameter for now, which I
do not intend to send.

2. WLAN/Bluetooth coexistence settings

The vendor driver sends WMI_COEX_CONFIG_CMDID per station vdev with the
values of the board's WCNSS_qcom_cfg.ini: tx power while BT is active,
antenna isolation, BT RSSI and interference thresholds, TDD mode. With
none of them sent, A2DP audio drops out on this board while Wi-Fi is
busy on 2.4 GHz; with the stock values it does not.

The command itself is generic, but antenna isolation and the power
limits belong to the board. Would devicetree properties of the wifi node
be acceptable here (ath10k has qcom,coexist-support and
qcom,coexist-gpio-pin), with chip defaults in hw_params otherwise, or
do you prefer another source?

3. A scan observation, in case it is known

With no vdev started, a scan that mixes 2.4 GHz or lower 5 GHz channels
(up to 5330 MHz) with upper 5 GHz or 6 GHz channels does not report the
lower 5 GHz BSSes on this firmware, while the same channels scanned on
their own are found every time. A connection manager at boot then sees
only the 2.4 GHz BSS of a dual band access point. Splitting the scan in
the host works around it, but I would rather not send that. Is this a
known firmware issue, or is there a scan parameter the firmware expects
for this case?

Thanks,
Vladyslav

(I used an AI assistant, Claude, for the analysis and to draft this
mail; the tests ran on my device.)