Re: [PATCH v3 3/4] ipv6: add option to drop unicast encapsulated in L2 multicast

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Feb 2016 13:31:19 +0100

> From: Johannes Berg 
> 
> In order to solve a problem with 802.11, the so-called hole-196 attack,
> add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
> enabled, causes the stack to drop IPv6 unicast packets encapsulated in
> link-layer multi- or broadcast frames. Such frames can (as an attack)
> be created by any member of the same wireless network and transmitted
> as valid encrypted frames since the symmetric key for broadcast frames
> is shared between all stations.
> 
> Reviewed-by: Julian Anastasov 
> Signed-off-by: Johannes Berg 

Applied.
--
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 v3 2/4] ipv4: add option to drop gratuitous ARP packets

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Feb 2016 13:31:18 +0100

> From: Johannes Berg 
> 
> In certain 802.11 wireless deployments, there will be ARP proxies
> that use knowledge of the network to correctly answer requests.
> To prevent gratuitous ARP frames on the shared medium from being
> a problem, on such deployments wireless needs to drop them.
> 
> Enable this by providing an option called "drop_gratuitous_arp".
> 
> Signed-off-by: Johannes Berg 

Applied.
--
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 v3 4/4] ipv6: add option to drop unsolicited neighbor advertisements

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Feb 2016 13:31:20 +0100

> From: Johannes Berg 
> 
> In certain 802.11 wireless deployments, there will be NA proxies
> that use knowledge of the network to correctly answer requests.
> To prevent unsolicitd advertisements on the shared medium from
> being a problem, on such deployments wireless needs to drop them.
> 
> Enable this by providing an option called "drop_unsolicited_na".
> 
> Signed-off-by: Johannes Berg 

Applied.
--
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 v3 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Feb 2016 13:31:17 +0100

> From: Johannes Berg 
> 
> In order to solve a problem with 802.11, the so-called hole-196 attack,
> add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
> enabled, causes the stack to drop IPv4 unicast packets encapsulated in
> link-layer multi- or broadcast frames. Such frames can (as an attack)
> be created by any member of the same wireless network and transmitted
> as valid encrypted frames since the symmetric key for broadcast frames
> is shared between all stations.
> 
> Additionally, enabling this option provides compliance with a SHOULD
> clause of RFC 1122.
> 
> Reviewed-by: Julian Anastasov 
> Signed-off-by: Johannes Berg 

Applied.
--
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 1/3] mwifiex: Fixed incorrect indentation issue

[Kalle Valo]

Ujjal Roy  writes:

> This patch fixes the incorrect indentation of the case label.
>
> Signed-off-by: Ujjal Roy 

A changelog is always recommended to have. Also for some reason your
name in patchwork is all caps:

Submitter   UJJAL ROY

https://patchwork.kernel.org/patch/8276851/

Please try to fix that, but I don't know if that's even possible.

-- 
Kalle Valo
--
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 2/2] ath10k: process htt rx indication as batch mode

[Rajkumar Manoharan]

On multicore systems, it is possible that txrx tasket can run
in parallel with pci tasklet (i.e smp affinity of ath10k irq is
assigned to multiple CPUs). Feeding and consuming from the same
rx completion list leads to txrx tasklet runs for longer period.
Prevent this by processing a snapshot of rx queue by moving list
into temporary list. Consecutive received frames will be processed
in next batch.

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index bedd8c3..61d9507 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2155,22 +2155,34 @@ static void ath10k_htt_txrx_compl_task(unsigned long 
ptr)
struct ath10k_htt *htt = (struct ath10k_htt *)ptr;
struct ath10k *ar = htt->ar;
struct sk_buff_head tx_q;
+   struct sk_buff_head rx_q;
+   struct sk_buff_head rx_ind_q;
struct htt_resp *resp;
struct sk_buff *skb;
unsigned long flags;
 
__skb_queue_head_init(_q);
+   __skb_queue_head_init(_q);
+   __skb_queue_head_init(_ind_q);
 
spin_lock_irqsave(>tx_compl_q.lock, flags);
skb_queue_splice_init(>tx_compl_q, _q);
spin_unlock_irqrestore(>tx_compl_q.lock, flags);
 
+   spin_lock_irqsave(>rx_compl_q.lock, flags);
+   skb_queue_splice_init(>rx_compl_q, _q);
+   spin_unlock_irqrestore(>rx_compl_q.lock, flags);
+
+   spin_lock_irqsave(>rx_in_ord_compl_q.lock, flags);
+   skb_queue_splice_init(>rx_in_ord_compl_q, _ind_q);
+   spin_unlock_irqrestore(>rx_in_ord_compl_q.lock, flags);
+
while ((skb = __skb_dequeue(_q))) {
ath10k_htt_rx_frm_tx_compl(htt->ar, skb);
dev_kfree_skb_any(skb);
}
 
-   while ((skb = skb_dequeue(>rx_compl_q))) {
+   while ((skb = __skb_dequeue(_q))) {
resp = (struct htt_resp *)skb->data;
spin_lock_bh(>rx_ring.lock);
ath10k_htt_rx_handler(htt, >rx_ind);
@@ -2178,7 +2190,7 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
dev_kfree_skb_any(skb);
}
 
-   while ((skb = skb_dequeue(>rx_in_ord_compl_q))) {
+   while ((skb = __skb_dequeue(_ind_q))) {
spin_lock_bh(>rx_ring.lock);
ath10k_htt_rx_in_ord_ind(ar, skb);
spin_unlock_bh(>rx_ring.lock);
-- 
2.7.0

--
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 1/2] ath10k: reduce rx_lock contention for htt rx indication

[Rajkumar Manoharan]

Received frame indications are queued into a skb list and latest
processed by txrx tasklet. This skb queue is protected by htt rx lock.
Since the entire rx processing till delivering frame to mac80211 and
replenish tasks are processed under rx_lock protection, there might be
some delay in queuing newly received rx frame into that list on
multicore systems. Optimize this by using skb list lock while accessing
rx completion queue instead of htt rx lock.

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cc957a6..bedd8c3 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2011,9 +2011,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct 
sk_buff *skb)
break;
}
case HTT_T2H_MSG_TYPE_RX_IND:
-   spin_lock_bh(>rx_ring.lock);
-   __skb_queue_tail(>rx_compl_q, skb);
-   spin_unlock_bh(>rx_ring.lock);
+   skb_queue_tail(>rx_compl_q, skb);
tasklet_schedule(>txrx_compl_task);
return;
case HTT_T2H_MSG_TYPE_PEER_MAP: {
@@ -2111,9 +2109,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct 
sk_buff *skb)
break;
}
case HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND: {
-   spin_lock_bh(>rx_ring.lock);
-   __skb_queue_tail(>rx_in_ord_compl_q, skb);
-   spin_unlock_bh(>rx_ring.lock);
+   skb_queue_tail(>rx_in_ord_compl_q, skb);
tasklet_schedule(>txrx_compl_task);
return;
}
@@ -2174,16 +2170,18 @@ static void ath10k_htt_txrx_compl_task(unsigned long 
ptr)
dev_kfree_skb_any(skb);
}
 
-   spin_lock_bh(>rx_ring.lock);
-   while ((skb = __skb_dequeue(>rx_compl_q))) {
+   while ((skb = skb_dequeue(>rx_compl_q))) {
resp = (struct htt_resp *)skb->data;
+   spin_lock_bh(>rx_ring.lock);
ath10k_htt_rx_handler(htt, >rx_ind);
+   spin_unlock_bh(>rx_ring.lock);
dev_kfree_skb_any(skb);
}
 
-   while ((skb = __skb_dequeue(>rx_in_ord_compl_q))) {
+   while ((skb = skb_dequeue(>rx_in_ord_compl_q))) {
+   spin_lock_bh(>rx_ring.lock);
ath10k_htt_rx_in_ord_ind(ar, skb);
+   spin_unlock_bh(>rx_ring.lock);
dev_kfree_skb_any(skb);
}
-   spin_unlock_bh(>rx_ring.lock);
 }
-- 
2.7.0

--
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 1/3] mwifiex: Fixed incorrect indentation issue

[Ujjal Roy]

On Thu, Feb 11, 2016 at 3:05 PM, Kalle Valo  wrote:
> Ujjal Roy  writes:
>
>> This patch fixes the incorrect indentation of the case label.
>>
>> Signed-off-by: Ujjal Roy 
>
> A changelog is always recommended to have. Also for some reason your
> name in patchwork is all caps:
>
> Submitter   UJJAL ROY
>
> https://patchwork.kernel.org/patch/8276851/
>
> Please try to fix that, but I don't know if that's even possible.
>
> --
> Kalle Valo

I checked that and unable to change the name. If you have any
suggestion please share with me.

Thanks,
UjjaL Roy
--
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] codel: add forgotten inline to functions in header file

[Grumbach, Emmanuel]

fixing linux-wireless address ...

On 02/11/2016 04:30 PM, Eric Dumazet wrote:
> On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote:
>> Signed-off-by: Emmanuel Grumbach 
>> ---
>> -static bool codel_should_drop(const struct sk_buff *skb,
>> -  struct Qdisc *sch,
>> -  struct codel_vars *vars,
>> -  struct codel_params *params,
>> -  struct codel_stats *stats,
>> -  codel_time_t now)
>> +static inline bool codel_should_drop(const struct sk_buff *skb,
>> + struct Qdisc *sch,
>> + struct codel_vars *vars,
>> + struct codel_params *params,
>> + struct codel_stats *stats,
>> + codel_time_t now)
>
> The lack of inline was done on purpose.
>
> This include file is kind of special, being included by codel and
> fq_codel.
>
> Hint : we do not want to force the compiler to inline
> codel_should_drop() (or any other function).
>
>
> See this file as if it was a .c really.
>
>

Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
codel_get_time and associated utils (_before, _after) in iwlwifi.
They're better than jiffies... So maybe I can just copy that code to
iwlwifi.
--
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] codel: add forgotten inline to functions in header file

[Eric Dumazet]

On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote:


> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
> codel_get_time and associated utils (_before, _after) in iwlwifi.
> They're better than jiffies... So maybe I can just copy that code to
> iwlwifi.


You certainly can submit a patch adding the inline, but not on all
functions present in this file ;)

Thanks !


--
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] mac80211: fix wiphy supported_band access

[Sven Eckelmann]

On Wednesday 10 February 2016 16:08:17 Lorenzo Bianconi wrote:
> Fix wiphy supported_band access in tx radiotap parsing. In particular,
> info->band is always set to 0 (IEEE80211_BAND_2GHZ) since it has not
> assigned yet. This cause a kernel crash on 5GHz only devices.
> Move ieee80211_parse_tx_radiotap() after info->band assignment
> 
> Signed-off-by: Lorenzo Bianconi 

Thanks for the patch. I really never tested with 5GHz only cards and
forgot to check when info->band is assigned.

Can you please add a line describing which patch this one fixes (I hope
the ids are stable in this tree):

Fixes: 5ec3aed9ba4c ("mac80211: Parse legacy and HT rate in injected frames")

And btw., I am happy about the VHT patches. I should really get some MT76
compatible hardware to test how well AC works with a less annoying firmware.


@Felix, I saw that you've added the original patch to OpenWrt. Can you also
check this patch and maybe add it as fix for OpenWrt? Thanks

Kind regards,
Sven


