ath11k: Country code setting ignored on bootup

[Sriram R]

> This seems to be a race between receiving the
> "ATH11K_QMI_EVENT_FW_READY" event and the ieee80211_register_hw() in
> __ath11k_mac_register. The ieee80211_register_hw will make the hw
> responsible for handling the regd updates but they will not be
> correctly processed until the ATH11K_QMI_EVENT_FW_READY was handled by
> the firmware. And if the regd change was processed after
> ath11k_regd_update was called in __ath11k_mac_register (but before the
> ATH11K_QMI_EVENT_FW_READY was processed) then we will just loose the
> regd change.
Agree that there is a possibility of a race between FW reg event
for user regd update and where the ATH11K_REGISTERED flag gets
set in the above scenario.
> 
> So I am a little bit baffled why ATH11K_FLAG_REGISTERED is bound to
> something which is not related to the  IEEE802211 registration code.
> Sounds to me like somebody wanted a FW_READY flag but misused the
> ATH11K_FLAG_REGISTERED flag for this purpose.
> 
> Btw. there are similar problems with the use of ATH11K_FLAG_REGISTERED
> in context of ath11k_debug_pdev_create, ath11k_mac_register and
> ath11k_mac_allocate.
> 
> Maybe something like the attached patch could be used to improve this 
> situation.
> 
With and without this patch, i also see there are slight chances the
default regd (provided by fw during 
init) can get overwritten by new reg rules
from FW in similar scenario you had mentioned.
But, Overwriting of default regd is not allowed.

I get a feeling that we can remove the use of ATH11k_FLAG_REGISTERED for 
the
purpose of checking whether to update default or new_regd.

Since the default reg rules wil be received only once per pdev on FW 
load,
the above flag based check can be replaced with a check to see
if default_regd is already set, so that we can now update the new_regd. 
Also if the
new_regd is set, irrespective of the argument in ath11k_regd_update() we 
can use
the new_regd data then to update the reg info for the phy.

This would avoid both overwriting of the default regd as well as the 
race you
had mentioned and also a possibility of another case where default_regd 
overwrites new_regd
after the previous call to regulatory_set_wiphy_regd_sync_rtnl.

Do you see any issues?

btw, i dont see any possible issues in current usage of 
ATH11k_FLAG_REGISTERED in
  ath11k_debug_pdev_create, ath11k_mac_register and ath11k_mac_allocate
since they sequenced and fall within the same context. Do you face any 
issues?

Thanks,
Sriram.R

> Kind regards,
> Sven