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

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

[Wen Gong]

On 2020-12-21 05:06, Sustek Goran wrote:
> Hi, on my ath10k Chipset,
> QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/)
> afetr this patch i can not longer to initialize my card.
> 
> my dmesg log: So i need to revert this patch! Is my card need
> aditional support? Can you please guide what to do for my card to ahve
> OOB support in streamline kernels?
> 

If this patch introduce issue to you,
I think you can try to revert this patch.

> Regards,
> Goran.
> 
>  [Sun Dec 20 21:41:47 2020] ath: EEPROM regdomain sanitized
>  [Sun Dec 20 21:41:47 2020] ath: EEPROM regdomain: 0x64
>  [Sun Dec 20 21:41:47 2020] ath: EEPROM indicates we should expect a
> direct regpair map
>  [Sun Dec 20 21:41:47 2020] ath: Country alpha2 being used: 00
>  [Sun Dec 20 21:41:47 2020] ath: Regpair used: 0x64
>  [Sun Dec 20 21:41:47 2020] ath10k_pci 0000:07:00.0 wlp7s0: renamed
> from wlan0
> 
>  iw list
>  Wiphy phy0
>  max # scan SSIDs: 16
>  max scan IEs length: 199 bytes
>  max # sched scan SSIDs: 0
>  max # match sets: 0
>  Retry short limit: 7
>  Retry long limit: 4
>  Coverage class: 0 (up to 0m)
>  Device supports RSN-IBSS.
>  Device supports AP-side u-APSD.
>  Supported Ciphers:
>  * WEP40 (00-0f-ac:1)
>  * WEP104 (00-0f-ac:5)
>  * TKIP (00-0f-ac:2)
>  * CCMP-128 (00-0f-ac:4)
>  * CMAC (00-0f-ac:6)
>  * CMAC-256 (00-0f-ac:13)
>  * GMAC-128 (00-0f-ac:11)
>  * GMAC-256 (00-0f-ac:12)
>  * GCMP-128 (00-0f-ac:8)
>  * GCMP-256 (00-0f-ac:9)
>  * CCMP-256 (00-0f-ac:10)
>  Available Antennas: TX 0xf RX 0xf
>  Configured Antennas: TX 0xf RX 0xf
>  Supported interface modes:
>  * managed
>  * AP
>  * AP/VLAN
>  * monitor
>  * mesh point
>  Band 2:
>  Capabilities: 0x19ef
>  RX LDPC
>  HT20/HT40
>  SM Power Save disabled
>  RX HT20 SGI
>  RX HT40 SGI
>  TX STBC
>  RX STBC 1-stream
>  Max AMSDU length: 7935 bytes
>  DSSS/CCK HT40
>  Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
>  Minimum RX AMPDU time spacing: 8 usec (0x06)
>  HT TX/RX MCS rate indexes supported: 0-31
>  VHT Capabilities (0x339b79fa):
>  Max MPDU length: 11454
>  Supported Channel Width: 160 MHz, 80+80 MHz
>  RX LDPC
>  short GI (80 MHz)
>  short GI (160/80+80 MHz)
>  TX STBC
>  SU Beamformer
>  SU Beamformee
>  MU Beamformer
>  MU Beamformee
>  RX antenna pattern consistency
>  TX antenna pattern consistency
>  VHT RX MCS set:
>  1 streams: MCS 0-9
>  2 streams: MCS 0-9
>  3 streams: MCS 0-9
>  4 streams: MCS 0-9
>  5 streams: not supported
>  6 streams: not supported
>  7 streams: not supported
>  8 streams: not supported
>  VHT RX highest supported: 1560 Mbps
>  VHT TX MCS set:
>  1 streams: MCS 0-9
>  2 streams: MCS 0-9
>  3 streams: MCS 0-9
>  4 streams: MCS 0-9
>  5 streams: not supported
>  6 streams: not supported
>  7 streams: not supported
>  8 streams: not supported
>  VHT TX highest supported: 1560 Mbps
>  Bitrates (non-HT):
>  * 6.0 Mbps
>  * 9.0 Mbps
>  * 12.0 Mbps
>  * 18.0 Mbps
>  * 24.0 Mbps
>  * 36.0 Mbps
>  * 48.0 Mbps
>  * 54.0 Mbps
>  Frequencies:
>  * 5180 MHz [36] (24.0 dBm) (no IR)
>  * 5200 MHz [40] (24.0 dBm) (no IR)
>  * 5220 MHz [44] (24.0 dBm) (no IR)
>  * 5240 MHz [48] (24.0 dBm) (no IR)
>  * 5260 MHz [52] (24.0 dBm) (no IR, radar detection)
>  * 5280 MHz [56] (24.0 dBm) (no IR, radar detection)
>  * 5300 MHz [60] (24.0 dBm) (no IR, radar detection)
>  * 5320 MHz [64] (24.0 dBm) (no IR, radar detection)
>  * 5500 MHz [100] (disabled)
>  * 5520 MHz [104] (disabled)
>  * 5540 MHz [108] (disabled)
>  * 5560 MHz [112] (disabled)
>  * 5580 MHz [116] (disabled)
>  * 5600 MHz [120] (disabled)
>  * 5620 MHz [124] (disabled)
>  * 5640 MHz [128] (disabled)
>  * 5660 MHz [132] (disabled)
>  * 5680 MHz [136] (disabled)
>  * 5700 MHz [140] (disabled)
>  * 5720 MHz [144] (disabled)
>  * 5745 MHz [149] (30.0 dBm) (no IR)
>  * 5765 MHz [153] (30.0 dBm) (no IR)
>  * 5785 MHz [157] (30.0 dBm) (no IR)
>  * 5805 MHz [161] (30.0 dBm) (no IR)
>  * 5825 MHz [165] (30.0 dBm) (no IR)
>  * 5845 MHz [169] (disabled)
>  * 5865 MHz [173] (disabled)
>  Supported commands:
>  * new_interface
>  * set_interface
>  * new_key
>  * start_ap
>  * new_station
>  * new_mpath
>  * set_mesh_config
>  * set_bss
>  * authenticate
>  * associate
>  * deauthenticate
>  * disassociate
>  * join_ibss
>  * join_mesh
>  * remain_on_channel
>  * set_tx_bitrate_mask
>  * frame
>  * frame_wait_cancel
>  * set_wiphy_netns
>  * set_channel
>  * set_wds_peer
>  * probe_client
>  * set_noack_map
>  * register_beacons
>  * start_p2p_device
>  * set_mcast_rate
>  * connect
>  * disconnect
>  * channel_switch
>  * set_qos_map
>  * set_multicast_to_unicast
>  software interface modes (can always be added):
>  * AP/VLAN
>  * monitor
>  valid interface combinations:
>  * #{ managed } <= 1, #{ AP, mesh point } <= 16,
>    total <= 16, #channels <= 1, STA/AP BI must match
>  HT Capability overrides:
>  * MCS: ff ff ff ff ff ff ff ff ff ff
>  * maximum A-MSDU length
>  * supported channel width
>  * short GI for 40 MHz
>  * max A-MPDU length exponent
>  * min MPDU start spacing
>  Device supports TX status socket option.
>  Device supports HT-IBSS.
>  Device supports SAE with AUTHENTICATE command
>  Device supports scan flush.
>  Device supports AP scan.
>  Device supports per-vif TX power setting
>  Driver supports full state transitions for AP/GO clients
>  Driver supports a userspace MPM
>  Driver/device bandwidth changes during BSS lifetime (AP/GO mode)
>  Device supports static SMPS
>  Device supports configuring vdev MAC-addr on create.
>  max # scan plans: 1
>  max scan plan interval: -1
>  max scan plan iterations: 0
>  Supported TX frame types:
>  * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
> 0xc0 0xd0 0xe0 0xf0
>  * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
>  * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
> 0xc0 0xd0 0xe0 0xf0
>  * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
>  * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
>  * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
>  * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
> 0xc0 0xd0 0xe0 0xf0
>  * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
>  Supported RX frame types:
>  * IBSS: 0x40 0xb0 0xc0 0xd0
>  * managed: 0x40 0xb0 0xd0
>  * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
>  * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
>  * mesh point: 0xb0 0xc0 0xd0
>  * P2P-client: 0x40 0xd0
>  * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
>  * P2P-device: 0x40 0xd0
>  Supported extended features:
>  * [ VHT_IBSS ]: VHT-IBSS
>  * [ RRM ]: RRM
>  * [ SET_SCAN_DWELL ]: scan dwell setting
>  * [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
>  * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
>  * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
>  * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
>  * [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
>  * [ STA_TX_PWR ]: TX power control per station
>  root@u1804:~# dmesg -T

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Brian Norris]

On Mon, Dec 21, 2020 at 7:43 PM Wen Gong <wgong@codeaurora.org> wrote:
>
> On 2020-12-21 05:06, Sustek Goran wrote:
> > Hi, on my ath10k Chipset,
> > QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/)
> > afetr this patch i can not longer to initialize my card.
> >
> > my dmesg log: So i need to revert this patch! Is my card need
> > aditional support? Can you please guide what to do for my card to ahve
> > OOB support in streamline kernels?
> >
>
> If this patch introduce issue to you,
> I think you can try to revert this patch.