> ---
>  net/mac80211/tx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 7bb67fa..b07d037 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1892,10 +1892,6 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct 
> sk_buff *skb,
>   info->flags = IEEE80211_TX_CTL_REQ_TX_STATUS |
> IEEE80211_TX_CTL_INJECTED;
>  
> - /* process and remove the injection radiotap header */
> - if (!ieee80211_parse_tx_radiotap(local, skb))
> - goto fail;
> -
>   rcu_read_lock();
>  
>   /*
> @@ -1957,6 +1953,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct 
> sk_buff *skb,
>   goto fail_rcu;
>  
>   info->band = chandef->chan->band;
> + /* process and remove the injection radiotap header */
> + if (!ieee80211_parse_tx_radiotap(local, skb))
> + goto fail_rcu;
> +
>   ieee80211_xmit(sdata, NULL, skb);
>   rcu_read_unlock();
>  
> 


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] codel: add forgotten inline to functions in header file

[Grumbach, Emmanuel]

On 02/11/2016 05:12 PM, Eric Dumazet wrote:
> On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote:
>
>
>> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
>> codel_get_time and associated utils (_before, _after) in iwlwifi.
>> They're better than jiffies... So maybe I can just copy that code to
>> iwlwifi.
>
> You certainly can submit a patch adding the inline, but not on all
> functions present in this file ;)
>
> Thanks !
>

Actually... All I need *has* the inline, but if I include codel.h,
codel_dequeue is defined but not used and you definitely don't want to
inline that one. So I guess the only other option I have is to split
that header file which I don't think is really worth it. So, unless you
object it, I'll just copy the code.

--
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] codel: add forgotten inline to functions in header file

[Dave Taht]

On Thu, Feb 11, 2016 at 7:05 AM, Grumbach, Emmanuel
 wrote:
> fixing linux-wireless address ...
>
> On 02/11/2016 04:30 PM, Eric Dumazet wrote:
>> On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote:
>>> Signed-off-by: Emmanuel Grumbach 
>>> ---
>>> -static bool codel_should_drop(const struct sk_buff *skb,
>>> -  struct Qdisc *sch,
>>> -  struct codel_vars *vars,
>>> -  struct codel_params *params,
>>> -  struct codel_stats *stats,
>>> -  codel_time_t now)
>>> +static inline bool codel_should_drop(const struct sk_buff *skb,
>>> + struct Qdisc *sch,
>>> + struct codel_vars *vars,
>>> + struct codel_params *params,
>>> + struct codel_stats *stats,
>>> + codel_time_t now)
>>
>> The lack of inline was done on purpose.
>>
>> This include file is kind of special, being included by codel and
>> fq_codel.
>>
>> Hint : we do not want to force the compiler to inline
>> codel_should_drop() (or any other function).
>>
>>
>> See this file as if it was a .c really.
>>
>>
>
> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
> codel_get_time and associated utils (_before, _after) in iwlwifi.
> They're better than jiffies... So maybe I can just copy that code to
> iwlwifi.

I need to stress that codel as is is not the right thing for wifi,
particularly point to multipoint wifi in highly contended scenarios.
It IS a starting point. We have generally felt that the target needs
to be offset against the actual service opportunities, and the effects
of multicast (with powersave) and other "background" frames, needs to
be smoothed out.

Lacking hardware that can do that, or adaquate sims, has stalled
trying to come up with "the right thing". It looks like you are
putting in place more of the pieces to get there in some tree
somewhere?
--
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] codel: add forgotten inline to functions in header file

[Dave Taht]

On Thu, Feb 11, 2016 at 7:29 AM, Grumbach, Emmanuel
 wrote:
>
>
> On 02/11/2016 05:12 PM, Eric Dumazet wrote:
>> On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote:
>>
>>
>>> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the
>>> codel_get_time and associated utils (_before, _after) in iwlwifi.
>>> They're better than jiffies... So maybe I can just copy that code to
>>> iwlwifi.

Definately better than jiffies.

>>
>> You certainly can submit a patch adding the inline, but not on all
>> functions present in this file ;)
>>
>> Thanks !
>>
>
> Actually... All I need *has* the inline, but if I include codel.h,
> codel_dequeue is defined but not used and you definitely don't want to
> inline that one. So I guess the only other option I have is to split
> that header file which I don't think is really worth it. So, unless you
> object it, I'll just copy the code.

