Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Peter Oh]

Hi Anilkumar,


On 03/27/2018 11:37 PM, Sven Eckelmann wrote:

On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote:
[...]

The rate average and throughput are relative. no?

Can you share the output number from your new function?
It may help us to understand a little bit more how well the new function 
works.


Thanks,
Peter

Re: [PATCH 2/2] ath10k: support MAC address randomization in scan

[Brian Norris]

Hi Carl,

On Fri, Mar 30, 2018 at 11:14:00AM +0800, Carl Huang wrote:
> The ath10k reports the random_mac_addr capability to upper layer
> based on the service bit firmware reported. Driver sets the
> spoofed flag in scan_ctrl_flag to firmware if upper layer has
> enabled this feature in scan request.
> 
> Test with QCA6174 hw3.0 and firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1,
> but QCA9377 is also affected.
> 
> Signed-off-by: Carl Huang 
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 17 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h | 22 ++
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c | 25 +
>  drivers/net/wireless/ath/ath10k/wmi-tlv.h | 11 +++
>  drivers/net/wireless/ath/ath10k/wmi.c |  5 +
>  drivers/net/wireless/ath/ath10k/wmi.h |  9 +
>  6 files changed, 89 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index ebb3f1b..c5cd5e5 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5699,6 +5699,12 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
>   arg.scan_ctrl_flags |= WMI_SCAN_FLAG_PASSIVE;
>   }
>  
> + if (req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
> + arg.scan_ctrl_flags |=  WMI_SCAN_ADD_SPOOFED_MAC_IN_PROBE_REQ;
> + ether_addr_copy(arg.mac_addr.addr, req->mac_addr);
> + ether_addr_copy(arg.mac_mask.addr, req->mac_addr_mask);
> + }
> +
>   if (req->n_channels) {
>   arg.n_channels = req->n_channels;
>   for (i = 0; i < arg.n_channels; i++)
> @@ -8397,6 +8403,17 @@ int ath10k_mac_register(struct ath10k *ar)
>   goto err_dfs_detector_exit;
>   }
>  
> + if (test_bit(WMI_SERVICE_SPOOF_MAC_SUPPORT, ar->wmi.svc_map)) {
> + ret = ath10k_wmi_scan_prob_req_oui(ar, ar->mac_addr);
> + if (ret) {
> + ath10k_err(ar, "failed to set prob req oui: %i\n", ret);
> + goto err_dfs_detector_exit;
> + }
> +
> + ar->hw->wiphy->features |=
> + NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;

Do you support NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR too?

> + }
> +


Brian

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

It seems you are already pissed off, but could you please reply inline 
instead of top posting. Its a drag to scroll up and down.


On 4/12/2018 7:05 PM, solsTiCe d'Hiver wrote:

Hi.

I thought I made myself clear.
I leave in France. My system(s) is/are set up to use FR as default
regulatory domain.

But when I plug in that tp-link card, I am restricted to use CN
regulatory domain. Why am I the only one to see this as a problem ?


unlikely you are the only one.


I know that one can only have one regdom defined on the system. I have
set it up myself. So why is it changed behind my back by some card or
whatever ?


so:
Alfa = rt2800usb = FR
> country FR: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
TP-Link = ath9k_htc = CN
>country CN: DFS-FCC
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 44), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)

The FR setting may or may not be your doing. You seem to indicate having 
done 'iw reg set FR'. So as to why it changed behind your back is 
because that card indicates it is certified to work in CN regulatory 
domain and your system is configure to work in FR domain. So the 
regulatory code in the kernel has to take action and as Steve explains 
it creates an intersection domain named '98'.


> country 98: DFS-UNSET
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 40), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)

So it is not as you say that your Alfa device now operates in CN domain, 
but in the 98 domain. As you can see it creates rules different from FR 
and CN picking the lowest power of the two.



Like I said, I am left with the option, to disable crda, or to use 2
systems, one for each card !


So yeah, plugging multiple cards in a system limits your options, but 
you still have channels to operate in unless you are otherwise 
restricted by AP(s) used.


Regards,
Arend

Re: [PATCH] ANDROID: mac80211_hwsim: support/ignore power state changes

[Johannes Berg]

On Thu, 2018-04-12 at 17:04 +, Roman Kiryanov wrote:
> Hi Kalle,
> 
> thank you for reviewing our patch. I am ok with applying this patch without
> "ANDROID:" prefix. Do you want me to send an updated patch?

I can fix it up.

johannes

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 5:52 PM, Dan Williams wrote:

On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:

On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
 wrote:

On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:


Hi.

This is beyond my comprehension that you could assert this is a
non issue.



Well. I am just saying that it is by design. There is no way for
the
regulatory code to determine where you and your hardware actually
reside so
instead it takes a conservative approach.



To say it another way: mixing regulatory domains on your host system
should result in a _smaller_ set of channels - ie only those channels
at the intersection of the two.

And another wrinkle to consider - one of the 802.11 amendments (can't
remember which one) actually causes the radio to listen to the


802.11d I believe, from the early 2000s.


Correct.

Regards,
Arend

Re: [PATCH] ath9k: introduce endian_check module parameter

[Martin Blumenstingl]

Hello Bas,

On Tue, Apr 10, 2018 at 11:05 AM, Bas Vermeulen  wrote:
> On 14-03-18 15:34, Kalle Valo wrote:
>>
>> Bas Vermeulen  writes:
>>
>>> --- a/drivers/net/wireless/ath/ath9k/init.c
>>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>>> @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
>>> module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
>>> MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
>>> +static int ath9k_endian_check;
>>> +module_param_named(endian_check, ath9k_endian_check, int, 0444);
>>> +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness
>>> compatibility");
>>> #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
>>>   int ath9k_use_chanctx;
>>> @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
>>> ether_addr_copy(common->macaddr, mac);
>>> ah->ah_flags &= ~AH_USE_EEPROM;
>>> -   ah->ah_flags |= AH_NO_EEP_SWAP;
>>> +   if (!ath9k_endian_check)
>>> +   ah->ah_flags |= AH_NO_EEP_SWAP;
>>
>> A bit annoying to have a module parameter, isn't there any automatic
>> way
>> to detect/try this? But on the other hand I guess this isn't a common
>> problem as nobody has reported this before?
>
> There is an automatic way to detect this, but that is disabled by the
> AH_NO_EEP_SWAP flag.

 Ah, I didn't check the code at all.

> The platform initialisation does not set this flag if the endian_check
> member of pdata is set to true, but there is no way to not set this
> when using a device tree. I used a module parameter instead of a
> device tree variable because I don't know of a way to modify the
> device tree my PowerMac boots with.

 Ok, makes sense. A module parameter is not an ideal solution I guess
 it's ok in this case.

>>> Kalle: Are there any changes you want me to make in order to get this
>>> accepted? I didn't see anything for me to resolve, but I may have
>>> missed something.
>>>
>>> I can submit a patch to not set the AH_NO_EEP_SWAP flag by default if
>>> you prefer, as that would fix my problem as well. I am just not sure
>>> that doesn't break things for some platform/device I don't have.
>>
>> I'm not really sure what to do. Basically this is a choise between bad
>> for user experience (the module parameter) or risk of regressions
>> (disable AH_NO_EEP_SWAP by default). As ath9k is used in very exotic
>> hardware I'm starting to lean towards the module parameter approach
>> (your patch) but would like to know what others think, especially Felix
>> (CCed).
>>
>> Full patch here:
>>
>> https://patchwork.kernel.org/patch/10241731/
>
>
> Just another ping. As I understood things, all OpenWRT dts' use
> qca,no-eeprom, and perhaps we could
> move ~AH_USE_EEPROM and |= AH_NO_EEP_SWAP in that if block.
>
> This would solve my problem, as I need to have AH_NO_EEP_SWAP removed from
> flags for my card (which is a
> little endian eeprom/card used on a big endian machine).
>
> Would you like me to prepare a patch for this? Is there anyone who can test
> this on the various OpenWRT
> boards/soc and or other configurations? I don't want to break things for
> other people.
can you please prepare a patch for this?
if you want I can test it on two OpenWrt devices and see if it breaks
anything (please give me a few days to test though)


Regards
Martin

Re: second wifi card enforce CN reg dom

[Steve deRosier]

On Thu, Apr 12, 2018 at 10:25 AM, solsTiCe d'Hiver
 wrote:
> It's the second time that you (Ben and Steve) are implying that I
> might break the law.
>

No implication intended. All I said is regulatory operation is
constrained by laws in various jurisdictions. And how the unit behaves
is likely simply following the rules programmed into it for those
purposes. And, there's nothing we can do to change that.

> But why are you saying that ? I am not gonna repeat myself again.
>

If the radio only works as CN and won't let you change it, it's
probably a CN radio and is hard-coded to do that. And, the
intersection of your FR regulatory domain and the CN is what it is.
Have you plugged it in alone? And if so, can you get it on FR or does
it stay on CN?

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: second wifi card enforce CN reg dom

[Ben Greear]

On 04/12/2018 10:25 AM, solsTiCe d'Hiver wrote:

It's the second time that you (Ben and Steve) are implying that I
might break the law.

But why are you saying that ? I am not gonna repeat myself again.


If you force the NIC to use a different regulatory domain that what it
originally was tested with, then it might generate out-of-spec RF
noise on the newly available channels, and to generate invalid RF noise is
against the law in many places.

*Probably* it would be OK, but you cannot know that for certain
without some specialized RF analyzer equipment and some very detailed
testing.



And for the patch, it is also implied that I am able to write one.


Unfortunately, my opinion is that if you are unable to write one, then
you should not be mucking with the regulatory domain stuff at all.

Thanks,
Ben



2018-04-12 19:11 GMT+02:00 Ben Greear :

On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:


Hi.

I thought I made myself clear.
I leave in France. My system(s) is/are set up to use FR as default
regulatory domain.

But when I plug in that tp-link card, I am restricted to use CN
regulatory domain. Why am I the only one to see this as a problem ?

I know that one can only have one regdom defined on the system. I have
set it up myself. So why is it changed behind my back by some card or
whatever ?
Like I said, I am left with the option, to disable crda, or to use 2
systems, one for each card !

Or may be try Windows when this is not messed up like that ??? Well,
it's not on Windows that I will be able to use monitor mode, anyway.



You can hack the ath9k-htc driver to allow over-riding the regdom
of the NIC, but that requires an out of tree patch and is probably
against the law in your country since the NIC may then not be able to
pass the regulatory requirements.

Thanks,
Ben




Never mind.

2018-04-12 17:52 GMT+02:00 Dan Williams :


On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:


On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
 wrote:


On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:



Hi.

This is beyond my comprehension that you could assert this is a
non issue.




Well. I am just saying that it is by design. There is no way for
the
regulatory code to determine where you and your hardware actually
reside so
instead it takes a conservative approach.



To say it another way: mixing regulatory domains on your host system
should result in a _smaller_ set of channels - ie only those channels
at the intersection of the two.

And another wrinkle to consider - one of the 802.11 amendments (can't
remember which one) actually causes the radio to listen to the



802.11d I believe, from the early 2000s.

Dan


beacons
around it, determine what the local regulatory domain is based on the
beacons it hears, and then lock to that regulatory domain. It's
possible for that information to be propagated up to the card's host
and the regulatory domain then would affect both cards. That's how
it's supposed to work, though I don't factually know Linux does this
in all cases.  Could it be you're somewhere where CN is the local
regulatory domain and the TL-WN722N has this feature?

In any case, as Arend points out, despite the hand-wringing that
regulatory domains cause users trying to do something particular,
between certain rules and regulations and certain manufacturers bad
interpretations and implementations around it, there's little that
can
be done about it. Fact is, your radio must comply to whatever
regulatory domain you are in, otherwise it's breaking the rules. And
people breaking the regulatory rules is part of what's gotten
governments to pass even worse (for us OSS guys) laws that tighten
those rules down further.

You asked who to contact. Its not the LKML - it's your relevant
government body. And certain manufacturers who improperly interpret
said rules because it's easier for them.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/






--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com






--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

It's the second time that you (Ben and Steve) are implying that I
might break the law.

But why are you saying that ? I am not gonna repeat myself again.

And for the patch, it is also implied that I am able to write one.

