Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

2016-04-16 Thread Arnd Bergmann
On Wednesday 13 April 2016 10:38:26 Johannes Berg wrote:
> > The patch was build-tested / debugged by removing the
> > "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
> 
> Stands to reason that we should just remove the (more or less) dead
> code, since I don't think anyone really ever touches this driver any
> more or will ever again ...

Do you mean removing all DEBUG() statements from the driver, or
removing the entire driver?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 4/5] mac80211: implement codel on fair queuing flows

2016-04-16 Thread Johannes Berg
On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote:
> 
> + struct ieee80211_vif *vif;
> +
> + /* When packets are enqueued on txq
> it's easy
> +  * to re-construct the vif pointer.
> There's no
> +  * more space in tx_info so it can
> be used to
> +  * store the necessary enqueue time
> for packet
> +  * sojourn time computation.
> +  */
> + u64 enqueue_time;
> + };

I wonder if we could move something like the hw_key into tx_control
instead?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 2/5] mac80211: implement fair queueing per txq

2016-04-16 Thread Johannes Berg
On Sun, 2016-04-17 at 00:23 +0200, Johannes Berg wrote:
> On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote:
> > 
> >  
> > +++ b/net/mac80211/fq.h
> > 
> Now that you've mostly rewritten it, why keep it in a .h file?
> 

I think I just confused this with codel.h, but still - why a .h file
with all this "real" code, meaning the file can really only be included
once?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 2/5] mac80211: implement fair queueing per txq

2016-04-16 Thread Johannes Berg
On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote:
> 
> +++ b/net/mac80211/fq.h
> 
Now that you've mostly rewritten it, why keep it in a .h file?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 1/5] mac80211: skip netdev queue control with software queuing

2016-04-16 Thread Johannes Berg
> +static void ieee80211_txq_enqueue(struct ieee80211_local *local,
> +   struct txq_info *txqi,
> +   struct sk_buff *skb)
> +{
> + lockdep_assert_held(>queue.lock);
[...]
> + atomic_inc(>num_tx_queued);

This global kinda bothers me - anything we can do about removing it?

We obviously didn't have it now - just one (even bigger limit!) per
queue, so that's 4000 frames default per interface ... now you're down
to 512 for the entire hardware. Perhaps keeping it per interface at
least gets away the worst of the contention here?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] cfg80211: Advertise extended capabilities per interface type to userspace

2016-04-16 Thread Johannes Berg
On Fri, 2016-04-15 at 16:57 +0530, Kanchanapally, Vidyullatha wrote:
> 
> +struct wiphy_iftype_ext_capab {
> + enum nl80211_iftype iftype;
> + const u8 *ext_capab;
> + const u8 *ext_capab_mask;
> + u8 ext_capab_len;

I think you should reuse the struct member names that we used before -
that will make grepping for them easier.

> + struct wiphy_iftype_ext_capab *iftype_ext_capab;

const

> + * @NL80211_ATTR_IFTYPE_EXT_CAPA: Nested attribute of the following
> attributes:
> + *   %NL80211_ATTR_IFTYPE, %NL80211_ATTR_EXT_CAPA,
> + *   %NL80211_ATTR_EXT_CAPA_MASK, to specify the extended
> capabilities per
> + *   interface type.

That's a bit awkward to parse, since you have to parse the big
attribute list again, but I guess it still makes more sense than having
entirely different attributes.
 
> + state->split_start++;
> + break;
> + case 13:
> + if (rdev->wiphy.num_iftype_ext_capab &&
> + rdev->wiphy.iftype_ext_capab) {
> + struct nlattr *nested_ext_capab, *nested;
> +
> + nested = nla_nest_start(msg,
> + NL80211_ATTR_IFTYPE_
> EXT_CAPA);
> + if (!nested)
> + goto nla_put_failure;
> +
> + for (i = 0; i < rdev-
> >wiphy.num_iftype_ext_capab; i++) {
> + struct wiphy_iftype_ext_capab
> *capab;
> +
> + capab = 
> >wiphy.iftype_ext_capab[i];
> + nested_ext_capab =
> nla_nest_start(msg, i);
> + if (!nested_ext_capab ||
> + nla_put_u32(msg,
> NL80211_ATTR_IFTYPE,
> + capab->iftype) ||
> + nla_put(msg,
> NL80211_ATTR_EXT_CAPA,
> + capab->ext_capab_len,
> + capab->ext_capab) ||
> + nla_put(msg,
> NL80211_ATTR_EXT_CAPA_MASK,
> + capab->ext_capab_len,
> + capab->ext_capab_mask))
> + goto nla_put_failure;
> +
> + nla_nest_end(msg, nested_ext_capab);
> + }
> + nla_nest_end(msg, nested);
> + }

I think we should consider allowing this to be split multiple messages
(for different interface types), since this can potentially get rather
long (interface types x 2 x capa len). OTOH, we'd have to get a LOT of
interface types x capabilities to hit the limit of 4k, not sure. But it
should just require a few lines of code to do this.


Also, if it's possible, perhaps we should consider checking that nobody
globally advertises any capabilities they don't advertise on all
possible interface types?

I'm assuming that not listing an interface type would mean that the
global defaults apply, but old userspace will also not know about the
per-interface, so you shouldn't list anything there.

So I'm thinking something like

supported_on_all = iftype_ext_capab[0]
for i in 1..num_iftype_ext_capab-1:
    supported_on_all &= iftype_ext_capab[i]
WARN_ON(wiphy->ext_capa_mask & ~supported_on_all)

(which is obviously some kind of pseudo-code.)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] netlink: don't send NETLINK_URELEASE for unbound sockets