I think it is best to start with another base implementation of codel
for wifi, yes.

What I think is the currently best performing codel implementation (on
the wire, for ethernet) we have is in:

https://github.com/dtaht/bcake/codel5.h

which has a few differences from eric's implementation (64 bit
timestamps, inlining, not a lot of cpu profiling on it - still aiming
for algorithmic correctness here, it is closer to the original
paper... We'd used a different means of injecting the callback in it,
too)

The one currently in the main cake had issues in the last test round
but has been updated since. (sch_cake is also on github).

In neither case it is the right thing for wifi either.

the "starting plan" such as it was was to get to "one aggregate in the
hardware, one in the driver, one ready to be formed on the completion
interrupt", and pull a smoothed service time from start to completion
interrupt to dynamically modify the codel target. (other headaches,
like multicast, abound).

(It's the per station queue + fq as close to the hardware as possible
that matters most, IMHO.)

>
> --
> 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
--
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

Rate Control Tuning/Information

[Todd Efflam]

Hello,
We're currently trying to tune the rate control algorithm (minstrel)
with our video encoding quality.  We're using a udp network so ideally
the two will match up and we won't be trying to encode at too high of
a quality when our data rate is decreased.

In doing so, I have a couple of questions:
a) Is it possible to change the timing between rate changes?  We'd
like to not change in the middle of encoding a video frame and give
our encoding enough time to create a frame that will fit in the
current data rate.
b) Is there a better way to get the current data rate than using
iwconfig?  Or possibly an interrupt for when the data rate is changed
so we can change our encoding quality to match it as soon as possible?
c) If the above aren't possible, is the best way to manually change
the data rate by configuring the kernel to not use rate control and
send rate change requests via something like "echo 'index' >
/sys/kernel/debug/ieee80211/phy0/rc/fixed_rate_idx" (posted here:
http://unix.stackexchange.com/questions/182520/disable-rate-control-in-linux-wireless-driver).

Any advice is appreciated!  Thank you.

Best,
Todd
--
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] ath10k: fix erroneous return value

[Julian Calaby]

Hi All,

On Thu, Feb 11, 2016 at 3:58 AM, Anton Protopopov
 wrote:
> The ath10k_pci_hif_exchange_bmi_msg() function may return the positive
> value EIO instead of -EIO in case of error.
>
> Signed-off-by: Anton Protopopov 

This looks right to me.

Reviewed-by: Julian Calaby 

> ---
>  drivers/net/wireless/ath/ath10k/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
> b/drivers/net/wireless/ath/ath10k/pci.c
> index ee925c6..526acde 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1756,7 +1756,7 @@ static int ath10k_pci_hif_exchange_bmi_msg(struct 
> ath10k *ar,
> DMA_FROM_DEVICE);
> ret = dma_mapping_error(ar->dev, resp_paddr);
> if (ret) {
> -   ret = EIO;
> +   ret = -EIO;
> goto err_req;
> }
>
> --
> 2.6.5
>
> --
> 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



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 2/4] rtlwifi: rtl8192de: Convert driver to use common 5G channels

[Larry Finger]

This driver defines its owh copy of the 5G channels. Change it to use
the common definitions.

Signed-off-by: Larry Finger 
---

Kalle,

This material is for kernel 4.6.