2018-04-12 19:11 GMT+02:00 Ben Greear :
> On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:
>>
>> Hi.
>>
>> I thought I made myself clear.
>> I leave in France. My system(s) is/are set up to use FR as default
>> regulatory domain.
>>
>> But when I plug in that tp-link card, I am restricted to use CN
>> regulatory domain. Why am I the only one to see this as a problem ?
>>
>> I know that one can only have one regdom defined on the system. I have
>> set it up myself. So why is it changed behind my back by some card or
>> whatever ?
>> Like I said, I am left with the option, to disable crda, or to use 2
>> systems, one for each card !
>>
>> Or may be try Windows when this is not messed up like that ??? Well,
>> it's not on Windows that I will be able to use monitor mode, anyway.
>
>
> You can hack the ath9k-htc driver to allow over-riding the regdom
> of the NIC, but that requires an out of tree patch and is probably
> against the law in your country since the NIC may then not be able to
> pass the regulatory requirements.
>
> Thanks,
> Ben
>
>
>>
>> Never mind.
>>
>> 2018-04-12 17:52 GMT+02:00 Dan Williams :
>>>
>>> On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:

 On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
  wrote:
>
> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>
>>
>> Hi.
>>
>> This is beyond my comprehension that you could assert this is a
>> non issue.
>
>
>
> Well. I am just saying that it is by design. There is no way for
> the
> regulatory code to determine where you and your hardware actually
> reside so
> instead it takes a conservative approach.
>

 To say it another way: mixing regulatory domains on your host system
 should result in a _smaller_ set of channels - ie only those channels
 at the intersection of the two.

 And another wrinkle to consider - one of the 802.11 amendments (can't
 remember which one) actually causes the radio to listen to the
>>>
>>>
>>> 802.11d I believe, from the early 2000s.
>>>
>>> Dan
>>>
 beacons
 around it, determine what the local regulatory domain is based on the
 beacons it hears, and then lock to that regulatory domain. It's
 possible for that information to be propagated up to the card's host
 and the regulatory domain then would affect both cards. That's how
 it's supposed to work, though I don't factually know Linux does this
 in all cases.  Could it be you're somewhere where CN is the local
 regulatory domain and the TL-WN722N has this feature?

 In any case, as Arend points out, despite the hand-wringing that
 regulatory domains cause users trying to do something particular,
 between certain rules and regulations and certain manufacturers bad
 interpretations and implementations around it, there's little that
 can
 be done about it. Fact is, your radio must comply to whatever
 regulatory domain you are in, otherwise it's breaking the rules. And
 people breaking the regulatory rules is part of what's gotten
 governments to pass even worse (for us OSS guys) laws that tighten
 those rules down further.

 You asked who to contact. Its not the LKML - it's your relevant
 government body. And certain manufacturers who improperly interpret
 said rules because it's easier for them.

 - Steve

 --
 Steve deRosier
 Cal-Sierra Consulting LLC
 https://www.cal-sierra.com/
>>
>>
>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>

Re: second wifi card enforce CN reg dom

[Ben Greear]

On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:

Hi.

I thought I made myself clear.
I leave in France. My system(s) is/are set up to use FR as default
regulatory domain.

But when I plug in that tp-link card, I am restricted to use CN
regulatory domain. Why am I the only one to see this as a problem ?

I know that one can only have one regdom defined on the system. I have
set it up myself. So why is it changed behind my back by some card or
whatever ?
Like I said, I am left with the option, to disable crda, or to use 2
systems, one for each card !

Or may be try Windows when this is not messed up like that ??? Well,
it's not on Windows that I will be able to use monitor mode, anyway.


You can hack the ath9k-htc driver to allow over-riding the regdom
of the NIC, but that requires an out of tree patch and is probably
against the law in your country since the NIC may then not be able to
pass the regulatory requirements.

Thanks,
Ben



Never mind.

2018-04-12 17:52 GMT+02:00 Dan Williams :

On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:

On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
 wrote:

On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:


Hi.

This is beyond my comprehension that you could assert this is a
non issue.



Well. I am just saying that it is by design. There is no way for
the
regulatory code to determine where you and your hardware actually
reside so
instead it takes a conservative approach.



To say it another way: mixing regulatory domains on your host system
should result in a _smaller_ set of channels - ie only those channels
at the intersection of the two.

And another wrinkle to consider - one of the 802.11 amendments (can't
remember which one) actually causes the radio to listen to the


802.11d I believe, from the early 2000s.

Dan


beacons
around it, determine what the local regulatory domain is based on the
beacons it hears, and then lock to that regulatory domain. It's
possible for that information to be propagated up to the card's host
and the regulatory domain then would affect both cards. That's how
it's supposed to work, though I don't factually know Linux does this
in all cases.  Could it be you're somewhere where CN is the local
regulatory domain and the TL-WN722N has this feature?

In any case, as Arend points out, despite the hand-wringing that
regulatory domains cause users trying to do something particular,
between certain rules and regulations and certain manufacturers bad
interpretations and implementations around it, there's little that
can
be done about it. Fact is, your radio must comply to whatever
regulatory domain you are in, otherwise it's breaking the rules. And
people breaking the regulatory rules is part of what's gotten
governments to pass even worse (for us OSS guys) laws that tighten
those rules down further.

You asked who to contact. Its not the LKML - it's your relevant
government body. And certain manufacturers who improperly interpret
said rules because it's easier for them.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/





--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

Hi.

I thought I made myself clear.
I leave in France. My system(s) is/are set up to use FR as default
regulatory domain.

But when I plug in that tp-link card, I am restricted to use CN
regulatory domain. Why am I the only one to see this as a problem ?

I know that one can only have one regdom defined on the system. I have
set it up myself. So why is it changed behind my back by some card or
whatever ?
Like I said, I am left with the option, to disable crda, or to use 2
systems, one for each card !

Or may be try Windows when this is not messed up like that ??? Well,
it's not on Windows that I will be able to use monitor mode, anyway.

Never mind.

2018-04-12 17:52 GMT+02:00 Dan Williams :
> On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:
>> On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
>>  wrote:
>> > On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>> > >
>> > > Hi.
>> > >
>> > > This is beyond my comprehension that you could assert this is a
>> > > non issue.
>> >
>> >
>> > Well. I am just saying that it is by design. There is no way for
>> > the
>> > regulatory code to determine where you and your hardware actually
>> > reside so
>> > instead it takes a conservative approach.
>> >
>>
>> To say it another way: mixing regulatory domains on your host system
>> should result in a _smaller_ set of channels - ie only those channels
>> at the intersection of the two.
>>
>> And another wrinkle to consider - one of the 802.11 amendments (can't
>> remember which one) actually causes the radio to listen to the
>
> 802.11d I believe, from the early 2000s.
>
> Dan
>
>> beacons
>> around it, determine what the local regulatory domain is based on the
>> beacons it hears, and then lock to that regulatory domain. It's
>> possible for that information to be propagated up to the card's host
>> and the regulatory domain then would affect both cards. That's how
>> it's supposed to work, though I don't factually know Linux does this
>> in all cases.  Could it be you're somewhere where CN is the local
>> regulatory domain and the TL-WN722N has this feature?
>>
>> In any case, as Arend points out, despite the hand-wringing that
>> regulatory domains cause users trying to do something particular,
>> between certain rules and regulations and certain manufacturers bad
>> interpretations and implementations around it, there's little that
>> can
>> be done about it. Fact is, your radio must comply to whatever
>> regulatory domain you are in, otherwise it's breaking the rules. And
>> people breaking the regulatory rules is part of what's gotten
>> governments to pass even worse (for us OSS guys) laws that tighten
>> those rules down further.
>>
>> You asked who to contact. Its not the LKML - it's your relevant
>> government body. And certain manufacturers who improperly interpret
>> said rules because it's easier for them.
>>
>> - Steve
>>
>> --
>> Steve deRosier
>> Cal-Sierra Consulting LLC
>> https://www.cal-sierra.com/

Re: [PATCH] ANDROID: mac80211_hwsim: support/ignore power state changes

[Roman Kiryanov]

Hi Kalle,

thank you for reviewing our patch. I am ok with applying this patch without
"ANDROID:" prefix. Do you want me to send an updated patch?

Regards,
Roman.

On Wed, Apr 11, 2018 at 9:23 PM Kalle Valo  wrote:

> r...@google.com writes:

> > From: Bjoern Johansson 
> >
> > Indicate support for power state changes and handle them by calling an
> > empty function.
> > The important part is "ieee80211_hw_set(hw, SUPPORTS_PS);" at the
> > bottom of the diff. Without this upper layers in the kernel will return
an
> > error code when trying to set the power state because the driver doesn't
> > indicate power state support. This in turn causes VTS
> > (Android Vendor Test Suite) failures because the WiFi HAL can't enable
> > power saving mode. The remaining code is just there to deal with the
> > incoming state change request.
> >
> > Signed-off-by: Bjoern Johansson 
> > Signed-off-by: Lingfeng Yang 
> > Signed-off-by: Roman Kiryanov 

> Why the odd "ANDROID:" prefix?

> --
> Kalle Valo

[PATCH] NFC: fix attrs checks in netlink interface

[Andrey Konovalov]

nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.

This patch adds appropriate checks.

Found with syzkaller.

Signed-off-by: Andrey Konovalov 
---
 net/nfc/netlink.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index f018eafc2a0d..58adfb0c90f6 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -936,7 +936,8 @@ static int nfc_genl_deactivate_target(struct sk_buff *skb,
u32 device_idx, target_idx;
int rc;
 
-   if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+   if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+   !info->attrs[NFC_ATTR_TARGET_INDEX])
return -EINVAL;
 
device_idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
@@ -1245,7 +1246,8 @@ static int nfc_genl_fw_download(struct sk_buff *skb, 
struct genl_info *info)
u32 idx;
char firmware_name[NFC_FIRMWARE_NAME_MAXSIZE + 1];
 
-   if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+   if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+   !info->attrs[NFC_ATTR_FIRMWARE_NAME])
return -EINVAL;
 
idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
-- 
2.17.0.484.g0c8726318c-goog

Re: second wifi card enforce CN reg dom

[Dan Williams]

On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:
> On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
>  wrote:
> > On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
> > > 
> > > Hi.
> > > 
> > > This is beyond my comprehension that you could assert this is a
> > > non issue.
> > 
> > 
> > Well. I am just saying that it is by design. There is no way for
> > the
> > regulatory code to determine where you and your hardware actually
> > reside so
> > instead it takes a conservative approach.
> > 
> 
> To say it another way: mixing regulatory domains on your host system
> should result in a _smaller_ set of channels - ie only those channels
> at the intersection of the two.
> 
> And another wrinkle to consider - one of the 802.11 amendments (can't
> remember which one) actually causes the radio to listen to the 

802.11d I believe, from the early 2000s.

Dan

> beacons
> around it, determine what the local regulatory domain is based on the
> beacons it hears, and then lock to that regulatory domain. It's
> possible for that information to be propagated up to the card's host
> and the regulatory domain then would affect both cards. That's how
> it's supposed to work, though I don't factually know Linux does this
> in all cases.  Could it be you're somewhere where CN is the local
> regulatory domain and the TL-WN722N has this feature?
> 
> In any case, as Arend points out, despite the hand-wringing that
> regulatory domains cause users trying to do something particular,
> between certain rules and regulations and certain manufacturers bad
> interpretations and implementations around it, there's little that
> can
> be done about it. Fact is, your radio must comply to whatever
> regulatory domain you are in, otherwise it's breaking the rules. And
> people breaking the regulatory rules is part of what's gotten
> governments to pass even worse (for us OSS guys) laws that tighten
> those rules down further.
> 
> You asked who to contact. Its not the LKML - it's your relevant
> government body. And certain manufacturers who improperly interpret
> said rules because it's easier for them.
> 
> - Steve
> 
> --
> Steve deRosier
> Cal-Sierra Consulting LLC
> https://www.cal-sierra.com/

[PATCH] ath6kl: use WMI to set RSN capabilities

[Alfonso Sánchez-Beato]

This fixes AP mode when the ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE flag
is not present in the FW. The id of some WMI commands is also fixed
(there was an error in the enum order), and a function to set RSN caps
is added.

Signed-off-by: Alfonso Sánchez-Beato 
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 21 ++---
 drivers/net/wireless/ath/ath6kl/main.c | 10 +++---
 drivers/net/wireless/ath/ath6kl/wmi.c  | 23 +++
 drivers/net/wireless/ath/ath6kl/wmi.h  | 15 +++
 4 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 2ba8cf3f38af..1b89c53d47e7 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -2933,13 +2933,11 @@ static int ath6kl_start_ap(struct wiphy *wiphy, struct 
net_device *dev,
 * advertise the same in beacon/probe response. Send
 * the complete RSN IE capability field to firmware
 */
-   if (!ath6kl_get_rsn_capab(>beacon, (u8 *) _capab) &&
-   test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
-ar->fw_capabilities)) {
-   res = ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
-   WLAN_EID_RSN, WMI_RSN_IE_CAPB,
-   (const u8 *) _capab,
-   sizeof(rsn_capab));
+   if (!ath6kl_get_rsn_capab(>beacon, (u8 *)_capab)) {
+   ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "RSN caps %d\n", rsn_capab);
+
+   res = ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
+rsn_capab);
vif->rsn_capab = rsn_capab;
if (res < 0)
return res;
@@ -3918,14 +3916,7 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
return -EINVAL;
}
 
-   /*
-* Even if the fw has HT support, advertise HT cap only when
-* the firmware has support to override RSN capability, otherwise
-* 4-way handshake would fail.
-*/
-   if (!(ht &&
- test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
-  ar->fw_capabilities))) {
+   if (!ht) {
ath6kl_band_2ghz.ht_cap.cap = 0;
ath6kl_band_2ghz.ht_cap.ht_supported = false;
ath6kl_band_5ghz.ht_cap.cap = 0;
diff --git a/drivers/net/wireless/ath/ath6kl/main.c 
b/drivers/net/wireless/ath/ath6kl/main.c
index db95f85751e3..4e186f8b3950 100644
--- a/drivers/net/wireless/ath/ath6kl/main.c
+++ b/drivers/net/wireless/ath/ath6kl/main.c
@@ -579,13 +579,9 @@ static int ath6kl_commit_ch_switch(struct ath6kl_vif *vif, 
u16 channel)
 * reconfigure any saved RSN IE capabilites in the beacon /
 * probe response to stay in sync with the supplicant.
 */
-   if (vif->rsn_capab &&
-   test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
-ar->fw_capabilities))
-   ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
- WLAN_EID_RSN, WMI_RSN_IE_CAPB,
- (const u8 *) >rsn_capab,
- sizeof(vif->rsn_capab));
+   if (vif->rsn_capab)
+   ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
+  vif->rsn_capab);
 
return ath6kl_wmi_ap_profile_commit(ar->wmi, vif->fw_vif_idx,
>profile);
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index 777acc564ac9..d7de9224d755 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -4168,3 +4168,26 @@ void ath6kl_wmi_shutdown(struct wmi *wmi)
kfree(wmi->last_mgmt_tx_frame);
kfree(wmi);
 }
+
+int ath6kl_wmi_set_rsn_cap(struct wmi *wmi, u8 if_idx, u16 rsn_cap)
+{
+   struct sk_buff *skb;
+   struct wmi_rsn_cap_cmd *cmd;
+
+   skb = ath6kl_wmi_get_new_buf(sizeof(*cmd));
+   if (!skb)
+   return -ENOMEM;
+
+   ath6kl_dbg(ATH6KL_DBG_WMI, "set_rsn_cap: 0x%04x\n", rsn_cap);
+
+   cmd = (struct wmi_rsn_cap_cmd *)skb->data;
+   cmd->rsn_cap = cpu_to_le16(rsn_cap);
+
+   return ath6kl_wmi_cmd_send(wmi, if_idx, skb, WMI_SET_RSN_CAP_CMDID,
+  NO_SYNC_WMIFLAG);
+}
+
+int ath6kl_wmi_get_rsn_cap(struct wmi *wmi, u8 if_idx)
+{
+   return ath6kl_wmi_simple_cmd(wmi, if_idx, WMI_GET_RSN_CAP_CMDID);
+}
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.h 
b/drivers/net/wireless/ath/ath6kl/wmi.h
index a60bb49fe920..011d4b6fb5ab 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.h
+++ 

Re: second wifi card enforce CN reg dom

[Steve deRosier]

On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
 wrote:
> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>
>> Hi.
>>
>> This is beyond my comprehension that you could assert this is a non issue.
>
>
> Well. I am just saying that it is by design. There is no way for the
> regulatory code to determine where you and your hardware actually reside so
> instead it takes a conservative approach.
>

To say it another way: mixing regulatory domains on your host system
should result in a _smaller_ set of channels - ie only those channels
at the intersection of the two.

And another wrinkle to consider - one of the 802.11 amendments (can't
remember which one) actually causes the radio to listen to the beacons
around it, determine what the local regulatory domain is based on the
beacons it hears, and then lock to that regulatory domain. It's
possible for that information to be propagated up to the card's host
and the regulatory domain then would affect both cards. That's how
it's supposed to work, though I don't factually know Linux does this
in all cases.  Could it be you're somewhere where CN is the local
regulatory domain and the TL-WN722N has this feature?

In any case, as Arend points out, despite the hand-wringing that
regulatory domains cause users trying to do something particular,
between certain rules and regulations and certain manufacturers bad
interpretations and implementations around it, there's little that can
be done about it. Fact is, your radio must comply to whatever
regulatory domain you are in, otherwise it's breaking the rules. And
people breaking the regulatory rules is part of what's gotten
governments to pass even worse (for us OSS guys) laws that tighten
those rules down further.

You asked who to contact. Its not the LKML - it's your relevant
government body. And certain manufacturers who improperly interpret
said rules because it's easier for them.

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: [PATCH 1/1 RFC] wcn36xx: fix buffer commit logic on TX path

[Loic Poulain]

On 11 April 2018 at 15:37, Daniel Mack  wrote:
> Hi Loic,
>
> On Wednesday, April 11, 2018 03:30 PM, Loic Poulain wrote:
>>> /* Move the head of the ring to the next empty descriptor */
>>> -ch->head_blk_ctl = ctl->next;
>>> +ch->head_blk_ctl = ctl_skb->next;
>>> +
>>> +   /* Commit all previous writes and set descriptors to VALID */
>>> +   wmb();
>>
>> Is this first memory barrier really needed? from what I understand, we
>> only need to ensure that the control descriptor is marked valid at the
>> end of the procedure and we don't really care about the paylod one.
>
> Well, without documentation or the firmware sources, that's just
> guesswork at this point. My assumption is only based on the weird
> comments and workarounds in the downstream driver.
>
> I added the second barrier to ensure that no descriptor is ever marked
> valid unless all other bits are definitely in sync.

Fair enough!

Re: [PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Kalle Valo]

Daniel Mack  writes:

>>> Yeah, sorry. I did that intentionally, but missed to mention it in the
>>> commit log.
>> 
>> I can add that to the commit log, just tell me what to add.
>
> I'll resend, hang on :)

Even better, thanks.

-- 
Kalle Valo

[PATCH v2] wcn36xx: pass correct BSS index when deleting BSS keys

[Daniel Mack]

The firmware message to delete BSS keys expects a BSS index to be passed.
This field is currently hard-coded to 0. Fix this by passing in the index
we received from the firmware when the BSS was configured.

The encryption type in that message also needs to be set to what was used
when the key was set, so the assignment of vif_priv->encrypt_type is now
done after the firmware command was sent. This reportedly fixes the
following error in AP mode:

  wcn36xx: ERROR hal_remove_bsskey response failed err=6

Also, AFAIU, when a BSS is deleted, the firmware apparently drops all the
keys associated with it. Trying to remove the key explicitly afterwards
will hence lead to the following message:

  wcn36xx: ERROR hal_remove_bsskey response failed err=16

This is now suppressed with an extra check for the BSS index validity.

Signed-off-by: Daniel Mack 
---
v2: mention the vif_priv->encrypt_type move in the commit log.

 drivers/net/wireless/ath/wcn36xx/main.c | 10 +++---
 drivers/net/wireless/ath/wcn36xx/smd.c  |  6 --
 drivers/net/wireless/ath/wcn36xx/smd.h  |  2 ++
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 0bc9283e7d8d..1b17c35a7944 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -547,6 +547,7 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
} else {
wcn36xx_smd_set_bsskey(wcn,
vif_priv->encrypt_type,
+   vif_priv->bss_index,
key_conf->keyidx,
key_conf->keylen,
key);
@@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
break;
case DISABLE_KEY:
if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
+   if (vif_priv->bss_index != WCN36XX_HAL_BSS_INVALID_IDX)
+   wcn36xx_smd_remove_bsskey(wcn,
+   vif_priv->encrypt_type,
+   vif_priv->bss_index,
+   key_conf->keyidx);
+
vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
-   wcn36xx_smd_remove_bsskey(wcn,
-   vif_priv->encrypt_type,
-   key_conf->keyidx);
} else {
sta_priv->is_data_encrypted = false;
/* do not remove key if disassociated */
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9827a1e1124b..297a785d0785 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -1636,6 +1636,7 @@ int wcn36xx_smd_set_stakey(struct wcn36xx *wcn,
 
 int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
   enum ani_ed_type enc_type,
+  u8 bssidx,
   u8 keyidx,
   u8 keylen,
   u8 *key)
@@ -1645,7 +1646,7 @@ int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
 
mutex_lock(>hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_SET_BSSKEY_REQ);
-   msg_body.bss_idx = 0;
+   msg_body.bss_idx = bssidx;
msg_body.enc_type = enc_type;
msg_body.num_keys = 1;
msg_body.keys[0].id = keyidx;
@@ -1706,6 +1707,7 @@ int wcn36xx_smd_remove_stakey(struct wcn36xx *wcn,
 
 int wcn36xx_smd_remove_bsskey(struct wcn36xx *wcn,
  enum ani_ed_type enc_type,
+ u8 bssidx,
  u8 keyidx)
 {
struct wcn36xx_hal_remove_bss_key_req_msg msg_body;
@@ -1713,7 +1715,7 @@ int wcn36xx_smd_remove_bsskey(struct wcn36xx *wcn,
 
mutex_lock(>hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_RMV_BSSKEY_REQ);
-   msg_body.bss_idx = 0;
+   msg_body.bss_idx = bssidx;
msg_body.enc_type = enc_type;
msg_body.key_id = keyidx;
 
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h 
b/drivers/net/wireless/ath/wcn36xx/smd.h
index 8076edf40ac8..61bb8d43138c 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -97,6 +97,7 @@ int wcn36xx_smd_set_stakey(struct wcn36xx *wcn,
   u8 sta_index);
 int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
   enum ani_ed_type enc_type,
+  u8 bssidx,
   u8 keyidx,
   u8 keylen,
   u8 *key);
@@ -106,6 +107,7 @@ int wcn36xx_smd_remove_stakey(struct wcn36xx *wcn,
  u8 sta_index);
 int wcn36xx_smd_remove_bsskey(struct 

[PATCH] ath10k: correct target assert problem due to CE5 stuck

[mpubbise]

From: Manikanta Pubbisetty 

Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix
copy engine 5 destination ring stuck") which introduced a change to fix
firmware assert that happens when ring indices of copy engine 5 are stuck
for a specific duration, problem with this fix is that it did not use
ring arithmatic. As a result,firmware asserts did not go away entirely
athough the frequency of occurrence has reduced. Using ring arithmatic
to fix the issue.

Tested on QCA9984(fw version-10.4-3.4-00082).

Fixes: 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck)
Signed-off-by: Manikanta Pubbisetty 
---
 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index b9def7b..6efa69e 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -615,7 +615,7 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe 
*pipe, u32 nentries)
/* Prevent CE ring stuck issue that will occur when ring is full.
 * Make sure that write index is 1 less than read index.
 */
-   if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+   if (((cur_write_idx + nentries) & nentries_mask) == dest_ring->sw_index)
nentries -= 1;
 
write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
-- 
2.7.4

Re: [PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Daniel Mack]

On Thursday, April 12, 2018 02:14 PM, Kalle Valo wrote:
> Daniel Mack  writes:
> 
>> On Thursday, April 12, 2018 01:46 PM, Loic Poulain wrote:
>>> Hi Daniel,
>>>
 @@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, 
 enum set_key_cmd cmd,
 break;
 case DISABLE_KEY:
 if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
 +   if (vif_priv->bss_index != 
 WCN36XX_HAL_BSS_INVALID_IDX)
 +   wcn36xx_smd_remove_bsskey(wcn,
 +   vif_priv->encrypt_type,
 +   vif_priv->bss_index,
 +   key_conf->keyidx);
 +
 vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
 -   wcn36xx_smd_remove_bsskey(wcn,
 -   vif_priv->encrypt_type,
 -   key_conf->keyidx);
>>>
>>> Note that moving vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE after
>>> key removal also fixes an issue I observed in AP mode:
>>> wcn36xx: ERROR hal_remove_bsskey response failed err=6
>>
>> Yeah, sorry. I did that intentionally, but missed to mention it in the
>> commit log.
> 
> I can add that to the commit log, just tell me what to add.

I'll resend, hang on :)

Daniel

[PATCH] ath10k: correct target assert problem due to CE5 stuck

[mpubbise]

From: Manikanta Pubbisetty 

Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix
copy engine 5 destination ring stuck") which introduced a change to fix
firmware assert that happens when ring indices of copy engine 5 are stuck
for a specific duration, problem with this fix is that it did not use
ring arithmatic. As a result,firmware asserts did not go away entirely
athough the frequency of occurrence has reduced. Using ring arithmatic
to fix the issue.

Tested on QCA9984(fw version-10.4-3.4-00082).

Fixes: 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck)
Signed-off-by: Manikanta Pubbisetty 
---
 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index b9def7b..6efa69e 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -615,7 +615,7 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe 
*pipe, u32 nentries)
/* Prevent CE ring stuck issue that will occur when ring is full.
 * Make sure that write index is 1 less than read index.
 */
