ath9k: Deaf QCA9558 when setting rxchainmask

[Sven Eckelmann <sven@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Hi,

I've needed to test some problems with a QCA9558 Rev 0 based 3x3 2.4G device. 
During these tests I've wanted to try different antenna configurations to 
reduce the complexity of the problem. This was done by setting the 
rxchainmask/txchainsmask to settings like 1, 5 and 7. Unfortunatelly, the 
setting 5 (antenna 0 and 1) turned the device completely deaf. Here an 
overview of the settings (excerpt)

chainmask | ant 0 | ant 1 | ant 2 | Status
1         | 1     | 0     | 0     | works
5         | 1     | 0     | 1     | deaf
7         | 1     | 1     | 1     | works

The antenna setting is used in ath9k at different places but trigger seems to 
be the AR_PHY_RX_CHAINMASK register write in ar9003_phy.c in the function 
ar9003_hw_set_chain_masks. Forcing it to 7 instead of the requested 5 avoids 
this deaf state (but makes the rx chainmask setting useless). Of course, this 
is not a valid workaround and quite unexpected.

The test platform was a current trunk OpenWrt build together with compat-
wireless 2013-02-22, compat-wireless 2013-06-27 and backports 2013-10-31. The 
settings were configured using the txantenna and rxantenna of the OpenWrt 
wireless config system. Both were always set to the same values during the 
tests.

The deaf state was identified using 1x1 and 2x2 clients which could receive 
the beacons of the device. The QCA9558 device was then unable to receive the 
probe request from the clients or any other traffic on the air. This was also 
checked by a monitor (flags: control) interface on the same phy.

Maybe someone knows whether this is a known problem with this SoC or what 
information can be gathered to debug this problem further.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]