Larry

 .../net/wireless/realtek/rtlwifi/rtl8192de/phy.c   | 23 --
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
index bb06fe8..7810fe8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c
@@ -924,19 +924,11 @@ static void _rtl92d_ccxpower_index_check(struct 
ieee80211_hw *hw,
 
 static u8 _rtl92c_phy_get_rightchnlplace(u8 chnl)
 {
-   u8 channel_5g[59] = {
-   1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58,
-   60, 62, 64, 100, 102, 104, 106, 108, 110, 112,
-   114, 116, 118, 120, 122, 124, 126, 128,
-   130, 132, 134, 136, 138, 140, 149, 151,
-   153, 155, 157, 159, 161, 163, 165
-   };
u8 place = chnl;
 
if (chnl > 14) {
-   for (place = 14; place < sizeof(channel_5g); place++) {
-   if (channel_5g[place] == chnl) {
+   for (place = 14; place < sizeof(channel5g); place++) {
+   if (channel5g[place] == chnl) {
place++;
break;
}
@@ -2471,16 +2463,9 @@ static bool _rtl92d_is_legal_5g_channel(struct 
ieee80211_hw *hw, u8 channel)
 {
 
int i;
-   u8 channel_5g[45] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58,
-   60, 62, 64, 100, 102, 104, 106, 108, 110, 112,
-   114, 116, 118, 120, 122, 124, 126, 128, 130, 132,
-   134, 136, 138, 140, 149, 151, 153, 155, 157, 159,
-   161, 163, 165
-   };
 
-   for (i = 0; i < sizeof(channel_5g); i++)
-   if (channel == channel_5g[i])
+   for (i = 0; i < sizeof(channel5g); i++)
+   if (channel == channel5g[i])
return true;
return false;
 }
-- 
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

[PATCH 4/4] rtlwifi: rtl8821ae: Convert driver to use common 5G channel table

[Larry Finger]

There are several copies of the 5G channel tables in this driver. These
are removed so that the tables in the core will be used. This change
also removes a useless message of "Channel 163 in Group not found".

The number of possible 5G channels was reduced from 54 to a better
value of 49 during the conversion.

Signed-off-by: Larry Finger 
---

Kalle,

This material is for kernel 4.6.

Larry

 .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c| 18 ---
 .../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c   | 27 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h|  2 +-
 3 files changed, 7 insertions(+), 40 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index bbb789f..5da9bd0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -2786,14 +2786,6 @@ static void 
_rtl8812ae_read_txpower_info_from_hwpg(struct ieee80211_hw *hw,
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct txpower_info_2g pwrinfo24g;
struct txpower_info_5g pwrinfo5g;
-   u8 channel5g[CHANNEL_MAX_NUMBER_5G] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54,
-   56, 58, 60, 62, 64, 100, 102, 104, 106,
-   108, 110, 112, 114, 116, 118, 120, 122,
-   124, 126, 128, 130, 132, 134, 136, 138,
-   140, 142, 144, 149, 151, 153, 155, 157,
-   159, 161, 163, 165, 167, 168, 169, 171, 173, 175, 177};
-   u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M] = {42, 58, 106, 122, 138, 
155, 171};
u8 rf_path, index;
u8 i;
 
@@ -2872,16 +2864,6 @@ static void 
_rtl8821ae_read_txpower_info_from_hwpg(struct ieee80211_hw *hw,
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct txpower_info_2g pwrinfo24g;
struct txpower_info_5g pwrinfo5g;
-   u8 channel5g[CHANNEL_MAX_NUMBER_5G] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54,
-   56, 58, 60, 62, 64, 100, 102, 104, 106,
-   108, 110, 112, 114, 116, 118, 120, 122,
-   124, 126, 128, 130, 132, 134, 136, 138,
-   140, 142, 144, 149, 151, 153, 155, 157,
-   159, 161, 163, 165, 167, 168, 169, 171,
-   173, 175, 177};
-   u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M] = {
-   42, 58, 106, 122, 138, 155, 171};
u8 rf_path, index;
u8 i;
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index 9b4d8a6..74165b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -1472,18 +1472,13 @@ static char 
_rtl8812ae_phy_get_chnl_idx_of_txpwr_lmt(struct ieee80211_hw *hw,
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
char channel_index = -1;
-   u8 channel_5g[CHANNEL_MAX_NUMBER_5G] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64,
-   100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122,
-   124, 126, 128, 130, 132, 134, 136, 138, 140, 142, 144, 149,
-   151, 153, 155, 157, 159, 161, 163, 165, 167, 168, 169, 171,
-   173, 175, 177};
u8  i = 0;
+
if (band == BAND_ON_2_4G)
channel_index = channel - 1;
else if (band == BAND_ON_5G) {
-   for (i = 0; i < sizeof(channel_5g)/sizeof(u8); ++i) {
-   if (channel_5g[i] == channel)
+   for (i = 0; i < sizeof(channel5g)/sizeof(u8); ++i) {
+   if (channel5g[i] == channel)
channel_index = i;
}
} else
@@ -2240,13 +2235,6 @@ void rtl8821ae_phy_get_txpower_level(struct ieee80211_hw 
*hw, long *powerlevel)
 
 static bool _rtl8821ae_phy_get_chnl_index(u8 channel, u8 *chnl_index)
 {
-   u8 channel_5g[CHANNEL_MAX_NUMBER_5G] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,
-   64, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118,
-   120, 122, 124, 126, 128, 130, 132, 134, 136, 138, 140,
-   142, 144, 149, 151, 153, 155, 157, 159, 161, 163, 165,
-   167, 168, 169, 171, 173, 175, 177
-   };
u8 i = 0;
bool in_24g = true;
 
@@ -2257,7 +2245,7 @@ static bool _rtl8821ae_phy_get_chnl_index(u8 channel, u8 
*chnl_index)
in_24g = false;
 
for (i = 0; i < CHANNEL_MAX_NUMBER_5G; ++i) {
-   if (channel_5g[i] == channel) {
+   if (channel5g[i] == channel) {
*chnl_index = i;
return in_24g;
}
@@ -2728,13 +2716,10 @@ static u8 _rtl8821ae_get_txpower_index(struct 
ieee80211_hw *hw, u8 

[PATCH 3/4] rtlwifi: rtl8192ee: Convert driver to use new 5G channel tables

[Larry Finger]

The driver defines its own set of channel tables for the 5G band. With
this change, it will use those of the core.

Signed-off-by: Larry Finger 
---

Kalle,

This material is for kernel 4.6.

Larry

 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
index 5f14308..9fd3f1b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c
@@ -2018,18 +2018,6 @@ static void _rtl92ee_read_txpower_info_from_hwpg(struct 
ieee80211_hw *hw,
struct rtl_efuse *efu = rtl_efuse(rtl_priv(hw));
struct txpower_info_2g pwr2g;
struct txpower_info_5g pwr5g;
-   u8 channel5g[CHANNEL_MAX_NUMBER_5G] = {
-   36, 38, 40, 42, 44, 46, 48, 50, 52, 54,
-   56, 58, 60, 62, 64, 100, 102, 104, 106,
-   108, 110, 112, 114, 116, 118, 120, 122,
-   124, 126, 128, 130, 132, 134, 136, 138,
-   140, 142, 144, 149, 151, 153, 155, 157,
-   159, 161, 163, 165, 167, 168, 169, 171,
-   173, 175, 177
-   };
-   u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M] = {
-   42, 58, 106, 122, 138, 155, 171
-   };
u8 rf, idx;
u8 i;
 
-- 
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

[PATCH] rtlwifi: rtl8821ae: Silence useless log output

[Larry Finger]

When driver rtl8821ae is loaded but not connected to any AP, it logs
a "firmware not ready to run" message roughly once a minute. To
eliminate logging this massage under normal debug conditions, the
degug level needed to print this message is increased.

Signed-off-by: Larry Finger 
---

Kalle,

This patch is intended for kernel 4.6.

Signed-off-by: Larry Finger 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
index 525eb23..a4fc70e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c
@@ -271,7 +271,7 @@ int rtl8821ae_download_fw(struct ieee80211_hw *hw, bool 
buse_wake_on_wlan_fw)
 
err = _rtl8821ae_fw_free_to_go(hw);
if (err) {
-   RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
+   RT_TRACE(rtlpriv, COMP_ERR, DBG_DMESG,
 "Firmware is not ready to run!\n");
} else {
RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD,
-- 
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

[PATCH 1/4] rtlwifi: Prepare for reworking 5G channels

[Larry Finger]

There are 3 drivers in this family that have 5G radios. Each of them
defines local copies of the available channels. This patch adds the
two arrays to the core driver.

Signed-off-by: Larry Finger 
---

Kalle,

This material is for kernel 4.6.

Larry

 drivers/net/wireless/realtek/rtlwifi/core.c | 16 
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  9 -
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c 
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 4ae421e..02eba0e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -35,6 +35,22 @@
 #include 
 #include 
 
+u8 channel5g[CHANNEL_MAX_NUMBER_5G] = {
+   36, 38, 40, 42, 44, 46, 48, /* Band 1 */
+   52, 54, 56, 58, 60, 62, 64, /* Band 2 */
+   100, 102, 104, 106, 108, 110, 112,  /* Band 3 */
+   116, 118, 120, 122, 124, 126, 128,  /* Band 3 */
+   132, 134, 136, 138, 140, 142, 144,  /* Band 3 */
+   149, 151, 153, 155, 157, 159, 161,  /* Band 4 */
+   165, 167, 169, 171, 173, 175, 177   /* Band 4 */
+};
+EXPORT_SYMBOL(channel5g);
+
+u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M] = {
+   42, 58, 106, 122, 138, 155, 171
+};
+EXPORT_SYMBOL(channel5g_80m);
+
 void rtl_addr_delay(u32 addr)
 {
if (addr == 0xfe)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 4544752..e603819 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -122,11 +122,6 @@
*/
 #define CHANNEL_MAX_NUMBER_5G_80M  7
 #define CHANNEL_GROUP_MAX  (3 + 9) /*  ch1~3, 4~9, 10~14 = three groups */
-#define CHANNEL_MAX_NUMBER_5G  54 /* Please refer to
-   *"phy_GetChnlGroup8812A" and
-   * "Hal_ReadTxPowerInfo8812A"
-   */
-#define CHANNEL_MAX_NUMBER_5G_80M  7
 #define MAX_PG_GROUP   13
 #defineCHANNEL_GROUP_MAX_2G3
 #defineCHANNEL_GROUP_IDX_5GL   3
@@ -2904,6 +2899,10 @@ value to host byte ordering.*/
 #defineSTBC_VHT_TEST_TX_ENABLE BIT(2)
 #defineSTBC_VHT_CAP_TX BIT(3)
 
+extern u8 channel5g[CHANNEL_MAX_NUMBER_5G];
+
+extern u8 channel5g_80m[CHANNEL_MAX_NUMBER_5G_80M];
+
 static inline u8 rtl_read_byte(struct rtl_priv *rtlpriv, u32 addr)
 {
return rtlpriv->io.read8_sync(rtlpriv, addr);
-- 
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

[PATCH 0/4] rtlwifi: Rework 5G channel arrays

[Larry Finger]

Several of the rtlwifi drivers have separate definitions of the 5D channel
arrays. This patch set replaces 5 separate instances with a single one in the
common header.

These patches also eliminate spurious messages 
"rtl8821ae:_rtl8821ae_get_chnl_group():
5G, Channel 163 in Group not found" from rtl8821ae.

This material is for kernel 4.6.

Signed-off-by: Larry Finger 


Larry Finger (4):
  rtlwifi: Prepare for reworking 5G channels
  rtlwifi: rtl8192de: Convert driver to use common 5G channels
  rtlwifi: rtl8192ee: Convert driver to use new 5G channel tables
  rtlwifi: rtl8821ae: Convert driver to use common 5G channel table

 drivers/net/wireless/realtek/rtlwifi/core.c| 16 +
 .../net/wireless/realtek/rtlwifi/rtl8192de/phy.c   | 23 --
 .../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c| 12 --
 .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c| 18 ---
 .../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c   | 27 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h| 11 -
 6 files changed, 31 insertions(+), 76 deletions(-)

-- 
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