-   if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+   if (((cur_write_idx + nentries) & nentries_mask) == dest_ring->sw_index)
nentries -= 1;
 
write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
-- 
2.7.4

Re: [PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Kalle Valo]

Daniel Mack  writes:

> On Thursday, April 12, 2018 01:46 PM, Loic Poulain wrote:
>> Hi Daniel,
>> 
>>> @@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, 
>>> enum set_key_cmd cmd,
>>> break;
>>> case DISABLE_KEY:
>>> if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
>>> +   if (vif_priv->bss_index != 
>>> WCN36XX_HAL_BSS_INVALID_IDX)
>>> +   wcn36xx_smd_remove_bsskey(wcn,
>>> +   vif_priv->encrypt_type,
>>> +   vif_priv->bss_index,
>>> +   key_conf->keyidx);
>>> +
>>> vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
>>> -   wcn36xx_smd_remove_bsskey(wcn,
>>> -   vif_priv->encrypt_type,
>>> -   key_conf->keyidx);
>> 
>> Note that moving vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE after
>> key removal also fixes an issue I observed in AP mode:
>> wcn36xx: ERROR hal_remove_bsskey response failed err=6
>
> Yeah, sorry. I did that intentionally, but missed to mention it in the
> commit log.

I can add that to the commit log, just tell me what to add.

-- 
Kalle Valo

Re: [PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Daniel Mack]

On Thursday, April 12, 2018 01:46 PM, Loic Poulain wrote:
> Hi Daniel,
> 
>> @@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, 
>> enum set_key_cmd cmd,
>> break;
>> case DISABLE_KEY:
>> if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
>> +   if (vif_priv->bss_index != 
>> WCN36XX_HAL_BSS_INVALID_IDX)
>> +   wcn36xx_smd_remove_bsskey(wcn,
>> +   vif_priv->encrypt_type,
>> +   vif_priv->bss_index,
>> +   key_conf->keyidx);
>> +
>> vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
>> -   wcn36xx_smd_remove_bsskey(wcn,
>> -   vif_priv->encrypt_type,
>> -   key_conf->keyidx);
> 
> Note that moving vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE after
> key removal also fixes an issue I observed in AP mode:
> wcn36xx: ERROR hal_remove_bsskey response failed err=6

Yeah, sorry. I did that intentionally, but missed to mention it in the
commit log.


Thanks,
Daniel

Re: [PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Loic Poulain]

Hi Daniel,

> @@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, 
> enum set_key_cmd cmd,
> break;
> case DISABLE_KEY:
> if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
> +   if (vif_priv->bss_index != 
> WCN36XX_HAL_BSS_INVALID_IDX)
> +   wcn36xx_smd_remove_bsskey(wcn,
> +   vif_priv->encrypt_type,
> +   vif_priv->bss_index,
> +   key_conf->keyidx);
> +
> vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
> -   wcn36xx_smd_remove_bsskey(wcn,
> -   vif_priv->encrypt_type,
> -   key_conf->keyidx);

Note that moving vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE after
key removal also fixes an issue I observed in AP mode:
wcn36xx: ERROR hal_remove_bsskey response failed err=6

Indeed, trying to remove a key with non-matching encrypt type fails,
keeping the right encrypt_type for removal fixes the issue.

Patch looks good.

Regards,
Loic

[PATCH] wcn36xx: pass correct BSS index when deleting BSS keys

[Daniel Mack]

The firmware message to delete BSS keys expects a BSS index to be passed.
This field is currently hard-coded to 0. Fix this by passing in the index
we received from the firmware when the BSS was configured.

Also, AFAIU, when a BSS is deleted, the firmware apparently drops all the
keys associated with it. Trying to remove the key explicitly afterwards
will hence lead to the following message:

  wcn36xx: ERROR hal_remove_bsskey response failed err=16

This is now suppressed with an extra check for the BSS index validity.

Signed-off-by: Daniel Mack 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 10 +++---
 drivers/net/wireless/ath/wcn36xx/smd.c  |  6 --
 drivers/net/wireless/ath/wcn36xx/smd.h  |  2 ++
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 0bc9283e7d8d..1b17c35a7944 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -547,6 +547,7 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
} else {
wcn36xx_smd_set_bsskey(wcn,
vif_priv->encrypt_type,
+   vif_priv->bss_index,
key_conf->keyidx,
key_conf->keylen,
key);
@@ -564,10 +565,13 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
break;
case DISABLE_KEY:
if (!(IEEE80211_KEY_FLAG_PAIRWISE & key_conf->flags)) {
+   if (vif_priv->bss_index != WCN36XX_HAL_BSS_INVALID_IDX)
+   wcn36xx_smd_remove_bsskey(wcn,
+   vif_priv->encrypt_type,
+   vif_priv->bss_index,
+   key_conf->keyidx);
+
vif_priv->encrypt_type = WCN36XX_HAL_ED_NONE;
-   wcn36xx_smd_remove_bsskey(wcn,
-   vif_priv->encrypt_type,
-   key_conf->keyidx);
} else {
sta_priv->is_data_encrypted = false;
/* do not remove key if disassociated */
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9827a1e1124b..297a785d0785 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -1636,6 +1636,7 @@ int wcn36xx_smd_set_stakey(struct wcn36xx *wcn,
 
 int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
   enum ani_ed_type enc_type,
+  u8 bssidx,
   u8 keyidx,
   u8 keylen,
   u8 *key)
@@ -1645,7 +1646,7 @@ int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
 
mutex_lock(>hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_SET_BSSKEY_REQ);
-   msg_body.bss_idx = 0;
+   msg_body.bss_idx = bssidx;
msg_body.enc_type = enc_type;
msg_body.num_keys = 1;
msg_body.keys[0].id = keyidx;
@@ -1706,6 +1707,7 @@ int wcn36xx_smd_remove_stakey(struct wcn36xx *wcn,
 
 int wcn36xx_smd_remove_bsskey(struct wcn36xx *wcn,
  enum ani_ed_type enc_type,
+ u8 bssidx,
  u8 keyidx)
 {
struct wcn36xx_hal_remove_bss_key_req_msg msg_body;
@@ -1713,7 +1715,7 @@ int wcn36xx_smd_remove_bsskey(struct wcn36xx *wcn,
 
mutex_lock(>hal_mutex);
INIT_HAL_MSG(msg_body, WCN36XX_HAL_RMV_BSSKEY_REQ);
-   msg_body.bss_idx = 0;
+   msg_body.bss_idx = bssidx;
msg_body.enc_type = enc_type;
msg_body.key_id = keyidx;
 
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h 
b/drivers/net/wireless/ath/wcn36xx/smd.h
index 8076edf40ac8..61bb8d43138c 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -97,6 +97,7 @@ int wcn36xx_smd_set_stakey(struct wcn36xx *wcn,
   u8 sta_index);
 int wcn36xx_smd_set_bsskey(struct wcn36xx *wcn,
   enum ani_ed_type enc_type,
+  u8 bssidx,
   u8 keyidx,
   u8 keylen,
   u8 *key);
@@ -106,6 +107,7 @@ int wcn36xx_smd_remove_stakey(struct wcn36xx *wcn,
  u8 sta_index);
 int wcn36xx_smd_remove_bsskey(struct wcn36xx *wcn,
  enum ani_ed_type enc_type,
+ u8 bssidx,
  u8 keyidx);
 int wcn36xx_smd_enter_bmps(struct wcn36xx *wcn, struct ieee80211_vif *vif);
 int wcn36xx_smd_exit_bmps(struct wcn36xx *wcn, struct ieee80211_vif *vif);
-- 
2.14.3

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:

Hi.

This is beyond my comprehension that you could assert this is a non issue.


Well. I am just saying that it is by design. There is no way for the 
regulatory code to determine where you and your hardware actually reside 
so instead it takes a conservative approach.


btw. can you change the global reg back to FR using iw reg set?

Regards,
Arend


If this is a hint, then someone should take this as a hint , and not
enforce it blindly.

I loose the capability to use a lot of channels on a card because of
the mis-behaving of another. Or the crda framework, or whatever.

What is even more stupid is that the TL-W722N is a 2.4GHz only band
and that breaks operation on the 5GHz band of the other card.

I am not even speaking about the fact that I use this in monitor mode,
hence I will never emit anything. But anyway... crda has already
broken everyhting even before I am entering monitor mode for the
cards.

Well, non issue... sight

2018-04-12 9:48 GMT+02:00 Arend van Spriel :

On 4/12/2018 9:00 AM, solsTiCe d'Hiver wrote:


Nobody cares about this ?

Should I report this as a bug to the LKML ? or elsewhere ? to
ath9k_htc dev ? to crda dev ?

Please.



Hi,

I do not think nobody cares, but what you describe is actually no issue as
far as I can determine. Wifi cards are typically programmed with some
country code and both provide that as a regulatory hint to the regulatory
framework, which adapts to a regulatory domain in which only channels and
power limits are set that are allowed for both devices. That is why some of
the rules in the global set #98 are matching the FR set and some rules match
the CN set. And because FR uses ETSI DFS and CN uses FCC DFS you are loosing
all channels that require DFS.

Regards,
Arend




2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver :


hi.

I am trying to capture on 2 channels at the same time with 2 cards.

One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
an Alfa AWUS051NH v2 using rt2800usb.

I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
reproduced the issue on a netbook using archlinux x64 too using latest
kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
too)

So when the Alfa card is used alone using the default reg dom FR, one
can change to 112 channel for example (using iw dev wlan1 set channel
112)

But once the tp-link is plugged in, reg dom seems to become CN and one
can't change the alfa card to 112 channel.

iw reg get output change from
global
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
to
global
country 98: DFS-UNSET
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 40), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)

phy#2
country CN: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 44), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)


and all the channels above 100 are marked as disabled in iw list
output (after the plug not before) for the alfa card

It is as if the TL-WN722N has CN reg dom hard-coded and that switches
it globally to CN too ???

Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??

[PATCH] staging: wilc1000: fix NULL pointer exception in host_int_parse_assoc_resp_info()

[Ajay Singh]

Commit fe014d4e6b55 (staging: wilc1000: free memory allocated for general info
message from firmware) introduced a bug by using wrong source address in
kmemdup(). 'conn_info.req_ies' is used for source address in kempdup()
instead of 'hif_drv->usr_conn_req.ies'.

This commit fixes the NULL pointer dereference issue in
host_int_parse_assoc_resp_info() by using the correct source address in
kmemdup().

Fixes: fe014d4e6b55 (staging: wilc1000: free memory allocated for
general info message from firmware)
Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 316d73c..302e3cb 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1387,7 +1387,7 @@ static inline void host_int_parse_assoc_resp_info(struct 
wilc_vif *vif,
}
 