2016-04-16 Thread Johannes Berg
On Sat, 2016-04-16 at 14:30 +0800, Herbert Xu wrote:
> Johannes Berg  wrote:
> > 
> > 
> > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> > index 215fc08c02ab..330ebd600f25 100644
> > --- a/net/netlink/af_netlink.c
> > +++ b/net/netlink/af_netlink.c
> > @@ -688,7 +688,7 @@ static int netlink_release(struct socket *sock)
> > 
> >    skb_queue_purge(>sk_write_queue);
> > 
> > -   if (nlk->portid) {
> > +   if (nlk->portid && nlk->bound) {
> Any reason why we're still testing portid at all? Isn't testing
> bound enough?

The reason is that while I felt confident in understanding the problem
and its solution, I didn't realize that bound follows portid, and that,
for example, a kernel socket can't get bound. :-)

But yeah - looking at the code after your comment does show that
testing portid is pointless now.

In fact, now that I look at it, I wonder how this situation came about?

In the current code, you can only trigger the problematic situation
through an error condition, afaict - you have to try to bind a socket
with the same portid as an already existing one, and __netlink_insert()
will then fail, but netlink_insert() won't reset the nlk_sk(sk)->portid 
since your commit da314c9923fe ("netlink: Replace rhash_portid with
bound"), even though you had previously fixed precisely this issue
already - commit c0bb07df7d98 ("netlink: Reset portid after
netlink_insert failure"). You then close the socket, and since portid
is assigned, that will trigger NETLINK_URELEASE.

So before the rhash_portid -> bound change, this doesn't seem to have
been a problem, and I guess we didn't get the "stuck in limbo" problem
back because we now check bound everywhere relevant, for purposes of
calling netlink_autobind.

IOW - I'm now even more convinced that the patch is correct, and I'm
also convinced that until fairly recently (da314c9923fe) this wasn't
even a problem.

Maybe we can take the opportunity of removing the "portid" check to put
most of the above into a commit message, but I think you should review
it first.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

2016-04-16 Thread Grumbach, Emmanuel
On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote:
> On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> > [1] 
> > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> > fi.git/
> 
> It is very strange to pull from this repo, git fetch is doing
> something
> for a while now without any forward progress.

This is not surprising at all. This tree is not a kernel tree, but
rather a backport tree. It doesn't contain anything besides the Wifi
stack and the backport code. It has no common commit with the Linux
kernel. I understand that you fetched this tree from a kernel tree but
that's not a good idea. Git will try to find a common ancestor but that
will fail... after a huge number of tentatives. You'd better clone it.

> In any case, 4.5 is bad too, testing 4.4 now.

Here you go.

> I 'm travelling currently
> so the whole bisection deal will take a whole but I'll get to it
> eventually.

I'll be glad to see something coming out of this, but I can't say I am
very optimistic.

> 
> Thanks for taking a look.
> 

Re: [PATCH] ath9k: remove repetitions of mask array size

2016-04-16 Thread Oleksij Rempel
Thank you!

Kalle should be in CC.

Am 16.04.2016 um 16:54 schrieb Bob Copeland:
> The constant "123", which is the number of elements in
> mask_m / mask_p, is repeated several times in this function.
> 
> Replace memsets with array initialization, and replace a loop
> conditional with ARRAY_SIZE() so that we don't repeat ourselves.
> 
> Signed-off-by: Bob Copeland 

Reviewed-by: Oleksij Rempel 

> ---
>  drivers/net/wireless/ath/ath9k/ar5008_phy.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
> b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> index 1b271b9..8eea8d2 100644
> --- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> +++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
> @@ -260,8 +260,8 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   int cur_bin;
>   int upper, lower, cur_vit_mask;
>   int i;
> - int8_t mask_m[123];
> - int8_t mask_p[123];
> + int8_t mask_m[123] = {0};
> + int8_t mask_p[123] = {0};
>   int8_t mask_amt;
>   int tmp_mask;
>   static const int pilot_mask_reg[4] = {
> @@ -274,9 +274,6 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   };
>   static const int inc[4] = { 0, 100, 0, 0 };
>  
> - memset(_m, 0, sizeof(int8_t) * 123);
> - memset(_p, 0, sizeof(int8_t) * 123);
> -
>   cur_bin = -6000;
>   upper = bin + 100;
>   lower = bin - 100;
> @@ -302,7 +299,7 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>   upper = bin + 120;
>   lower = bin - 120;
>  
> - for (i = 0; i < 123; i++) {
> + for (i = 0; i < ARRAY_SIZE(mask_m); i++) {
>   if ((cur_vit_mask > lower) && (cur_vit_mask < upper)) {
>   /* workaround for gcc bug #37014 */
>   volatile int tmp_v = abs(cur_vit_mask - bin);
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature


Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

2016-04-16 Thread Borislav Petkov
On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> fi.git/

It is very strange to pull from this repo, git fetch is doing something
for a while now without any forward progress.

In any case, 4.5 is bad too, testing 4.4 now. I'm travelling currently
so the whole bisection deal will take a whole but I'll get to it
eventually.

Thanks for taking a look.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply. Srsly.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] carl9170: Clarify kconfig text

2016-04-16 Thread Christian Lamparter
On Saturday, April 16, 2016 05:18:56 PM Lauri Kasanen wrote:
> The previous text was confusing, leading readers to think this
> driver was a duplicate, and so didn't need to be enabled.
> 
> After the removal of the older staging driver, this is the only
> driver in mainline for these devices.
> 
> Signed-off-by: Lauri Kasanen 
Acked-by: Christian Lamparter 

> ---
> v2: Remove the mention of the previous driver, suggested by Christian.

Thanks!
 
>  drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
> b/drivers/net/wireless/ath/carl9170/Kconfig
> index 1a796e5..2e34bae 100644
> --- a/drivers/net/wireless/ath/carl9170/Kconfig
> +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> @@ -5,12 +5,10 @@ config CARL9170
>   select FW_LOADER
>   select CRC32
>   help
> -   This is another driver for the Atheros "otus" 802.11n USB devices.
> +   This is the mainline driver for the Atheros "otus" 802.11n USB 
> devices.
>  
> -   This driver provides more features than the original,
> -   but it needs a special firmware (carl9170-1.fw) to do that.
> -
> -   The firmware can be downloaded from our wiki here:
> +   It needs a special firmware (carl9170-1.fw), which can be downloaded
> +   from our wiki here:
> 
>  
> If you choose to build a module, it'll be called carl9170.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ath9k: remove repetitions of mask array size

2016-04-16 Thread Bob Copeland
The constant "123", which is the number of elements in
mask_m / mask_p, is repeated several times in this function.

Replace memsets with array initialization, and replace a loop
conditional with ARRAY_SIZE() so that we don't repeat ourselves.

Signed-off-by: Bob Copeland 
---
 drivers/net/wireless/ath/ath9k/ar5008_phy.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 1b271b9..8eea8d2 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -260,8 +260,8 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
int cur_bin;
int upper, lower, cur_vit_mask;
int i;
-   int8_t mask_m[123];
-   int8_t mask_p[123];
+   int8_t mask_m[123] = {0};
+   int8_t mask_p[123] = {0};
int8_t mask_amt;
int tmp_mask;
static const int pilot_mask_reg[4] = {
@@ -274,9 +274,6 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
};
static const int inc[4] = { 0, 100, 0, 0 };
 
-   memset(_m, 0, sizeof(int8_t) * 123);
-   memset(_p, 0, sizeof(int8_t) * 123);
-
cur_bin = -6000;
upper = bin + 100;
lower = bin - 100;
@@ -302,7 +299,7 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
upper = bin + 120;
lower = bin - 120;
 
-   for (i = 0; i < 123; i++) {
+   for (i = 0; i < ARRAY_SIZE(mask_m); i++) {
if ((cur_vit_mask > lower) && (cur_vit_mask < upper)) {
/* workaround for gcc bug #37014 */
volatile int tmp_v = abs(cur_vit_mask - bin);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

2016-04-16 Thread Bob Copeland
On Sat, Apr 16, 2016 at 08:01:59AM +0200, Oleksij Rempel wrote:
> > For a future patch, "sizeof(mask_m)" or even just:
> > 
> > u8 mask_m[123] = {0};
> > 
> > ... would be better here.  I looked at this bit and thought, no way is
> > "123" actually correct.  Lo and behold, that is actually the number of
> > array elements, whether that has a basis in something real or not :)
> 
> If you already on it can you please rework it on top of this patch?
> This complete function can be probably reworked.

I wasn't on it, but yeah I'll send a patch on top of this momentarily :)

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] carl9170: Clarify kconfig text

2016-04-16 Thread Lauri Kasanen
The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.

After the removal of the older staging driver, this is the only
driver in mainline for these devices.

Signed-off-by: Lauri Kasanen 
---
v2: Remove the mention of the previous driver, suggested by Christian.

 drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..2e34bae 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -5,12 +5,10 @@ config CARL9170
select FW_LOADER
select CRC32
help
- This is another driver for the Atheros "otus" 802.11n USB devices.
+ This is the mainline driver for the Atheros "otus" 802.11n USB 
devices.
 
- This driver provides more features than the original,
- but it needs a special firmware (carl9170-1.fw) to do that.
-
- The firmware can be downloaded from our wiki here:
+ It needs a special firmware (carl9170-1.fw), which can be downloaded
+ from our wiki here:
  
 
  If you choose to build a module, it'll be called carl9170.
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] carl9170: Clarify kconfig text

2016-04-16 Thread Lauri Kasanen
The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.

After the removal of the older staging driver, this is the only
driver in mainline for these devices.

Signed-off-by: Lauri Kasanen 
---
 drivers/net/wireless/ath/carl9170/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..f3e3222 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -5,7 +5,7 @@ config CARL9170
select FW_LOADER
select CRC32
help
- This is another driver for the Atheros "otus" 802.11n USB devices.
+ This is the mainline driver for the Atheros "otus" 802.11n USB 
devices.
 
  This driver provides more features than the original,
  but it needs a special firmware (carl9170-1.fw) to do that.
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/8] brcmfmac: insert default boardrev in nvram data if missing

2016-04-16 Thread Rafał Miłecki
On 11 April 2016 at 11:35, Arend van Spriel  wrote:
> From: Hante Meuleman 
>
> Some nvram files/stores come without the boardrev information,
> but firmware requires this to be set. When not found in nvram then
> add a default boardrev string to the nvram data.
>
> Reported-by: Rafal Milecki 
> Reviewed-by: Arend Van Spriel 
> Reviewed-by: Franky (Zhenhui) Lin 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Hante Meuleman 
> Signed-off-by: Arend van Spriel 

I needed to wait for a weekend to give it a try. It fixed my problem,
nice work, thanks!
Tested-by: Rafal Milecki 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

2016-04-16 Thread Oleksij Rempel
Am 15.04.2016 um 22:59 schrieb Bob Copeland:
> On Tue, Apr 12, 2016 at 07:37:44PM +0200, Oleksij Rempel wrote:
>> by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
>> mask_m & mask_p initialisation. This coused a performance regression
>> on ar9281.
>>
>> Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common 
>> code in ar9002_hw_spur_mitigate.")
>> Reported-by: Gustav Frederiksen 
>> Tested-by: Gustav Frederiksen 
>> Signed-off-by: Oleksij Rempel 
>> ---
>>  drivers/net/wireless/ath/ath9k/ar5008_phy.c | 8 +++-
>>  drivers/net/wireless/ath/ath9k/ar9002_phy.c | 5 -
>>  2 files changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c 
>> b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> index 8f87930..1b271b9 100644
>> --- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> +++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
>> @@ -274,6 +274,9 @@ void ar5008_hw_cmn_spur_mitigate(struct ath_hw *ah,
>>  };
>>  static const int inc[4] = { 0, 100, 0, 0 };
>>  
>> +memset(_m, 0, sizeof(int8_t) * 123);
>> +memset(_p, 0, sizeof(int8_t) * 123);
>> +
> 
> For a future patch, "sizeof(mask_m)" or even just:
> 
> u8 mask_m[123] = {0};
> 
> ... would be better here.  I looked at this bit and thought, no way is
> "123" actually correct.  Lo and behold, that is actually the number of
> array elements, whether that has a basis in something real or not :)

If you already on it can you please rework it on top of this patch?
This complete function can be probably reworked.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature