[PATCH] Revert "ath: add support for special 0x0 regulatory domain"

[Alvin Šipraga]

Hi Kalle,

On 7/30/20 2:49 PM, Alvin Šipraga wrote:
> This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
> 
> Per Atheros documentation to manufacturers, the EEPROM regulatory domain
> code 0x0 must always map to "US". In particular, it should not map to a
> custom world regulatory domain. For references, see [1] and [2] below.
> Furthermore, __ath_regd_init() has a specific condition to set the
> country code to "US" in this case, which emits the following log
> message:
> 
> [    7.814307] ath: EEPROM indicates default country code should be used
> 
> The patch being reverted mistakenly maps 0x0 to the custom world
> regulatory domain 0x64 - the most restrictive of the world regulatory
> domains. The premise of the patch is that in the case of EEPROM
> regulatory domain code 0x0, ath_is_world_regd() should return true. But,
> as stated above, 0x0 should not map to a world regulatory domain, and so
> the function should return false. The original behaviour, whereby
> NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
> the manufacturer's intent and should not have been changed.
> 
> [1] https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
> [2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
> 
> Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
> Cc: Wen Gong <wgong at codeaurora.org>
> Cc: Luis R. Rodriguez <mcgrof at kernel.org>
> Cc: linux-wireless at vger.kernel.org
> Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
> Signed-off-by: Alvin Šipraga <alsi at bang-olufsen.dk>
> ---
>   drivers/net/wireless/ath/regd.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
Do you have any feedback on this patch? No problem if you simply have 
not looked yet - I am not sure what kind of lead time to expect on the 
list. But without the patch, a (correctly) programmed 0x0 (US) card will 
not be able to operate on 5GHz channels without some hacking. I have 
cited some references to justify reverting this patch, so I would like 
to know if anything further should be done to get this into future kernels?

I wonder also if Wen Gong could comment, whose patch I am reverting in 
the first place. Maybe there is something I am missing?

Kind regards,
Alvin