if (hif_drv->usr_conn_req.ies) {
-   conn_info.req_ies = kmemdup(conn_info.req_ies,
+   conn_info.req_ies = kmemdup(hif_drv->usr_conn_req.ies,
hif_drv->usr_conn_req.ies_len,
GFP_KERNEL);
if (conn_info.req_ies)
-- 
2.7.4

Re: [PATCH v2] staging: wilc1000: Remove unnecessary braces {} around single statement block

[Claudiu Beznea]

On 12.04.2018 10:59, Eyal Ilsar wrote:
> Remove unnecessary braces {} around an 'if' statement block with a single 
> statement. Issue found by checkpatch.
> 
> Signed-off-by: Eyal Ilsar 

Reviewed-by: Claudiu Beznea 

> ---
> Added an empty line before the 'Signed-off-by' line and a space between the
> name and e-mail address within that line.
> 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 205304c..325afe1 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -284,9 +284,8 @@ static void remove_network_from_shadow(struct timer_list 
> *unused)
>   }
>   }
>  
> - if (last_scanned_cnt != 0) {
> + if (last_scanned_cnt != 0)
>   mod_timer(, jiffies + msecs_to_jiffies(AGING_TIME));
> - }
>  }
>  
>  static void clear_duringIP(struct timer_list *unused)
> 

[PATCH 04/10] wil6210: fix call to wil6210_disconnect during unload

[Maya Erez]

From: Lior David 

Move the call to wil6210_disconnect so it will be called
before unregister_netdevice. This is because it calls
netif_carrier_off which is forbidden to call on an
unregistered net device. Calling netif_carrier_off can
add a link watch event which might be handled after
net device was freed, causing a kernel oops.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/netdev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/netdev.c 
b/drivers/net/wireless/ath/wil6210/netdev.c
index 05e9408..eb6c14ed 100644
--- a/drivers/net/wireless/ath/wil6210/netdev.c
+++ b/drivers/net/wireless/ath/wil6210/netdev.c
@@ -457,16 +457,16 @@ void wil_vif_remove(struct wil6210_priv *wil, u8 mid)
return;
}
 
+   mutex_lock(>mutex);
+   wil6210_disconnect(vif, NULL, WLAN_REASON_DEAUTH_LEAVING, false);
+   mutex_unlock(>mutex);
+
ndev = vif_to_ndev(vif);
/* during unregister_netdevice cfg80211_leave may perform operations
 * such as stop AP, disconnect, so we only clear the VIF afterwards
 */
unregister_netdevice(ndev);
 
-   mutex_lock(>mutex);
-   wil6210_disconnect(vif, NULL, WLAN_REASON_DEAUTH_LEAVING, false);
-   mutex_unlock(>mutex);
-
if (any_active && vif->mid != 0)
wmi_port_delete(wil, vif->mid);
 
-- 
1.9.1

[PATCH 02/10] wil6210: set/get EDMG channel through debugfs

[Maya Erez]

From: Alexei Avshalom Lazar 

Setting EDMG channel through debugfs for connect and PCP start
commands.

Signed-off-by: Alexei Avshalom Lazar 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 89 +
 drivers/net/wireless/ath/wil6210/debugfs.c  |  1 +
 drivers/net/wireless/ath/wil6210/wil6210.h  |  4 ++
 drivers/net/wireless/ath/wil6210/wmi.c  | 25 +++-
 drivers/net/wireless/ath/wil6210/wmi.h  | 33 ++-
 5 files changed, 146 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index cdbb393..c2da159 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -261,6 +261,86 @@ int wil_iftype_nl2wmi(enum nl80211_iftype type)
return -EOPNOTSUPP;
 }
 