Kalle is still planning on applying my revert patch someday, I think:

https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/

We just have to wait.

Brian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

Brian Norris <briannorris@chromium.org> writes:

> On Mon, Dec 21, 2020 at 7:43 PM Wen Gong <wgong@codeaurora.org> wrote:
>>
>> On 2020-12-21 05:06, Sustek Goran wrote:
>> > Hi, on my ath10k Chipset,
>> > QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/)
>> > afetr this patch i can not longer to initialize my card.
>> >
>> > my dmesg log: So i need to revert this patch! Is my card need
>> > aditional support? Can you please guide what to do for my card to ahve
>> > OOB support in streamline kernels?
>> >
>>
>> If this patch introduce issue to you,
>> I think you can try to revert this patch.
>
> Kalle is still planning on applying my revert patch someday, I think:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/
>
> We just have to wait.

Actually I don't see how I could apply the revert due to the regulatory
problems explained by Jouni[1]. We cannot break regulatory rules.

[1] https://lore.kernel.org/ath10k/CANe27j+fur52HydqqzLc2hBV3QwC2La8+RTJcV=5W5LkUr=PqQ@mail.gmail.com/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Brian Norris]

On Wed, Dec 23, 2020 at 3:02 AM Kalle Valo <kvalo@codeaurora.org> wrote:
> Brian Norris <briannorris@chromium.org> writes:
> > Kalle is still planning on applying my revert patch someday, I think:
> >
> > https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/
> >
> > We just have to wait.
>
> Actually I don't see how I could apply the revert due to the regulatory
> problems explained by Jouni[1]. We cannot break regulatory rules.
>
> [1] https://lore.kernel.org/ath10k/CANe27j+fur52HydqqzLc2hBV3QwC2La8+RTJcV=5W5LkUr=PqQ@mail.gmail.com/

Thanks for pointing that out; I hadn't noticed that thread.

I'm not sure I totally agree with Jouni's logic there, but
(a) I don't have a huge stake in that (because for systems I care
about, I make sure the hardware gets shipped out with the correct
module programming) and
(b) it's probably best if discussion mostly stays on that thread.

But I still can't help myself: that feels like retroactive logic that
doesn't make sense. Jouni seems to imply that every module ever
shipped *must* have a programmed country code in order to comply with
regulations. My understanding is that systems could have been
compliant without such a country code (for example, shipping a
non-upstream driver; or enabling CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS
and specifying logic from user space; or other creative solutions
[1]). It's probably not ideal (because mainline Linux now doesn't
really know what to do), but possible. It unfortunately leaves a
sticky situation for these users, because they have to figure out how
to retroactively patch back in the original manufacturer's regulatory
strategy.

Brian

[1] I am quite familiar with a line of APs that ships this solution
(i.e., pulling its country code from the Device Tree, because the boot
flash has information about the country it was provisioned for):
https://chromium-review.googlesource.com/425619
I don't know what the module's EEPROM contains, but they're not relying on it.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Alvin Šipraga]

Hi Kalle,

On 12/23/20 12:01 PM, Kalle Valo wrote:
> Brian Norris <briannorris@chromium.org> writes:
> 
>> On Mon, Dec 21, 2020 at 7:43 PM Wen Gong <wgong@codeaurora.org> wrote:
>>>
>>> On 2020-12-21 05:06, Sustek Goran wrote:
>>>> Hi, on my ath10k Chipset,
>>>> QCA9984(https://compex.com.sg/shop/wifi-module/802-11ac-wave-2/wle1216v5-20-2/)
>>>> afetr this patch i can not longer to initialize my card.
>>>>
>>>> my dmesg log: So i need to revert this patch! Is my card need
>>>> aditional support? Can you please guide what to do for my card to ahve
>>>> OOB support in streamline kernels?
>>>>
>>>
>>> If this patch introduce issue to you,
>>> I think you can try to revert this patch.
>>
>> Kalle is still planning on applying my revert patch someday, I think:
>>
>> https://patchwork.kernel.org/project/linux-wireless/patch/20200527165718.129307-1-briannorris@chromium.org/
>>
>> We just have to wait.
> 
> Actually I don't see how I could apply the revert due to the regulatory
> problems explained by Jouni[1]. We cannot break regulatory rules.
> 
> [1] https://lore.kernel.org/ath10k/CANe27j+fur52HydqqzLc2hBV3QwC2La8+RTJcV=5W5LkUr=PqQ@mail.gmail.com/

Forgive me for insisting on this particular revert, but it still seems 
to me that the premise of the original patch is not correct. I tried to 
explain this in a reply[1] to Jouni's message that you linked, but I 
have not got a reply to that. Could you please clarify so that we can 
settle the issue and clarify what users can do (if anything)?

As it stands there are multiple reports of regression on the mailing 
list and only cursory discussion regarding the regulatory correctness of 
the patch. In the absence of such correctness (which I am trying to 
clarify) the regressions must surely be enough grounds for a revert?

As Brian mentioned in his revert patch[2] the original problem was 
resolved in firmware, and Wen has also agreed[3] that the patch should 
be reverted.

Kind regards,
Alvin

P.S. Sorry if the links in my mail are mangled - my employer's 
mailserver tends to vandalise incoming/outgoing mail.

[1] 
https://lore.kernel.org/ath10k/6a7e3314-6f91-cedb-1ffc-55ae9189dcf4@bang-olufsen.dk/
[2] 
https://lore.kernel.org/ath10k/20200527165718.129307-1-briannorris@chromium.org/
[3] 
https://lore.kernel.org/ath10k/9cc7efbb3c9b29e4553a427e6f58725f@codeaurora.org/
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

wgong@codeaurora.org writes:

> On 2019-12-02 18:08, Kalle Valo wrote:
>> Wen Gong <wgong@codeaurora.org> wrote:
>>
>>> Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is
>>> empty, then ath_is_world_regd will return false for this case, and
>>> it will lead function __ath_reg_dyn_country not work, thus the
>>> regdomain
>>> will not update for NL80211_REGDOM_SET_BY_COUNTRY_IE type, it result
>>> ath10k set the same regdomain/reg_5ghz_ctl/reg_2ghz_ctl to firmware,
>>> then the tx power will not changed with different regdomain's AP. The
>>> regulatory domain code of EEPROM of some QCA6174 PCIE chip is 0x6c, it
>>> means world wide regdomain, for this chip, it does not have the issue.
>>>
>>> For empty reulatory domain code chip, set it to world regulatory
>>> domain
>>> in functio ath_regd_sanitize, then it will fix the issue.
>>>
>>> Tested with QCA6174 SDIO with firmware
>>> WLAN.RMH.4.4.1-00029.
>>>
>>> Signed-off-by: Wen Gong <wgong@codeaurora.org>
>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>
>> Patch applied to ath-next branch of ath.git, thanks.
>>
>> 2dc016599cfa ath: add support for special 0x0 regulatory domain
> But I did not see it in ath-next now.
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/drivers/net/wireless/ath?h=ath-next
> is it has some delay?

Yes, it takes some time for me to apply other patches, merge branches,
servers sync etc. If you don't see the commit in the repository in 2
hours from me sending the "applied" mail, then do let me know as
something might be wrong. But before that just wait patiently :)

