Anyone get txbf to work on ath10k when using the linux driver?

Ben Greear greearb at
Tue Nov 14 14:17:33 PST 2017

On 11/13/2017 07:10 PM, Ben Greear wrote:
> On 11/13/2017 06:05 PM, Sebastian Gottschall wrote:
>> Am 13.11.2017 um 23:50 schrieb Ben Greear:
>>> From what I can tell, the 10.4 firmware will not even enable txbf unless the driver
>>> tells it too, and I don't think the driver is doing the correct call to enable this
>>> (it is a testing interface hack, it appears).
>>> But, maybe I am missing something?
>> so the firmware does not take care about the vht flags?
> There is a flag to enable implicit beamforming, but it is mis-defined
> in the driver as far as I can tell:
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index ff15c37..9522f22 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -5195,7 +5195,8 @@ enum wmi_10_4_vdev_param {
> -#define WMI_TXBF_STS_CAP_OFFSET_MASK   0xf0
> +#define WMI_TXBF_STS_CAP_OFFSET_MASK   0x70
> +#define WMI_TXBF_CONF_IMPLICIT_BF       BIT(7)
>  #define WMI_BF_SOUND_DIM_OFFSET_MASK   0xf00
> Possibly that bit is somehow set anyway, dunno.
> And the other explicit-beamforming appears to need a special hack to enable
> the feature in the firmware.
> But, someone using my firmware gets txbf to work, so I must be missing something.
> I will dig into it more tomorrow.

At least much of my confusion is that there is a bunch of logic in the rate-ctrl
code about txbf probing, and I was thinking that was what caused the sounding to happen.

I now realize that is a separate feature (that cannot be enabled w/out special
driver hacks not currently supported).


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list