+int wil_spec2wmi_ch(u8 spec_ch, u8 *wmi_ch)
+{
+   switch (spec_ch) {
+   case 1:
+   *wmi_ch = WMI_CHANNEL_1;
+   break;
+   case 2:
+   *wmi_ch = WMI_CHANNEL_2;
+   break;
+   case 3:
+   *wmi_ch = WMI_CHANNEL_3;
+   break;
+   case 4:
+   *wmi_ch = WMI_CHANNEL_4;
+   break;
+   case 5:
+   *wmi_ch = WMI_CHANNEL_5;
+   break;
+   case 6:
+   *wmi_ch = WMI_CHANNEL_6;
+   break;
+   case 9:
+   *wmi_ch = WMI_CHANNEL_9;
+   break;
+   case 10:
+   *wmi_ch = WMI_CHANNEL_10;
+   break;
+   case 11:
+   *wmi_ch = WMI_CHANNEL_11;
+   break;
+   case 12:
+   *wmi_ch = WMI_CHANNEL_12;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch)
+{
+   switch (wmi_ch) {
+   case WMI_CHANNEL_1:
+   *spec_ch = 1;
+   break;
+   case WMI_CHANNEL_2:
+   *spec_ch = 2;
+   break;
+   case WMI_CHANNEL_3:
+   *spec_ch = 3;
+   break;
+   case WMI_CHANNEL_4:
+   *spec_ch = 4;
+   break;
+   case WMI_CHANNEL_5:
+   *spec_ch = 5;
+   break;
+   case WMI_CHANNEL_6:
+   *spec_ch = 6;
+   break;
+   case WMI_CHANNEL_9:
+   *spec_ch = 9;
+   break;
+   case WMI_CHANNEL_10:
+   *spec_ch = 10;
+   break;
+   case WMI_CHANNEL_11:
+   *spec_ch = 11;
+   break;
+   case WMI_CHANNEL_12:
+   *spec_ch = 12;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
   struct station_info *sinfo)
 {
@@ -1005,6 +1085,15 @@ static int wil_cfg80211_connect(struct wiphy *wiphy,
}
conn.channel = ch - 1;
 
+   if (test_bit(WMI_FW_CAPABILITY_CHANNEL_BONDING, wil->fw_capabilities))
+   if (wil->force_edmg_channel) {
+   rc = wil_spec2wmi_ch(wil->force_edmg_channel,
+_channel);
+   if (rc)
+   wil_err(wil, "wmi channel for channel %d not 
found",
+   wil->force_edmg_channel);
+   }
+
ether_addr_copy(conn.bssid, bss->bssid);
ether_addr_copy(conn.dst_mac, bss->bssid);
 
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 8c90b31..10ffa4d 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1852,6 +1852,7 @@ static void wil6210_debugfs_init_isr(struct wil6210_priv 
*wil,
WIL_FIELD(abft_len, 0644,   doff_u8),
WIL_FIELD(wakeup_trigger, 0644, doff_u8),
WIL_FIELD(vring_idle_trsh, 0644,doff_u32),
+   WIL_FIELD(force_edmg_channel, 0644, doff_u8),
{},
 };
 
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index f9c5155..c765ff2 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -791,6 +791,7 @@ struct wil6210_priv {
u8 wakeup_trigger;
struct wil_suspend_stats suspend_stats;
struct wil_debugfs_data dbg_data;
+   u8 force_edmg_channel;
 
void *platform_handle;
struct wil_platform_ops platform_ops;
@@ -1151,4 +1152,7 @@ int wmi_start_sched_scan(struct wil6210_priv *wil,
 struct cfg80211_sched_scan_request *request);
 int wmi_stop_sched_scan(struct wil6210_priv *wil);
 
+int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch);
+int 

[PATCH 05/10] wil6210: change reply_size arg to u16 in wmi_call

[Maya Erez]

From: Lior David 

Change the type of the argument reply_size from u8 to
u16 in order to support reply sizes > 255 bytes.
The driver already supports u16 reply size in all
other places, this was the only missing change.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/wil6210.h | 2 +-
 drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index c765ff2..c81fe1d 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -987,7 +987,7 @@ int wmi_read_hdr(struct wil6210_priv *wil, __le32 ptr,
 int wmi_send(struct wil6210_priv *wil, u16 cmdid, u8 mid, void *buf, u16 len);
 void wmi_recv_cmd(struct wil6210_priv *wil);
 int wmi_call(struct wil6210_priv *wil, u16 cmdid, u8 mid, void *buf, u16 len,
-u16 reply_id, void *reply, u8 reply_size, int to_msec);
+u16 reply_id, void *reply, u16 reply_size, int to_msec);
 void wmi_event_worker(struct work_struct *work);
 void wmi_event_flush(struct wil6210_priv *wil);
 int wmi_set_ssid(struct wil6210_vif *vif, u8 ssid_len, const void *ssid);
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index 9f2c21b..cdaf80d 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -1426,7 +1426,7 @@ void wmi_recv_cmd(struct wil6210_priv *wil)
 }
 
 int wmi_call(struct wil6210_priv *wil, u16 cmdid, u8 mid, void *buf, u16 len,
-u16 reply_id, void *reply, u8 reply_size, int to_msec)
+u16 reply_id, void *reply, u16 reply_size, int to_msec)
 {
int rc;
unsigned long remain;
-- 
1.9.1

[PATCH 09/10] wil6210: remove unused rx_reorder members

[Maya Erez]

From: Dedy Lansky 

Remove unused members from struct wil_tid_ampdu_rx

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/debugfs.c|  3 +--
 drivers/net/wireless/ath/wil6210/rx_reorder.c |  7 +--
 drivers/net/wireless/ath/wil6210/wil6210.h| 10 --
 3 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 49d9808..aff819b 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1379,8 +1379,7 @@ static void wil_print_rxtid(struct seq_file *s, struct 
wil_tid_ampdu_rx *r)
u16 index = ((r->head_seq_num - r->ssn) & 0xfff) % r->buf_size;
unsigned long long drop_dup = r->drop_dup, drop_old = r->drop_old;
 
-   seq_printf(s, "([%2d] %3d TU) 0x%03x [", r->buf_size, r->timeout,
-  r->head_seq_num);
+   seq_printf(s, "([%2d]) 0x%03x [", r->buf_size, r->head_seq_num);
for (i = 0; i < r->buf_size; i++) {
if (i == index)
seq_printf(s, "%c", r->reorder_buf[i] ? 'O' : '|');
diff --git a/drivers/net/wireless/ath/wil6210/rx_reorder.c 
b/drivers/net/wireless/ath/wil6210/rx_reorder.c
index 14dcb06..76f8084 100644
--- a/drivers/net/wireless/ath/wil6210/rx_reorder.c
+++ b/drivers/net/wireless/ath/wil6210/rx_reorder.c
@@ -206,7 +206,6 @@ void wil_rx_reorder(struct wil6210_priv *wil, struct 
sk_buff *skb)
 
/* put the frame in the reordering buffer */
r->reorder_buf[index] = skb;
-   r->reorder_time[index] = jiffies;
r->stored_mpdu_num++;
wil_reorder_release(ndev, r);
 
@@ -252,11 +251,8 @@ struct wil_tid_ampdu_rx *wil_tid_ampdu_rx_alloc(struct 
wil6210_priv *wil,
 
r->reorder_buf =
kcalloc(size, sizeof(struct sk_buff *), GFP_KERNEL);
-   r->reorder_time =
-   kcalloc(size, sizeof(unsigned long), GFP_KERNEL);
-   if (!r->reorder_buf || !r->reorder_time) {
+   if (!r->reorder_buf) {
kfree(r->reorder_buf);
-   kfree(r->reorder_time);
kfree(r);
return NULL;
}
@@ -286,7 +282,6 @@ void wil_tid_ampdu_rx_free(struct wil6210_priv *wil,
kfree_skb(r->reorder_buf[i]);
 
kfree(r->reorder_buf);
-   kfree(r->reorder_time);
kfree(r);
 }
 
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 2f77319..fe58169 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -493,38 +493,28 @@ enum { /* for wil6210_priv.status */
  * struct tid_ampdu_rx - TID aggregation information (Rx).
  *
  * @reorder_buf: buffer to reorder incoming aggregated MPDUs
- * @reorder_time: jiffies when skb was added
- * @session_timer: check if peer keeps Tx-ing on the TID (by timeout value)
- * @reorder_timer: releases expired frames from the reorder buffer.
  * @last_rx: jiffies of last rx activity
  * @head_seq_num: head sequence number in reordering buffer.
  * @stored_mpdu_num: number of MPDUs in reordering buffer
  * @ssn: Starting Sequence Number expected to be aggregated.
  * @buf_size: buffer size for incoming A-MPDUs
- * @timeout: reset timer value (in TUs).
  * @ssn_last_drop: SSN of the last dropped frame
  * @total: total number of processed incoming frames
  * @drop_dup: duplicate frames dropped for this reorder buffer
  * @drop_old: old frames dropped for this reorder buffer
- * @dialog_token: dialog token for aggregation session
  * @first_time: true when this buffer used 1-st time
  */
 struct wil_tid_ampdu_rx {
struct sk_buff **reorder_buf;
-   unsigned long *reorder_time;
-   struct timer_list session_timer;
-   struct timer_list reorder_timer;
unsigned long last_rx;
u16 head_seq_num;
u16 stored_mpdu_num;
u16 ssn;
u16 buf_size;
-   u16 timeout;
u16 ssn_last_drop;
unsigned long long total; /* frames processed */
unsigned long long drop_dup;
unsigned long long drop_old;
-   u8 dialog_token;
bool first_time; /* is it 1-st time this buffer used? */
 };
 
-- 
1.9.1

[PATCH 06/10] wil6210: use country specific board file upon reg domain change

[Maya Erez]

From: Dedy Lansky 

wil6210 device needs to use country specific board file while in China
regulatory domain.
Register cfg80211 reg_notifier and switch board file if needed
according to new regulatory domain.
This feature is disabled by default and can be enabled with a new
country_specific_board_file module parameter.

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 66 +
 drivers/net/wireless/ath/wil6210/main.c | 37 +---
 drivers/net/wireless/ath/wil6210/wil6210.h  |  6 +++
 3 files changed, 104 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index c2da159..ba9a81c 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -24,11 +24,16 @@
 #include "fw.h"
 
 #define WIL_MAX_ROC_DURATION_MS 5000
+#define CTRY_CHINA "CN"
 
 bool disable_ap_sme;
 module_param(disable_ap_sme, bool, 0444);
 MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
 
+static bool country_specific_board_file;
+module_param(country_specific_board_file, bool, 0444);
+MODULE_PARM_DESC(country_specific_board_file, " switch board file upon 
regulatory domain change (Default: false)");
+
 #ifdef CONFIG_PM
 static struct wiphy_wowlan_support wil_wowlan_support = {
.flags = WIPHY_WOWLAN_ANY | WIPHY_WOWLAN_DISCONNECT,
@@ -2124,6 +2129,65 @@ static int wil_cfg80211_resume(struct wiphy *wiphy)
return 0;
 }
 
+static int wil_switch_board_file(struct wil6210_priv *wil,
+const u8 *new_regdomain)
+{
+   int rc = 0;
+
+   if (!country_specific_board_file)
+   return 0;
+
+   if (memcmp(wil->regdomain, CTRY_CHINA, 2) == 0) {
+   wil_info(wil, "moving out of China reg domain, use default 
board file\n");
+   wil->board_file_country[0] = '\0';
+   } else if (memcmp(new_regdomain, CTRY_CHINA, 2) == 0) {
+   wil_info(wil, "moving into China reg domain, use country 
specific board file\n");
+   strlcpy(wil->board_file_country, CTRY_CHINA,
+   sizeof(wil->board_file_country));
+   } else {
+   return 0;
+   }
+
+   /* need to switch board file - reset the device */
+
+   mutex_lock(>mutex);
+
+   if (!wil_has_active_ifaces(wil, true, false) ||
+   wil_is_recovery_blocked(wil))
+   /* new board file will be used in next FW load */
+   goto out;
+
+   __wil_down(wil);
+   rc = __wil_up(wil);
+
+out:
+   mutex_unlock(>mutex);
+   return rc;
+}
+
+static void wil_cfg80211_reg_notify(struct wiphy *wiphy,
+   struct regulatory_request *request)
+{
+   struct wil6210_priv *wil = wiphy_to_wil(wiphy);
+   int rc;
+
+   wil_info(wil, "cfg reg_notify %c%c%s%s initiator %d hint_type %d\n",
+request->alpha2[0], request->alpha2[1],
+request->intersect ? " intersect" : "",
+request->processed ? " processed" : "",
+request->initiator, request->user_reg_hint_type);
+
+   if (memcmp(wil->regdomain, request->alpha2, 2) == 0)
+   /* reg domain did not change */
+   return;
+
+   rc = wil_switch_board_file(wil, request->alpha2);
+   if (rc)
+   wil_err(wil, "switch board file failed %d\n", rc);
+
+   memcpy(wil->regdomain, request->alpha2, sizeof(wil->regdomain));
+}
+
 static const struct cfg80211_ops wil_cfg80211_ops = {
.add_virtual_intf = wil_cfg80211_add_iface,
.del_virtual_intf = wil_cfg80211_del_iface,
@@ -2198,6 +2262,8 @@ static void wil_wiphy_init(struct wiphy *wiphy)
wiphy->n_vendor_commands = ARRAY_SIZE(wil_nl80211_vendor_commands);
wiphy->vendor_commands = wil_nl80211_vendor_commands;
 
+   wiphy->reg_notifier = wil_cfg80211_reg_notify;
+
 #ifdef CONFIG_PM
wiphy->wowlan = _wowlan_support;
 #endif
diff --git a/drivers/net/wireless/ath/wil6210/main.c 
b/drivers/net/wireless/ath/wil6210/main.c
index 82aec6b..52f12c6 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -26,6 +26,7 @@
 
 #define WAIT_FOR_HALP_VOTE_MS 100
 #define WAIT_FOR_SCAN_ABORT_MS 1000
+#define WIL_BOARD_FILE_MAX_NAMELEN 128
 
 bool debug_fw; /* = false; */
 module_param(debug_fw, bool, 0444);
@@ -943,6 +944,30 @@ void wil_mbox_ring_le2cpus(struct wil6210_mbox_ring *r)
le32_to_cpus(>head);
 }
 
+/* construct actual board file name to use */
+void wil_get_board_file(struct wil6210_priv *wil, char *buf, size_t len)
+{
+   const char *board_file = WIL_BOARD_FILE_NAME;
+   const char *ext;
+   int prefix_len;
+
+   if (wil->board_file_country[0] == '\0') {
+   strlcpy(buf, 

[PATCH 10/10] wil6210: rate limit wil_rx_refill error

[Maya Erez]

From: Dedy Lansky 

wil_err inside wil_rx_refill can flood the log buffer.
Replace it with wil_err_ratelimited.

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/txrx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/txrx.c 
b/drivers/net/wireless/ath/wil6210/txrx.c
index 411130a..b9a9fa8 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -652,8 +652,8 @@ static int wil_rx_refill(struct wil6210_priv *wil, int 
count)
v->swtail = next_tail) {
rc = wil_vring_alloc_skb(wil, v, v->swtail, headroom);
if (unlikely(rc)) {
-   wil_err(wil, "Error %d in wil_rx_refill[%d]\n",
-   rc, v->swtail);
+   wil_err_ratelimited(wil, "Error %d in rx refill[%d]\n",
+   rc, v->swtail);
break;
}
}
-- 
1.9.1

[PATCH 08/10] wil6210: Initialize reply struct of the WMI commands

[Maya Erez]

From: Alexei Avshalom Lazar 

WMI command reply saved in uninitialized struct.
In order to avoid accessing unset values from FW initialize
the reply struct.

Signed-off-by: Alexei Avshalom Lazar 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 22 ---
 drivers/net/wireless/ath/wil6210/debugfs.c  |  2 +
 drivers/net/wireless/ath/wil6210/main.c |  2 +
 drivers/net/wireless/ath/wil6210/txrx.c |  8 ++-
 drivers/net/wireless/ath/wil6210/wmi.c  | 97 ++---
 5 files changed, 85 insertions(+), 46 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 568d414..1202714 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -361,6 +361,8 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
struct wil_net_stats *stats = >sta[cid].stats;
int rc;
 
+   memset(, 0, sizeof(reply));
+
rc = wmi_call(wil, WMI_NOTIFY_REQ_CMDID, vif->mid, , sizeof(cmd),
  WMI_NOTIFY_REQ_DONE_EVENTID, , sizeof(reply), 20);
if (rc)
@@ -2401,7 +2403,9 @@ static int wil_rf_sector_get_cfg(struct wiphy *wiphy,
struct {
struct wmi_cmd_hdr wmi;
struct wmi_get_rf_sector_params_done_event evt;
-   } __packed reply;
+   } __packed reply = {
+   .evt = {.status = WMI_RF_SECTOR_STATUS_NOT_SUPPORTED_ERROR},
+   };
struct sk_buff *msg;
struct nlattr *nl_cfgs, *nl_cfg;
u32 i;
@@ -2447,7 +2451,6 @@ static int wil_rf_sector_get_cfg(struct wiphy *wiphy,
cmd.sector_idx = cpu_to_le16(sector_index);
cmd.sector_type = sector_type;
cmd.rf_modules_vec = rf_modules_vec & 0xFF;
-   memset(, 0, sizeof(reply));
rc = wmi_call(wil, WMI_GET_RF_SECTOR_PARAMS_CMDID, vif->mid,
  , sizeof(cmd), WMI_GET_RF_SECTOR_PARAMS_DONE_EVENTID,
  , sizeof(reply),
@@ -2522,7 +2525,9 @@ static int wil_rf_sector_set_cfg(struct wiphy *wiphy,
struct {
struct wmi_cmd_hdr wmi;
struct wmi_set_rf_sector_params_done_event evt;
-   } __packed reply;
+   } __packed reply = {
+   .evt = {.status = WMI_RF_SECTOR_STATUS_NOT_SUPPORTED_ERROR},
+   };
struct nlattr *nl_cfg;
struct wmi_rf_sector_info *si;
 
@@ -2605,7 +2610,6 @@ static int wil_rf_sector_set_cfg(struct wiphy *wiphy,
}
 
cmd.rf_modules_vec = rf_modules_vec & 0xFF;
-   memset(, 0, sizeof(reply));
rc = wmi_call(wil, WMI_SET_RF_SECTOR_PARAMS_CMDID, vif->mid,
  , sizeof(cmd), WMI_SET_RF_SECTOR_PARAMS_DONE_EVENTID,
  , sizeof(reply),
@@ -2629,7 +2633,9 @@ static int wil_rf_sector_get_selected(struct wiphy *wiphy,
struct {
struct wmi_cmd_hdr wmi;
struct wmi_get_selected_rf_sector_index_done_event evt;
-   } __packed reply;
+   } __packed reply = {
+   .evt = {.status = WMI_RF_SECTOR_STATUS_NOT_SUPPORTED_ERROR},
+   };
struct sk_buff *msg;
 
if (!test_bit(WMI_FW_CAPABILITY_RF_SECTORS, wil->fw_capabilities))
@@ -2669,7 +2675,6 @@ static int wil_rf_sector_get_selected(struct wiphy *wiphy,
memset(, 0, sizeof(cmd));
cmd.cid = (u8)cid;
cmd.sector_type = sector_type;
-   memset(, 0, sizeof(reply));
rc = wmi_call(wil, WMI_GET_SELECTED_RF_SECTOR_INDEX_CMDID, vif->mid,
  , sizeof(cmd),
  WMI_GET_SELECTED_RF_SECTOR_INDEX_DONE_EVENTID,
@@ -2710,14 +2715,15 @@ static int wil_rf_sector_wmi_set_selected(struct 
wil6210_priv *wil,
struct {
struct wmi_cmd_hdr wmi;
struct wmi_set_selected_rf_sector_index_done_event evt;
-   } __packed reply;
+   } __packed reply = {
+   .evt = {.status = WMI_RF_SECTOR_STATUS_NOT_SUPPORTED_ERROR},
+   };
int rc;
 
memset(, 0, sizeof(cmd));
cmd.sector_idx = cpu_to_le16(sector_index);
cmd.sector_type = sector_type;
cmd.cid = (u8)cid;
-   memset(, 0, sizeof(reply));
rc = wmi_call(wil, WMI_SET_SELECTED_RF_SECTOR_INDEX_CMDID, mid,
  , sizeof(cmd),
  WMI_SET_SELECTED_RF_SECTOR_INDEX_DONE_EVENTID,
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 10ffa4d..49d9808 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1078,6 +1078,8 @@ static int wil_bf_debugfs_show(struct seq_file *s, void 
*data)
struct wmi_notify_req_done_event evt;
} __packed reply;
 
+   memset(, 0, sizeof(reply));
+
for (i = 0; i < ARRAY_SIZE(wil->sta); i++) {
u32 status;
 

[PATCH 01/10] wil6210: disable tracing config option

[Maya Erez]

From: Alexei Avshalom Lazar 

Disable WIL6210_TRACING by default to avoid its performance overhead.

Signed-off-by: Alexei Avshalom Lazar 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wil6210/Kconfig 
b/drivers/net/wireless/ath/wil6210/Kconfig
index b448926..3548e8d 100644
--- a/drivers/net/wireless/ath/wil6210/Kconfig
+++ b/drivers/net/wireless/ath/wil6210/Kconfig
@@ -33,7 +33,7 @@ config WIL6210_TRACING
bool "wil6210 tracing support"
depends on WIL6210
depends on EVENT_TRACING
-   default y
+   default n
---help---
  Say Y here to enable tracepoints for the wil6210 driver
  using the kernel tracing infrastructure.  Select this
-- 
1.9.1

[PATCH 07/10] wil6210: move WMI functionality out of wil_cfg80211_mgmt_tx

[Maya Erez]

From: Dedy Lansky 

Rearrange the code by having new function wmi_mgmt_tx() to take care
of the WMI part of wil_cfg80211_mgmt_tx().

Signed-off-by: Dedy Lansky 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/cfg80211.c | 39 +++-
 drivers/net/wireless/ath/wil6210/wil6210.h  |  1 +
 drivers/net/wireless/ath/wil6210/wmi.c  | 47 +
 3 files changed, 52 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index ba9a81c..568d414 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1175,17 +1175,11 @@ int wil_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
wireless_dev *wdev,
 u64 *cookie)
 {
const u8 *buf = params->buf;
-   size_t len = params->len, total;
+   size_t len = params->len;
struct wil6210_priv *wil = wiphy_to_wil(wiphy);
struct wil6210_vif *vif = wdev_to_vif(wil, wdev);
int rc;
-   bool tx_status = false;
-   struct ieee80211_mgmt *mgmt_frame = (void *)buf;
-   struct wmi_sw_tx_req_cmd *cmd;
-   struct {
-   struct wmi_cmd_hdr wmi;
-   struct wmi_sw_tx_complete_event evt;
-   } __packed evt;
+   bool tx_status;
 
/* Note, currently we do not support the "wait" parameter, user-space
 * must call remain_on_channel before mgmt_tx or listen on a channel
@@ -1194,34 +1188,9 @@ int wil_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
wireless_dev *wdev,
 * different from currently "listened" channel and fail if it is.
 */
 
-   wil_dbg_misc(wil, "mgmt_tx mid %d\n", vif->mid);
-   wil_hex_dump_misc("mgmt tx frame ", DUMP_PREFIX_OFFSET, 16, 1, buf,
- len, true);
-
-   if (len < sizeof(struct ieee80211_hdr_3addr))
-   return -EINVAL;
-
-   total = sizeof(*cmd) + len;
-   if (total < len)
-   return -EINVAL;
-
-   cmd = kmalloc(total, GFP_KERNEL);
-   if (!cmd) {
-   rc = -ENOMEM;
-   goto out;
-   }
-
-   memcpy(cmd->dst_mac, mgmt_frame->da, WMI_MAC_LEN);
-   cmd->len = cpu_to_le16(len);
-   memcpy(cmd->payload, buf, len);
-
-   rc = wmi_call(wil, WMI_SW_TX_REQ_CMDID, vif->mid, cmd, total,
- WMI_SW_TX_COMPLETE_EVENTID, , sizeof(evt), 2000);
-   if (rc == 0)
-   tx_status = !evt.evt.status;
+   rc = wmi_mgmt_tx(vif, buf, len);
+   tx_status = (rc == 0);
 
-   kfree(cmd);
- out:
cfg80211_mgmt_tx_status(wdev, cookie ? *cookie : 0, buf, len,
tx_status, GFP_KERNEL);
return rc;
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
b/drivers/net/wireless/ath/wil6210/wil6210.h
index 633eb71..2f77319 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -1157,6 +1157,7 @@ int wil_request_firmware(struct wil6210_priv *wil, const 
char *name,
 int wmi_start_sched_scan(struct wil6210_priv *wil,
 struct cfg80211_sched_scan_request *request);
 int wmi_stop_sched_scan(struct wil6210_priv *wil);
+int wmi_mgmt_tx(struct wil6210_vif *vif, const u8 *buf, size_t len);
 
 int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch);
 int wil_spec2wmi_ch(u8 spec_ch, u8 *wmi_ch);
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index cdaf80d..27ba42d 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -2792,3 +2792,50 @@ int wmi_stop_sched_scan(struct wil6210_priv *wil)
 
return 0;
 }
+
+int wmi_mgmt_tx(struct wil6210_vif *vif, const u8 *buf, size_t len)
+{
+   size_t total;
+   struct wil6210_priv *wil = vif_to_wil(vif);
+   struct ieee80211_mgmt *mgmt_frame = (void *)buf;
+   struct wmi_sw_tx_req_cmd *cmd;
+   struct {
+   struct wmi_cmd_hdr wmi;
+   struct wmi_sw_tx_complete_event evt;
+   } __packed evt = {
+   .evt = {.status = WMI_FW_STATUS_FAILURE},
+   };
+   int rc;
+
+   wil_dbg_misc(wil, "mgmt_tx mid %d\n", vif->mid);
+   wil_hex_dump_misc("mgmt tx frame ", DUMP_PREFIX_OFFSET, 16, 1, buf,
+ len, true);
+
+   if (len < sizeof(struct ieee80211_hdr_3addr))
+   return -EINVAL;
+
+   total = sizeof(*cmd) + len;
+   if (total < len) {
+   wil_err(wil, "mgmt_tx invalid len %zu\n", len);
+   return -EINVAL;
+   }
+
+   cmd = kmalloc(total, GFP_KERNEL);
+   if (!cmd)
+   return -ENOMEM;
+
+   memcpy(cmd->dst_mac, mgmt_frame->da, WMI_MAC_LEN);
+   cmd->len = cpu_to_le16(len);
+   memcpy(cmd->payload, buf, len);
+
+   rc = wmi_call(wil, WMI_SW_TX_REQ_CMDID, 

[PATCH 03/10] wil6210: align to latest auto generated wmi.h

[Maya Erez]

From: Ahmad Masri 

Align to latest version of the auto generated wmi file
describing the interface with FW

Signed-off-by: Ahmad Masri 
Signed-off-by: Maya Erez 
---
 drivers/net/wireless/ath/wil6210/wmi.c |   6 +-
 drivers/net/wireless/ath/wil6210/wmi.h | 387 +++--
 2 files changed, 371 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/wmi.c 
b/drivers/net/wireless/ath/wil6210/wmi.c
index 062ead3..9f2c21b 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -1564,7 +1564,9 @@ int wmi_pcp_start(struct wil6210_vif *vif,
.pcp_max_assoc_sta = max_assoc_sta,
.hidden_ssid = hidden_ssid,
.is_go = is_go,
-   .disable_ap_sme = disable_ap_sme,
+   .ap_sme_offload_mode = disable_ap_sme ?
+  WMI_AP_SME_OFFLOAD_PARTIAL :
+  WMI_AP_SME_OFFLOAD_FULL,
.abft_len = wil->abft_len,
};
struct {
@@ -1593,7 +1595,7 @@ int wmi_pcp_start(struct wil6210_vif *vif,
}
 
if (disable_ap_sme &&
-   !test_bit(WMI_FW_CAPABILITY_DISABLE_AP_SME,
+   !test_bit(WMI_FW_CAPABILITY_AP_SME_OFFLOAD_PARTIAL,
  wil->fw_capabilities)) {
wil_err(wil, "disable_ap_sme not supported by FW\n");
return -EOPNOTSUPP;
diff --git a/drivers/net/wireless/ath/wil6210/wmi.h 
b/drivers/net/wireless/ath/wil6210/wmi.h
index ecd4b44..92f63c5 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  * Copyright (c) 2012-2017 Qualcomm Atheros, Inc.
  * Copyright (c) 2006-2012 Wilocity
  *
@@ -29,8 +30,6 @@
 #ifndef __WILOCITY_WMI_H__
 #define __WILOCITY_WMI_H__
 
-/* General */
-#define WMI_MAX_ASSOC_STA  (8)
 #define WMI_DEFAULT_ASSOC_STA  (1)
 #define WMI_MAC_LEN(6)
 #define WMI_PROX_RANGE_NUM (3)
@@ -41,6 +40,19 @@
 #define WMI_RF_ETYPE_LENGTH(3)
 #define WMI_RF_RX2TX_LENGTH(3)
 #define WMI_RF_ETYPE_VAL_PER_RANGE (5)
+/* DTYPE configuration array size
+ * must always be kept equal to (WMI_RF_DTYPE_LENGTH+1)
+ */
+#define WMI_RF_DTYPE_CONF_LENGTH   (4)
+/* ETYPE configuration array size
+ * must always be kept equal to
+ * (WMI_RF_ETYPE_LENGTH+WMI_RF_ETYPE_VAL_PER_RANGE)
+ */
+#define WMI_RF_ETYPE_CONF_LENGTH   (8)
+/* RX2TX configuration array size
+ * must always be kept equal to (WMI_RF_RX2TX_LENGTH+1)
+ */
+#define WMI_RF_RX2TX_CONF_LENGTH   (4)
 
 /* Mailbox interface
  * used for commands and events
@@ -61,7 +73,7 @@ enum wmi_fw_capability {
WMI_FW_CAPABILITY_PS_CONFIG = 1,
WMI_FW_CAPABILITY_RF_SECTORS= 2,
WMI_FW_CAPABILITY_MGMT_RETRY_LIMIT  = 3,
-   WMI_FW_CAPABILITY_DISABLE_AP_SME= 4,
+   WMI_FW_CAPABILITY_AP_SME_OFFLOAD_PARTIAL= 4,
WMI_FW_CAPABILITY_WMI_ONLY  = 5,
WMI_FW_CAPABILITY_THERMAL_THROTTLING= 7,
WMI_FW_CAPABILITY_D3_SUSPEND= 8,
@@ -74,6 +86,7 @@ enum wmi_fw_capability {
WMI_FW_CAPABILITY_PNO   = 15,
WMI_FW_CAPABILITY_CHANNEL_BONDING   = 17,
WMI_FW_CAPABILITY_REF_CLOCK_CONTROL = 18,
+   WMI_FW_CAPABILITY_AP_SME_OFFLOAD_NONE   = 19,
WMI_FW_CAPABILITY_MAX,
 };
 
@@ -165,12 +178,14 @@ enum wmi_command_id {
WMI_SET_ACTIVE_SILENT_RSSI_TABLE_CMDID  = 0x85C,
WMI_RF_PWR_ON_DELAY_CMDID   = 0x85D,
WMI_SET_HIGH_POWER_TABLE_PARAMS_CMDID   = 0x85E,
+   WMI_FIXED_SCHEDULING_UL_CONFIG_CMDID= 0x85F,
/* Performance monitoring commands */
WMI_BF_CTRL_CMDID   = 0x862,
WMI_NOTIFY_REQ_CMDID= 0x863,
WMI_GET_STATUS_CMDID= 0x864,
WMI_GET_RF_STATUS_CMDID = 0x866,
WMI_GET_BASEBAND_TYPE_CMDID = 0x867,
+   WMI_VRING_SWITCH_TIMING_CONFIG_CMDID= 0x868,
WMI_UNIT_TEST_CMDID = 0x900,
WMI_FLASH_READ_CMDID= 0x902,
WMI_FLASH_WRITE_CMDID   = 0x903,
@@ -203,6 +218,7 @@ enum wmi_command_id {
WMI_GET_THERMAL_THROTTLING_CFG_CMDID= 0x941,
/* Read Power Save profile type */
WMI_PS_DEV_PROFILE_CFG_READ_CMDID   = 0x942,
+   WMI_TSF_SYNC_CMDID  = 0x973,
WMI_TOF_SESSION_START_CMDID = 0x991,

[PATCH 00/10] wil6210 patches

[Maya Erez]

The following patches include multiple wil6210 fixes.

Ahmad Masri (1):
  wil6210: align to latest auto generated wmi.h

Alexei Avshalom Lazar (3):
  wil6210: disable tracing config option
  wil6210: set/get EDMG channel through debugfs
  wil6210: Initialize reply struct of the WMI commands

Dedy Lansky (4):
  wil6210: use country specific board file upon reg domain change
  wil6210: move WMI functionality out of wil_cfg80211_mgmt_tx
  wil6210: remove unused rx_reorder members
  wil6210: rate limit wil_rx_refill error

Lior David (2):
  wil6210: fix call to wil6210_disconnect during unload
  wil6210: change reply_size arg to u16 in wmi_call

 drivers/net/wireless/ath/wil6210/Kconfig  |   2 +-
 drivers/net/wireless/ath/wil6210/cfg80211.c   | 216 ++---
 drivers/net/wireless/ath/wil6210/debugfs.c|   6 +-
 drivers/net/wireless/ath/wil6210/main.c   |  39 ++-
 drivers/net/wireless/ath/wil6210/netdev.c |   8 +-
 drivers/net/wireless/ath/wil6210/rx_reorder.c |   7 +-
 drivers/net/wireless/ath/wil6210/txrx.c   |  12 +-
 drivers/net/wireless/ath/wil6210/wil6210.h|  23 +-
 drivers/net/wireless/ath/wil6210/wmi.c| 177 ---
 drivers/net/wireless/ath/wil6210/wmi.h| 420 --
 10 files changed, 769 insertions(+), 141 deletions(-)

-- 
1.9.1

[PATCH v2] staging: wilc1000: Remove unnecessary braces {} around single statement block

[Eyal Ilsar]

Remove unnecessary braces {} around an 'if' statement block with a single 
statement. Issue found by checkpatch.

Signed-off-by: Eyal Ilsar 
---
Added an empty line before the 'Signed-off-by' line and a space between the
name and e-mail address within that line.

 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 205304c..325afe1 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -284,9 +284,8 @@ static void remove_network_from_shadow(struct timer_list 
*unused)
}
}
 
-   if (last_scanned_cnt != 0) {
+   if (last_scanned_cnt != 0)
mod_timer(, jiffies + msecs_to_jiffies(AGING_TIME));
-   }
 }
 
 static void clear_duringIP(struct timer_list *unused)
-- 
2.7.4

Re: [PATCH] ath10k:add support for multicast rate control

[Sven Eckelmann]

On Mittwoch, 11. April 2018 21:04:46 CEST Pradeep Kumar Chitrapu wrote:
> Issues wmi command to firmware when multicast rate change is received
> with the new BSS_CHANGED_MCAST_RATE flag.
[...]
>  
> + if (changed & BSS_CHANGED_MCAST_RATE &&
> + !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
> + band = def.chan->band;
> + sband = >mac.sbands[band];
> + vdev_param = ar->wmi.vdev_param->mcast_data_rate;
> + rate_index = vif->bss_conf.mcast_rate[band] - 1;
> + rate = ATH10K_HW_MCS_RATE(sband->bitrates[rate_index].hw_value);
> + ath10k_dbg(ar, ATH10K_DBG_MAC,
> +"mac vdev %d mcast_rate %d\n",
> +arvif->vdev_id, rate);
> +
> + ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
> + vdev_param, rate);
> + if (ret)
> + ath10k_warn(ar,
> + "failed to set mcast rate on vdev"
> + " %i: %d\n", arvif->vdev_id,  ret);
> + }
> +
>   mutex_unlock(>conf_mutex);
>  }
>  
> 

I see two major problems here without checking the actual implementation 
details:

* hw_value is incorrect for a couple of devices. Some devices use a different 
  mapping when they receive rates inforamtion (hw_value) then the ones you use
  for the mcast/bcast/beacon rate setting. I've handled in my POC patch like
  this:

+   if (ath10k_mac_bitrate_is_cck(sband->bitrates[i].bitrate)) {
+   preamble = WMI_RATE_PREAMBLE_CCK;
+
+   /* QCA didn't use the correct rate values for CA99x0
+* and above (ath10k_g_rates_rev2)
+*/
+   switch (sband->bitrates[i].bitrate) {
+   case 10:
+   hw_value = ATH10K_HW_RATE_CCK_LP_1M;
+   break;
+   case 20:
+   hw_value = ATH10K_HW_RATE_CCK_LP_2M;
+   break;
+   case 55:
+   hw_value = ATH10K_HW_RATE_CCK_LP_5_5M;
+   break;
+   case 110:
+   hw_value = ATH10K_HW_RATE_CCK_LP_11M;
+   break;
+   }
+   } else {
+   preamble = WMI_RATE_PREAMBLE_OFDM;
+   }

* bcast + mcast (+ mgmt) have to be set separately

I have attached my POC patch (which I was using for packet loss based mesh 
metrics) and to work around (using debugfs) the silly mgmt vs. mcast/bcast 
settings of the QCA fw for APs.

Many of the information came from Ben Greears ath10k-ct driver 
https://github.com/greearb/ath10k-ct 

Kind regards,   
SvenFrom: Sven Eckelmann 
Date: Fri, 16 Feb 2018 13:49:51 +0100
Subject: [PATCH] ath10k: Allow to configure bcast/mcast rate

TODO:

 * find better way to get mcast_rate
 * better get the lowest configured basic rate for APs
 * remove netifd WAR

Signed-off-by: Sven Eckelmann 

Forwarded: no
 not yet in the correct shape
---
 drivers/net/wireless/ath/ath10k/core.h  |   1 +
 drivers/net/wireless/ath/ath10k/debug.c |  78 ++
 drivers/net/wireless/ath/ath10k/debug.h |  11 
 drivers/net/wireless/ath/ath10k/mac.c   | 113 
 drivers/net/wireless/ath/ath10k/mac.h   |   1 +
 5 files changed, 204 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3ff4a423c4d873d322deebd3c498ef0688e84e05..a53f7b2042f4a80bbd358b00d4d26d6fabe5df6e 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -423,6 +423,7 @@ struct ath10k_vif {
 	bool nohwcrypt;
 	int num_legacy_stations;
 	int txpower;
+	u16 mcast_rate;
 	struct wmi_wmm_params_all_arg wmm_params;
 	struct work_struct ap_csa_work;
 	struct delayed_work connection_loss_work;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index fa72ef54605e74f501ab655a6afd0a50b89b6b7e..fc59f214d2a5288f2ac41824e584def787b4799c 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -23,6 +23,7 @@
 #include 
 
 #include "core.h"
+#include "mac.h"
 #include "debug.h"
 #include "hif.h"
 #include "wmi-ops.h"
@@ -2454,6 +2455,83 @@ void ath10k_debug_unregister(struct ath10k *ar)
 	cancel_delayed_work_sync(>debug.htt_stats_dwork);
 }
 
+
+
+static ssize_t ath10k_write_mcast_rate(struct file *file,
+   const char __user *ubuf,
+   size_t count, loff_t *ppos)
+{
+	struct ath10k_vif *arvif = file->private_data;
+	struct ath10k *ar = arvif->ar;
+	ssize_t ret = 0;
+	u32 mcast_rate;
+
+	ret = kstrtou32_from_user(ubuf, count, 0, _rate);

[PATCH 00/10] wil6210 patches

[Maya Erez]

The following patches include multiple wil6210 fixes.

Ahmad Masri (1):
  wil6210: align to latest auto generated wmi.h

Alexei Avshalom Lazar (2):
  wil6210: disable tracing config option
  wil6210: set/get EDMG channel through debugfs

Dedy Lansky (4):
  wil6210: use country specific board file upon reg domain change
  wil6210: move WMI functionality out of wil_cfg80211_mgmt_tx
  wil6210: remove unused rx_reorder members
  wil6210: rate limit wil_rx_refill error

Lazar Alexei (1):
  wil6210: Initialize reply struct of the WMI commands

Lior David (2):
  wil6210: fix call to wil6210_disconnect during unload
  wil6210: change reply_size arg to u16 in wmi_call

 drivers/net/wireless/ath/wil6210/Kconfig  |   2 +-
 drivers/net/wireless/ath/wil6210/cfg80211.c   | 216 ++---
 drivers/net/wireless/ath/wil6210/debugfs.c|   6 +-
 drivers/net/wireless/ath/wil6210/main.c   |  39 ++-
 drivers/net/wireless/ath/wil6210/netdev.c |   8 +-
 drivers/net/wireless/ath/wil6210/rx_reorder.c |   7 +-
 drivers/net/wireless/ath/wil6210/txrx.c   |  12 +-
 drivers/net/wireless/ath/wil6210/wil6210.h|  23 +-
 drivers/net/wireless/ath/wil6210/wmi.c| 177 ---
 drivers/net/wireless/ath/wil6210/wmi.h| 420 --
 10 files changed, 769 insertions(+), 141 deletions(-)

-- 
1.9.1

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 9:00 AM, solsTiCe d'Hiver wrote:

Nobody cares about this ?

Should I report this as a bug to the LKML ? or elsewhere ? to
ath9k_htc dev ? to crda dev ?

Please.


Hi,

I do not think nobody cares, but what you describe is actually no issue 
as far as I can determine. Wifi cards are typically programmed with some 
country code and both provide that as a regulatory hint to the 
regulatory framework, which adapts to a regulatory domain in which only 
channels and power limits are set that are allowed for both devices. 
That is why some of the rules in the global set #98 are matching the FR 
set and some rules match the CN set. And because FR uses ETSI DFS and CN 
uses FCC DFS you are loosing all channels that require DFS.


Regards,
Arend



2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver :

hi.

I am trying to capture on 2 channels at the same time with 2 cards.

One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
an Alfa AWUS051NH v2 using rt2800usb.

I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
reproduced the issue on a netbook using archlinux x64 too using latest
kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
too)

So when the Alfa card is used alone using the default reg dom FR, one
can change to 112 channel for example (using iw dev wlan1 set channel
112)

But once the tp-link is plugged in, reg dom seems to become CN and one
can't change the alfa card to 112 channel.

iw reg get output change from
global
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
to
global
country 98: DFS-UNSET
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 40), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)

phy#2
country CN: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 44), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)


and all the channels above 100 are marked as disabled in iw list
output (after the plug not before) for the alfa card

It is as if the TL-WN722N has CN reg dom hard-coded and that switches
it globally to CN too ???

Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??

Re: [PATCH] staging: wilc1000: Remove unnecessary braces {} around single statement block

[Claudiu Beznea]

On 10.04.2018 17:49, Eyal Ilsar wrote:
> Remove unnecessary braces {} around an 'if' statement block with a single 
> statement. Issue found by checkpatch.

You should add an empty line before "Signed-off" line as stated in [1]. I
would also add a space b/w your name and your email in Signed-off line as
is exemplified in [2].

[1]
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format
[2] https://www.kernel.org/doc/html/latest/process/sub
mitting-patches.html#developer-s-certificate-of-origin-1-1

> Signed-off-by: Eyal Ilsar
> ---
> This is part of my take on the Eudyptula challenge
> 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 205304c..325afe1 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -284,9 +284,8 @@ static void remove_network_from_shadow(struct timer_list 
> *unused)
>   }
>   }
>  
> - if (last_scanned_cnt != 0) {
> + if (last_scanned_cnt != 0)
>   mod_timer(, jiffies + msecs_to_jiffies(AGING_TIME));
> - }
>  }
>  
>  static void clear_duringIP(struct timer_list *unused)
> 

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

Nobody cares about this ?

Should I report this as a bug to the LKML ? or elsewhere ? to
ath9k_htc dev ? to crda dev ?

Please.

2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver :
> hi.
>
> I am trying to capture on 2 channels at the same time with 2 cards.
>
> One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
> an Alfa AWUS051NH v2 using rt2800usb.
>
> I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
> reproduced the issue on a netbook using archlinux x64 too using latest
> kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
> too)
>
> So when the Alfa card is used alone using the default reg dom FR, one
> can change to 112 channel for example (using iw dev wlan1 set channel
> 112)
>
> But once the tp-link is plugged in, reg dom seems to become CN and one
> can't change the alfa card to 112 channel.
>
> iw reg get output change from
> global
> country FR: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> to
> global
> country 98: DFS-UNSET
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 40), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>
> phy#2
> country CN: DFS-FCC
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 44), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>
>
> and all the channels above 100 are marked as disabled in iw list
> output (after the plug not before) for the alfa card
>
> It is as if the TL-WN722N has CN reg dom hard-coded and that switches
> it globally to CN too ???
>
> Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??