But now the commit is there:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=2dc016599cfa9672a147528ca26d70c3654a5423

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[wgong]

On 2019-12-02 18:08, Kalle Valo wrote:
> Wen Gong <wgong@codeaurora.org> wrote:
> 
>> Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is
>> empty, then ath_is_world_regd will return false for this case, and
>> it will lead function __ath_reg_dyn_country not work, thus the 
>> regdomain
>> will not update for NL80211_REGDOM_SET_BY_COUNTRY_IE type, it result
>> ath10k set the same regdomain/reg_5ghz_ctl/reg_2ghz_ctl to firmware,
>> then the tx power will not changed with different regdomain's AP. The
>> regulatory domain code of EEPROM of some QCA6174 PCIE chip is 0x6c, it
>> means world wide regdomain, for this chip, it does not have the issue.
>> 
>> For empty reulatory domain code chip, set it to world regulatory 
>> domain
>> in functio ath_regd_sanitize, then it will fix the issue.
>> 
>> Tested with QCA6174 SDIO with firmware
>> WLAN.RMH.4.4.1-00029.
>> 
>> Signed-off-by: Wen Gong <wgong@codeaurora.org>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> 
> Patch applied to ath-next branch of ath.git, thanks.
> 
> 2dc016599cfa ath: add support for special 0x0 regulatory domain
But I did not see it in ath-next now.
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/log/drivers/net/wireless/ath?h=ath-next
is it has some delay?

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

Wen Gong <wgong@codeaurora.org> wrote:

> Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is
> empty, then ath_is_world_regd will return false for this case, and
> it will lead function __ath_reg_dyn_country not work, thus the regdomain
> will not update for NL80211_REGDOM_SET_BY_COUNTRY_IE type, it result
> ath10k set the same regdomain/reg_5ghz_ctl/reg_2ghz_ctl to firmware,
> then the tx power will not changed with different regdomain's AP. The
> regulatory domain code of EEPROM of some QCA6174 PCIE chip is 0x6c, it
> means world wide regdomain, for this chip, it does not have the issue.
> 
> For empty reulatory domain code chip, set it to world regulatory domain
> in functio ath_regd_sanitize, then it will fix the issue.
> 
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-00029.
> 
> Signed-off-by: Wen Gong <wgong@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

2dc016599cfa ath: add support for special 0x0 regulatory domain

-- 
https://patchwork.kernel.org/patch/11266721/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Wen Gong]

Some sdio chips of rome QCA6174's regulatory domain code of EEPROM is
empty, then ath_is_world_regd will return false for this case, and
it will lead function __ath_reg_dyn_country not work, thus the regdomain
will not update for NL80211_REGDOM_SET_BY_COUNTRY_IE type, it result
ath10k set the same regdomain/reg_5ghz_ctl/reg_2ghz_ctl to firmware,
then the tx power will not changed with different regdomain's AP. The
regulatory domain code of EEPROM of some QCA6174 PCIE chip is 0x6c, it
means world wide regdomain, for this chip, it does not have the issue.

For empty reulatory domain code chip, set it to world regulatory domain
in functio ath_regd_sanitize, then it will fix the issue.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00029.

Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
 drivers/net/wireless/ath/regd.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 20f4f8ea9f89..bee9110b91f3 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
 
 /*
  * Some users have reported their EEPROM programmed with
- * 0x8000 set, this is not a supported regulatory domain
- * but since we have more than one user with it we need
- * a solution for them. We default to 0x64, which is the
- * default Atheros world regulatory domain.
+ * 0x8000 or 0x0 set, this is not a supported regulatory
+ * domain but since we have more than one user with it we
+ * need a solution for them. We default to 0x64, which is
+ * the default Atheros world regulatory domain.
  */
 static void ath_regd_sanitize(struct ath_regulatory *reg)
 {
-	if (reg->current_rd != COUNTRY_ERD_FLAG)
+	if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
 		return;
 	printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
 	reg->current_rd = 0x64;
-- 
2.23.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k