Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: maowenan @ 2019-02-18 14:04 UTC (permalink / raw)
  To: Kalle Valo; +Cc: johannes, linux-wireless, kernel-janitors, netdev
In-Reply-To: <878sydus0p.fsf@kamboji.qca.qualcomm.com>



On 2019/2/18 21:48, Kalle Valo wrote:
> maowenan <maowenan@huawei.com> writes:
> 
>> Add kalle Valo in mail list.
>>
>> Hi Kalle Valo,
>> Do you have any comments about this patch?
> 
> Why do you ask me? Johannes maintains cfg80211, not me, and he will
> provide comments once he reviews the patch (which might take some time,
> we do have other tasks as well).

I'm sorry for this, my mistake to add wrong maintainer.

> 


^ permalink raw reply

* Re: [BUG] mt76x0u: Probing issues on Raspberry Pi 3 B+
From: Stanislaw Gruszka @ 2019-02-18 13:52 UTC (permalink / raw)
  To: Stefan Wahren
  Cc: Lorenzo Bianconi, Alan Stern, Felix Fietkau, Doug Anderson,
	Minas Harutyunyan, USB list, linux-wireless
In-Reply-To: <2009016263.528260.1550344627996@email.ionos.de>

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]

On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> this is a misunderstanding. The warning is about memory alignment to 32 bit addresses, not about page alignment. This is a typical ARM restriction. Maybe we need to make sure in mt76 that the DMA buffer needs to be aligned. But it's also possible that the warning isn't the root cause of our problem.
> 

I see, it needs 4 bytes alignment . There is already dwc2 code checks
that and allocate new buffer if the alignment is not right:
dwc2_alloc_dma_aligned_buffer(), but it does nothing if urb->sg
is not NULL. I thought mt76usb already provide aligned buffers, but
looks it does not for one TX special case, which are PROBE REQUEST
frames. Other frames are aligned by inserting L2 header pad. One
solution for this would be just submit urb with  NULL sg (same as
Lorenzo's patches do, but still allocating buffers via buf->sg),
but I think, you have right, we should provide 4 bytes aligned buffers
by default as other DMA hardware may require that. I'm attaching yet
another patch to test, which fix up alignment for PROBE REQUEST frames.

> > Attached patch should fix this, plese test, thanks in advance.
> 
> Anyway i tested the following patch combinations against next with the same results as 1,2,3 (no wifi, alignment warning):
> 1,3
> 1,2,3,4

I noticed on my setup that patch 4 can cause troubles, but still
device is workable here on my PC machines.

> > > Btw i can confirm a regression was introduced after 4.19, because in 4.19 there was no firmware timeout but even no working wifi:
> > 
> > You ment 'no working wifi' or 'working wifi'?
> 
> Wifi is broken in 4.19, 4.20, 5.0 and next. It only worked with Lorenzo's SG avoid patches so far. Btw the regression (firmware timeout) started in 4.20. I also tested it today.

That somewhat strange because 4.19 mt76x0u does not use SG.
On 4.19 there is phy calibration bug fixed in 4.19.5:

commit 0d9813319b40399a0d8fd761d2fcfedee5701487
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Fri Sep 7 23:13:12 2018 +0200

    mt76x0: run vco calibration for each channel configuration

It's possible that without this vco calibration fix, MT7610U device
does not see AP if it's signal is weak.

Stanislaw


[-- Attachment #2: 0005-mt76x02-make-sure-probe-request-skb-s-are-4-bytes-al.patch --]
[-- Type: text/plain, Size: 4576 bytes --]

From d420961afd1ae2ca8590ee2c79defc0a48fa8e73 Mon Sep 17 00:00:00 2001
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 18 Feb 2019 14:39:38 +0100
Subject: [PATCH] mt76x02: make sure probe request skb's are 4 bytes aligned

We add 2 bytes header pad if header length is not multiple of 4 bytes,
this assure most tx skb buffers are 4 bytes aligned. But this is not
true for probe request frames which have n*4 bytes header length and
are not aligned.

I think is ok to assume that frames have to be 4 bytes aligned
for DMA purpose, so mt76 driver should take care of that.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
 drivers/net/wireless/mediatek/mt76/mt76x02.h       |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c  |  5 +---
 .../net/wireless/mediatek/mt76/mt76x02_usb_core.c  |  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x02_util.c  | 32 +++++++++++++++-------
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02.h b/drivers/net/wireless/mediatek/mt76/mt76x02.h
index 6d96766a6ed3..ad329db7de4e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02.h
@@ -155,7 +155,7 @@ void mt76x02_set_tx_ackto(struct mt76x02_dev *dev);
 void mt76x02_set_coverage_class(struct ieee80211_hw *hw,
 				s16 coverage_class);
 int mt76x02_set_rts_threshold(struct ieee80211_hw *hw, u32 val);
-int mt76x02_insert_hdr_pad(struct sk_buff *skb);
+void mt76x02_align_skb(struct sk_buff *skb);
 void mt76x02_remove_hdr_pad(struct sk_buff *skb, int len);
 bool mt76x02_tx_status_data(struct mt76_dev *mdev, u8 *update);
 void mt76x02_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c b/drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c
index a5413a309a0a..63c5520a65ca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c
@@ -163,7 +163,6 @@ int mt76x02_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
 	struct mt76x02_txwi *txwi = txwi_ptr;
 	int qsel = MT_QSEL_EDCA;
 	int pid;
-	int ret;
 
 	if (q == &dev->mt76.q_tx[MT_TXQ_PSD] && wcid && wcid->idx < 128)
 		mt76x02_mac_wcid_set_drop(dev, wcid->idx, false);
@@ -173,9 +172,7 @@ int mt76x02_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
 	pid = mt76_tx_status_skb_add(mdev, wcid, skb);
 	txwi->pktid = pid;
 
-	ret = mt76x02_insert_hdr_pad(skb);
-	if (ret < 0)
-		return ret;
+	mt76x02_align_skb(skb);
 
 	if (pid >= MT_PACKET_ID_FIRST)
 		qsel = MT_QSEL_MGMT;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
index 098d05e109e7..bd5838c26f43 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c
@@ -79,7 +79,7 @@ int mt76x02u_tx_prepare_skb(struct mt76_dev *mdev, void *data,
 	u32 flags;
 	int pid;
 
-	mt76x02_insert_hdr_pad(skb);
+	mt76x02_align_skb(skb);
 
 	txwi = skb_push(skb, sizeof(struct mt76x02_txwi));
 	mt76x02_mac_write_txwi(dev, txwi, skb, wcid, sta, len);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 062614ad0d51..08425b1d2c30 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -550,21 +550,33 @@ void mt76x02_sta_rate_tbl_update(struct ieee80211_hw *hw,
 }
 EXPORT_SYMBOL_GPL(mt76x02_sta_rate_tbl_update);
 
-int mt76x02_insert_hdr_pad(struct sk_buff *skb)
+void mt76x02_align_skb(struct sk_buff *skb)
 {
-	int len = ieee80211_get_hdrlen_from_skb(skb);
+	int align = ((unsigned long) skb->data) & 3;
+	int hdrlen, skblen;
 
-	if (len % 4 == 0)
-		return 0;
+	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+	WARN_ON_ONCE(align == 0 && (hdrlen & 3));
+
+	if (align == 0)
+		return;
 
-	skb_push(skb, 2);
-	memmove(skb->data, skb->data + 2, len);
+	if (hdrlen & 3) {
+		/* Align frame and add 2 bytes pad after header. */
+		skb_push(skb, 2);
+		memmove(skb->data, skb->data + 2, hdrlen);
 
-	skb->data[len] = 0;
-	skb->data[len + 1] = 0;
-	return 2;
+		skb->data[hdrlen] = 0;
+		skb->data[hdrlen + 1] = 0;
+	} else {
+		/* Only for probe request frames. */
+		skblen = skb->len;
+		skb_push(skb, 2);
+		memmove(skb->data, skb->data + 2, skblen);
+		skb_trim(skb, skblen);
+	}
 }
-EXPORT_SYMBOL_GPL(mt76x02_insert_hdr_pad);
+EXPORT_SYMBOL_GPL(mt76x02_align_skb);
 
 void mt76x02_remove_hdr_pad(struct sk_buff *skb, int len)
 {
-- 
2.7.5


^ permalink raw reply related

* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Kalle Valo @ 2019-02-18 13:48 UTC (permalink / raw)
  To: maowenan; +Cc: johannes, linux-wireless, kernel-janitors, netdev
In-Reply-To: <927ff17c-c506-734f-fc27-796d4c8fba98@huawei.com>

maowenan <maowenan@huawei.com> writes:

> Add kalle Valo in mail list.
>
> Hi Kalle Valo,
> Do you have any comments about this patch?

Why do you ask me? Johannes maintains cfg80211, not me, and he will
provide comments once he reviews the patch (which might take some time,
we do have other tasks as well).

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: maowenan @ 2019-02-18 13:25 UTC (permalink / raw)
  To: johannes, linux-wireless, kernel-janitors, netdev, kvalo
In-Reply-To: <20190216094710.127182-1-maowenan@huawei.com>

Add kalle Valo in mail list.

Hi Kalle Valo,
Do you have any comments about this patch?

On 2019/2/16 17:47, Mao Wenan wrote:
> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memset().
> 
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
>  net/wireless/pmsr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/wireless/pmsr.c b/net/wireless/pmsr.c
> index de9286703280..21139b82749f 100644
> --- a/net/wireless/pmsr.c
> +++ b/net/wireless/pmsr.c
> @@ -258,7 +258,7 @@ int nl80211_pmsr_start(struct sk_buff *skb, struct genl_info *info)
>  	} else {
>  		memcpy(req->mac_addr, nla_data(info->attrs[NL80211_ATTR_MAC]),
>  		       ETH_ALEN);
> -		memset(req->mac_addr_mask, 0xff, ETH_ALEN);
> +		eth_broadcast_addr(req->mac_addr_mask);
>  	}
>  
>  	idx = 0;
> 


^ permalink raw reply

* brcmfmac auto channel selection
From: Francesco Chiechi - Colibre @ 2019-02-18 11:23 UTC (permalink / raw)
  To: linux-wireless

hello everybody,

I need to implement Auto Channel Selection for the brcmfmac driver.
The chip I'm working on is a CYW43455 (BCM43455).
If I understand it correctly, user space needs the dump_survey
function to be supported in cfg80211_ops (The corresponding android
driver supports it under the configuration option WL_SUPPORT_ACS).

Some questions then:
- is there any technical reason why the dump_survey function is not
  already implemented in brcmfmac?
- it looks like that at a minimum SURVEY_INFO_NOISE_DBM should be
  returned into the survey_info struct. Does anybody have any hint
  on how to get this value, perhaps by using a brcmf_fil_xxx_yyy_get
  function with BRCMF_C_GET_PHY_NOISE?

thank you very much

Francesco

^ permalink raw reply

* [PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()
From: Johannes Berg @ 2019-02-18 10:29 UTC (permalink / raw)
  To: linux-wireless, netdev; +Cc: Herbert Xu, Wei Yongjun

From: Wei Yongjun <weiyongjun1@huawei.com>

spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
is used for unlocking. Fix it by using spin_unlock_bh() instead
of rcu_read_unlock() in the error handling case.

Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Dave, can you take this directly? I see little value in sending a
pull request for this one patch (but if you prefer can do so.)
---
 net/mac80211/mesh_pathtbl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index c3a7396fb955..88a6d5e18ccc 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -627,7 +627,7 @@ static int table_path_del(struct mesh_table *tbl,
 	spin_lock_bh(&tbl->walk_lock);
 	mpath = rhashtable_lookup_fast(&tbl->rhead, addr, mesh_rht_params);
 	if (!mpath) {
-		rcu_read_unlock();
+		spin_unlock_bh(&tbl->walk_lock);
 		return -ENXIO;
 	}
 
-- 
2.17.2


^ permalink raw reply related

* Re: [v3 PATCH 0/4] mac80211: Fix incorrect usage of rhashtable walk API
From: Herbert Xu @ 2019-02-18 10:25 UTC (permalink / raw)
  To: Johannes Berg
  Cc: David Miller, linux-wireless, netdev, j, tgraf, Julia Lawall
In-Reply-To: <52bdb66f7e9e26ce9225ae11e37e22766d73694d.camel@sipsolutions.net>

On Fri, Feb 15, 2019 at 01:21:55PM +0100, Johannes Berg wrote:
> 
> Applied those now, I'll send a pull request to Dave with them. Once that
> trickles back into net-next I'll apply the third patch (it doesn't apply
> without the others), and then Dave you can take the rhashtable one.

Thanks Johannes.

> Let me know if you'd prefer I take the rhashtable one through my tree,
> which really would be only so you don't have to track the dependency.

I don't mind.

> NB: it'd be easier in patchwork if you tagged all the patches with v3 in
> their own PATCH tag, or put the "v3" tag into the actual subject (not
> the "[PATCH 0/4]" tag because evidently patchwork drops the tags and
> doesn't track them for the *series* just each *patch* ... so with what
> you did nothing is visible in patchwork, even just appending "(v3)" to
> the subject of the cover letter would've fixed that...

Noted.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [PATCH] mac80211: mesh: fix missing unlock on error in table_path_del()
From: Herbert Xu @ 2019-02-18 10:25 UTC (permalink / raw)
  To: Wei Yongjun; +Cc: Johannes Berg, linux-wireless, kernel-janitors
In-Reply-To: <20190218065216.155259-1-weiyongjun1@huawei.com>

On Mon, Feb 18, 2019 at 06:52:16AM +0000, Wei Yongjun wrote:
> spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
> is used for unlocking. Fix it by using spin_unlock_bh() instead
> of rcu_read_unlock() in the error handling case.
> 
> Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

Thanks for catching this!
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH] carl9170: clean up a clamp() call
From: Dan Carpenter @ 2019-02-18  9:31 UTC (permalink / raw)
  To: Christian Lamparter; +Cc: Kalle Valo, linux-wireless, kernel-janitors

The parameter order for clamp is supposed to be clamp(value, low, high).
When we write it in this order it's equivalent to
min(head->plcp[3] & 0x7f, 75) which works in this context where the min
is zero.  But it's not a correct use of the API.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
 drivers/net/wireless/ath/carl9170/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
index f7c2f19e81c1..8e154f6364a3 100644
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -427,7 +427,7 @@ static int carl9170_rx_mac_status(struct ar9170 *ar,
 		if (head->plcp[6] & 0x80)
 			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
 
-		status->rate_idx = clamp(0, 75, head->plcp[3] & 0x7f);
+		status->rate_idx = clamp(head->plcp[3] & 0x7f, 0, 75);
 		status->encoding = RX_ENC_HT;
 		break;
 
-- 
2.17.1


^ permalink raw reply related

* Re: [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT
From: Borislav Petkov @ 2019-02-18  8:09 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Ingo Molnar, Thomas Gleixner, H . Peter Anvin, x86, Kalle Valo,
	linux-wireless, Christoph Hellwig, linux-kernel
In-Reply-To: <1550469571-25933-3-git-send-email-yamada.masahiro@socionext.com>

On Mon, Feb 18, 2019 at 02:59:31PM +0900, Masahiro Yamada wrote:
> arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
> alternatives, but they are implemented in arch/x86/lib/hweight.S
> 
> x86 does not rely on the generic C implementation lib/hweight.c
> at all, so CONFIG_GENERIC_HWEIGHT should be disabled.
> 
> __HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.

Well, it was needed because I didn't think of removing the selection of
GENERIC_HWEIGHT in arch/x86/ at the time:

ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:27: multiple definition of `__ksymtab___sw_hweight32'; arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:47: first defined here
ld: lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:67: multiple definition of `__ksymtab___sw_hweight64'; arch/x86/built-in.o:/dev/shm/bpetkov/kernel/linux/arch/x86/kernel/x8664_ksyms_64.c:48: first defined here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight32':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:12: multiple definition of `__sw_hweight32'; lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:15: first defined here
ld: arch/x86/lib/built-in.o: in function `__sw_hweight64':
/dev/shm/bpetkov/kernel/linux/arch/x86/lib/hweight.S:38: multiple definition of `__sw_hweight64'; lib/built-in.o:/dev/shm/bpetkov/kernel/linux/lib/hweight.c:53: first defined here
make: *** [vmlinux] Error 1

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply

* [PATCH] brcmfmac: remove set but not used variable 'old_state'
From: YueHaibing @ 2019-02-18  8:08 UTC (permalink / raw)
  To: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
	Wright Feng, Kalle Valo
  Cc: YueHaibing, linux-wireless, netdev, brcm80211-dev-list.pdl,
	brcm80211-dev-list, kernel-janitors

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning:
 variable 'old_state' set but not used [-Wunused-but-set-variable]

It's never used and can be removed.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 76cfaf6999c8..398536b30b7a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -575,7 +575,6 @@ static void
 brcmf_usb_state_change(struct brcmf_usbdev_info *devinfo, int state)
 {
 	struct brcmf_bus *bcmf_bus = devinfo->bus_pub.bus;
-	int old_state;
 
 	brcmf_dbg(USB, "Enter, current state=%d, new state=%d\n",
 		  devinfo->bus_pub.state, state);
@@ -583,7 +582,6 @@ brcmf_usb_state_change(struct brcmf_usbdev_info *devinfo, int state)
 	if (devinfo->bus_pub.state == state)
 		return;
 
-	old_state = devinfo->bus_pub.state;
 	devinfo->bus_pub.state = state;
 
 	/* update state of upper layer */




^ permalink raw reply related

* [PATCH] rtl818x_pci: Remove set but not used variables 'io_addr, mem_addr'
From: YueHaibing @ 2019-02-18  7:52 UTC (permalink / raw)
  To: Kalle Valo, John W. Linville, Colin Ian King
  Cc: YueHaibing, linux-wireless, netdev, kernel-janitors

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c: In function 'rtl8180_probe':
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1727:15: warning:
 variable 'io_addr' set but not used [-Wunused-but-set-variable]

drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1726:16: warning:
 variable 'mem_addr' set but not used [-Wunused-but-set-variable]

They're never used since introduction.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
index e2b1bfbcfbd4..d5f65372356b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
@@ -1723,8 +1723,8 @@ static int rtl8180_probe(struct pci_dev *pdev,
 {
 	struct ieee80211_hw *dev;
 	struct rtl8180_priv *priv;
-	unsigned long mem_addr, mem_len;
-	unsigned int io_addr, io_len;
+	unsigned long mem_len;
+	unsigned int io_len;
 	int err;
 	const char *chip_name, *rf_name = NULL;
 	u32 reg;
@@ -1743,9 +1743,7 @@ static int rtl8180_probe(struct pci_dev *pdev,
 		goto err_disable_dev;
 	}
 
-	io_addr = pci_resource_start(pdev, 0);
 	io_len = pci_resource_len(pdev, 0);
-	mem_addr = pci_resource_start(pdev, 1);
 	mem_len = pci_resource_len(pdev, 1);
 
 	if (mem_len < sizeof(struct rtl818x_csr) ||




^ permalink raw reply related

* [PATCH] rsi: remove set but not used variables 'info, vif'
From: YueHaibing @ 2019-02-18  7:51 UTC (permalink / raw)
  To: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo
  Cc: YueHaibing, linux-wireless, netdev, kernel-janitors

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_prepare_skb':
drivers/net/wireless/rsi/rsi_91x_main.c:127:24: warning:
 variable 'vif' set but not used [-Wunused-but-set-variable]

drivers/net/wireless/rsi/rsi_91x_main.c:124:28: warning:
 variable 'info' set but not used [-Wunused-but-set-variable]

They're not used any more since 160ee2a11ce0 ("rsi: fill rx_params only once.")

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/net/wireless/rsi/rsi_91x_main.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c
index ca3a55ed72e4..29d83049c5f5 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -121,11 +121,8 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common *common,
 				       u32 pkt_len,
 				       u8 extended_desc)
 {
-	struct ieee80211_tx_info *info;
 	struct sk_buff *skb = NULL;
 	u8 payload_offset;
-	struct ieee80211_vif *vif;
-	struct ieee80211_hdr *wh;
 
 	if (WARN(!pkt_len, "%s: Dummy pkt received", __func__))
 		return NULL;
@@ -144,10 +141,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common *common,
 	payload_offset = (extended_desc + FRAME_DESC_SZ);
 	skb_put(skb, pkt_len);
 	memcpy((skb->data), (buffer + payload_offset), skb->len);
-	wh = (struct ieee80211_hdr *)skb->data;
-	vif = rsi_get_vif(common->priv, wh->addr1);
 
-	info = IEEE80211_SKB_CB(skb);
 	return skb;
 }




^ permalink raw reply related

* [PATCH] mac80211: mesh: fix missing unlock on error in table_path_del()
From: Wei Yongjun @ 2019-02-18  6:52 UTC (permalink / raw)
  To: Johannes Berg, Herbert Xu; +Cc: Wei Yongjun, linux-wireless, kernel-janitors

spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
is used for unlocking. Fix it by using spin_unlock_bh() instead
of rcu_read_unlock() in the error handling case.

Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 net/mac80211/mesh_pathtbl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index c3a7396fb955..9bdeac2749e9 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -627,7 +627,7 @@ static int table_path_del(struct mesh_table *tbl,
 	spin_lock_bh(&tbl->walk_lock);
 	mpath = rhashtable_lookup_fast(&tbl->rhead, addr, mesh_rht_params);
 	if (!mpath) {
-		rcu_read_unlock();
+		spin_unlock_bh(&tbl->walk_lock);
 		return -ENXIO;
 	}




^ permalink raw reply related

* [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-18  5:59 UTC (permalink / raw)
  To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
	x86
  Cc: Kalle Valo, linux-wireless, Christoph Hellwig, Masahiro Yamada,
	David S. Miller, netdev, linux-kernel, Lorenzo Bianconi,
	linux-mediatek, linux-arm-kernel, Felix Fietkau, Matthias Brugger
In-Reply-To: <1550469571-25933-1-git-send-email-yamada.masahiro@socionext.com>

__sw_hweight8() is just internal implementation.

Drivers should use the common API, hweight8().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

This patch should go to x86 tree along with 2/2.

Otherwise, all{yes,mod}config of x86 would be broken.

This patch is trivial enough.
I want ACK from the net/wireless maintainer
so that this can go in via x86 tree.


 drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 7b926df..c42e0d3 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -124,7 +124,7 @@ static void mt76_init_stream_cap(struct mt76_dev *dev,
 				 bool vht)
 {
 	struct ieee80211_sta_ht_cap *ht_cap = &sband->ht_cap;
-	int i, nstream = __sw_hweight8(dev->antenna_mask);
+	int i, nstream = hweight8(dev->antenna_mask);
 	struct ieee80211_sta_vht_cap *vht_cap;
 	u16 mcs_map = 0;
 
-- 
2.7.4


^ permalink raw reply related

* [PATCH] ath10k: remove the calibration data fetch for sdio
From: Wen Gong @ 2019-02-18  6:14 UTC (permalink / raw)
  To: ath10k; +Cc: linux-wireless

The calibration data fetch will trigger sdio error, then sdio will
become fail untill reboot system.

If happens when run ifconfig wlan down, then ifconfig wlan up will
fail untill reboot system.Remove it fix the ifconfig wlan issue.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00005-QCARMSWP-1.

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

diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 15964b3..c33a51f 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1263,6 +1263,9 @@ static int ath10k_debug_cal_data_fetch(struct ath10k *ar)
 	if (WARN_ON(ar->hw_params.cal_data_len > ATH10K_DEBUG_CAL_DATA_LEN))
 		return -EINVAL;
 
+	if (ar->hw_params.cal_data_len == 0)
+		return -EOPNOTSUPP;
+
 	hi_addr = host_interest_item_address(HI_ITEM(hi_board_data));
 
 	ret = ath10k_hif_diag_read(ar, hi_addr, &addr, sizeof(addr));
-- 
1.9.1


^ permalink raw reply related

* [PATCH 2/2] x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT
From: Masahiro Yamada @ 2019-02-18  5:59 UTC (permalink / raw)
  To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
	x86
  Cc: Kalle Valo, linux-wireless, Christoph Hellwig, Masahiro Yamada,
	linux-kernel
In-Reply-To: <1550469571-25933-1-git-send-email-yamada.masahiro@socionext.com>

arch/x86/include/asm/arch_hweight.h uses __sw_hweight{32,64} as
alternatives, but they are implemented in arch/x86/lib/hweight.S

x86 does not rely on the generic C implementation lib/hweight.c
at all, so CONFIG_GENERIC_HWEIGHT should be disabled.

__HAVE_ARCH_SW_HWEIGHT was unneeded in the first place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/x86/Kconfig                    | 3 ---
 arch/x86/include/asm/arch_hweight.h | 2 --
 lib/hweight.c                       | 4 ----
 3 files changed, 9 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6826143..c2813af 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -262,9 +262,6 @@ config GENERIC_BUG
 config GENERIC_BUG_RELATIVE_POINTERS
 	bool
 
-config GENERIC_HWEIGHT
-	def_bool y
-
 config ARCH_MAY_HAVE_PC_FDC
 	def_bool y
 	depends on ISA_DMA_API
diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
index fc06935..ba88edd 100644
--- a/arch/x86/include/asm/arch_hweight.h
+++ b/arch/x86/include/asm/arch_hweight.h
@@ -12,8 +12,6 @@
 #define REG_OUT "a"
 #endif
 
-#define __HAVE_ARCH_SW_HWEIGHT
-
 static __always_inline unsigned int __arch_hweight32(unsigned int w)
 {
 	unsigned int res;
diff --git a/lib/hweight.c b/lib/hweight.c
index 7660d88..c94586b 100644
--- a/lib/hweight.c
+++ b/lib/hweight.c
@@ -10,7 +10,6 @@
  * The Hamming Weight of a number is the total number of bits set in it.
  */
 
-#ifndef __HAVE_ARCH_SW_HWEIGHT
 unsigned int __sw_hweight32(unsigned int w)
 {
 #ifdef CONFIG_ARCH_HAS_FAST_MULTIPLIER
@@ -27,7 +26,6 @@ unsigned int __sw_hweight32(unsigned int w)
 #endif
 }
 EXPORT_SYMBOL(__sw_hweight32);
-#endif
 
 unsigned int __sw_hweight16(unsigned int w)
 {
@@ -46,7 +44,6 @@ unsigned int __sw_hweight8(unsigned int w)
 }
 EXPORT_SYMBOL(__sw_hweight8);
 
-#ifndef __HAVE_ARCH_SW_HWEIGHT
 unsigned long __sw_hweight64(__u64 w)
 {
 #if BITS_PER_LONG == 32
@@ -69,4 +66,3 @@ unsigned long __sw_hweight64(__u64 w)
 #endif
 }
 EXPORT_SYMBOL(__sw_hweight64);
-#endif
-- 
2.7.4


^ permalink raw reply related

* [PATCH 0/2] x86: turn off wrongly enabled CONFIG_GENERIC_HWEIGHT
From: Masahiro Yamada @ 2019-02-18  5:59 UTC (permalink / raw)
  To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
	x86
  Cc: Kalle Valo, linux-wireless, Christoph Hellwig, Masahiro Yamada,
	David S. Miller, netdev, linux-kernel, Lorenzo Bianconi,
	linux-mediatek, linux-arm-kernel, Felix Fietkau, Matthias Brugger


x86 should not enable CONFIG_GENERIC_HWEIGHT
because lib/hweight.c is not used by x86.

The only user is drivers/net/wireless/mediatek/mt76/mac80211.c

Of course, this driver is wrong since drivers should use the
generic API, hweight8().

After fixing it, x86 does not need to compile lib/hweight.c at all.

The real implementation is located in arch/x86/lib/hweight.S



Masahiro Yamada (2):
  wireless: mt76: call hweight8() instead of __sw_hweight8()
  x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT

 arch/x86/Kconfig                              | 3 ---
 arch/x86/include/asm/arch_hweight.h           | 2 --
 drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
 lib/hweight.c                                 | 4 ----
 4 files changed, 1 insertion(+), 10 deletions(-)

-- 
2.7.4


^ permalink raw reply

* [PATCH 3/3] mac80211: probe unexercised mesh links
From: Rajkumar Manoharan @ 2019-02-18  6:04 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Rajkumar Manoharan
In-Reply-To: <1550469857-3968-1-git-send-email-rmanohar@codeaurora.org>

The requirement for mesh link metric refreshing, is that from one
mesh point we be able to send some data frames to other mesh points
which are not currently selected as a primary traffic path, but which
are only 1 hop away. The absence of the primary path to the chosen node
makes it necessary to apply some form of marking on a chosen packet
stream so that the packets can be properly steered to the selected node
for testing, and not by the regular mesh path lookup.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
---
 include/net/mac80211.h     |  2 ++
 net/mac80211/cfg.c         |  1 +
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mesh_hwmp.c   |  4 ++++
 net/mac80211/tx.c          | 29 +++++++++++++++++++++++++++++
 5 files changed, 38 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 88219cc137c3..65a5889be6b0 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -786,6 +786,7 @@ enum mac80211_tx_info_flags {
  * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
  * @IEEE80211_TX_CTRL_AMSDU: This frame is an A-MSDU frame
  * @IEEE80211_TX_CTRL_FAST_XMIT: This frame is going through the fast_xmit path
+ * @IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP: This frame skips mesh path lookup
  *
  * These flags are used in tx_info->control.flags.
  */
@@ -795,6 +796,7 @@ enum mac80211_tx_control_flags {
 	IEEE80211_TX_CTRL_RATE_INJECT		= BIT(2),
 	IEEE80211_TX_CTRL_AMSDU			= BIT(3),
 	IEEE80211_TX_CTRL_FAST_XMIT		= BIT(4),
+	IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP	= BIT(5),
 };
 
 /*
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 96496b2c1670..23df122d14a6 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3978,4 +3978,5 @@ static int ieee80211_get_txq_stats(struct wiphy *wiphy,
 	.get_ftm_responder_stats = ieee80211_get_ftm_responder_stats,
 	.start_pmsr = ieee80211_start_pmsr,
 	.abort_pmsr = ieee80211_abort_pmsr,
+	.probe_mesh_link = ieee80211_probe_mesh_link,
 };
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a1638a5d4188..974b651e3fbe 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1754,6 +1754,8 @@ void ieee80211_tx_monitor(struct ieee80211_local *local, struct sk_buff *skb,
 int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,
 			      const u8 *buf, size_t len,
 			      const u8 *dest, __be16 proto, bool unencrypted);
+int ieee80211_probe_mesh_link(struct wiphy *wiphy, struct net_device *dev,
+			      const u8 *buf, size_t len);
 
 /* HT */
 void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 6950cd0bf594..fe11bbd137ef 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1118,6 +1118,10 @@ int mesh_nexthop_resolve(struct ieee80211_sub_if_data *sdata,
 	if (ieee80211_is_qos_nullfunc(hdr->frame_control))
 		return 0;
 
+	/* Allow injected packets to bypass mesh routing */
+	if (info->control.flags & IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP)
+		return 0;
+
 	rcu_read_lock();
 	err = mesh_nexthop_lookup(sdata, skb);
 	if (!err)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c2ee5678b2d8..71dc21793060 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4916,3 +4916,32 @@ int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,
 
 	return 0;
 }
+
+int ieee80211_probe_mesh_link(struct wiphy *wiphy, struct net_device *dev,
+			      const u8 *buf, size_t len)
+{
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+	struct ieee80211_local *local = sdata->local;
+	struct sk_buff *skb;
+
+	skb = dev_alloc_skb(local->hw.extra_tx_headroom + len +
+			    30 + /* header size */
+			    18); /* 11s header size */
+	if (!skb)
+		return -ENOMEM;
+
+	skb_reserve(skb, local->hw.extra_tx_headroom);
+	skb_put_data(skb, buf, len);
+
+	skb->dev = dev;
+	skb->protocol = htons(ETH_P_802_3);
+	skb_reset_network_header(skb);
+	skb_reset_mac_header(skb);
+
+	local_bh_disable();
+	__ieee80211_subif_start_xmit(skb, skb->dev, 0,
+				     IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP);
+	local_bh_enable();
+
+	return 0;
+}
-- 
1.9.1


^ permalink raw reply related

* [PATCH 2/3] mac80211: add option for setting control flags
From: Rajkumar Manoharan @ 2019-02-18  6:04 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Rajkumar Manoharan
In-Reply-To: <1550469857-3968-1-git-send-email-rmanohar@codeaurora.org>

Allows setting of control flags of skb cb - if needed -
when calling ieee80211_subif_start_xmit().

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
---
 net/mac80211/ieee80211_i.h |  3 ++-
 net/mac80211/tdls.c        |  2 +-
 net/mac80211/tx.c          | 18 +++++++++++-------
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 7dfb4e2f98b2..a1638a5d4188 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1736,7 +1736,8 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 				       struct net_device *dev);
 void __ieee80211_subif_start_xmit(struct sk_buff *skb,
 				  struct net_device *dev,
-				  u32 info_flags);
+				  u32 info_flags,
+				  u32 ctrl_flags);
 void ieee80211_purge_tx_queue(struct ieee80211_hw *hw,
 			      struct sk_buff_head *skbs);
 struct sk_buff *
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index 6c647f425e05..044dad3e0423 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -1055,7 +1055,7 @@ static void ieee80211_tdls_add_ies(struct ieee80211_sub_if_data *sdata,
 
 	/* disable bottom halves when entering the Tx path */
 	local_bh_disable();
-	__ieee80211_subif_start_xmit(skb, dev, flags);
+	__ieee80211_subif_start_xmit(skb, dev, flags, 0);
 	local_bh_enable();
 
 	return ret;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 928f13a208b0..c2ee5678b2d8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2424,6 +2424,7 @@ static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
  * @sdata: virtual interface to build the header for
  * @skb: the skb to build the header in
  * @info_flags: skb flags to set
+ * @ctrl_flags: info control flags to set
  *
  * This function takes the skb with 802.3 header and reformats the header to
  * the appropriate IEEE 802.11 header based on which interface the packet is
@@ -2439,7 +2440,7 @@ static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
  */
 static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
 					   struct sk_buff *skb, u32 info_flags,
-					   struct sta_info *sta)
+					   struct sta_info *sta, u32 ctrl_flags)
 {
 	struct ieee80211_local *local = sdata->local;
 	struct ieee80211_tx_info *info;
@@ -2811,6 +2812,7 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
 	info->flags = info_flags;
 	info->ack_frame_id = info_id;
 	info->band = band;
+	info->control.flags = ctrl_flags;
 
 	return skb;
  free:
@@ -3638,7 +3640,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
 
 void __ieee80211_subif_start_xmit(struct sk_buff *skb,
 				  struct net_device *dev,
-				  u32 info_flags)
+				  u32 info_flags,
+				  u32 ctrl_flags)
 {
 	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	struct sta_info *sta;
@@ -3703,7 +3706,8 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
 		skb->prev = NULL;
 		skb->next = NULL;
 
-		skb = ieee80211_build_hdr(sdata, skb, info_flags, sta);
+		skb = ieee80211_build_hdr(sdata, skb, info_flags,
+					  sta, ctrl_flags);
 		if (IS_ERR(skb))
 			goto out;
 
@@ -3843,9 +3847,9 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 		__skb_queue_head_init(&queue);
 		ieee80211_convert_to_unicast(skb, dev, &queue);
 		while ((skb = __skb_dequeue(&queue)))
-			__ieee80211_subif_start_xmit(skb, dev, 0);
+			__ieee80211_subif_start_xmit(skb, dev, 0, 0);
 	} else {
-		__ieee80211_subif_start_xmit(skb, dev, 0);
+		__ieee80211_subif_start_xmit(skb, dev, 0, 0);
 	}
 
 	return NETDEV_TX_OK;
@@ -3870,7 +3874,7 @@ struct sk_buff *
 		goto out;
 	}
 
-	skb = ieee80211_build_hdr(sdata, skb, info_flags, sta);
+	skb = ieee80211_build_hdr(sdata, skb, info_flags, sta, 0);
 	if (IS_ERR(skb))
 		goto out;
 
@@ -4907,7 +4911,7 @@ int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,
 	skb_reset_mac_header(skb);
 
 	local_bh_disable();
-	__ieee80211_subif_start_xmit(skb, skb->dev, flags);
+	__ieee80211_subif_start_xmit(skb, skb->dev, flags, 0);
 	local_bh_enable();
 
 	return 0;
-- 
1.9.1


^ permalink raw reply related

* [PATCH 1/3] cfg80211: add support to probe unexercised mesh link
From: Rajkumar Manoharan @ 2019-02-18  6:04 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Rajkumar Manoharan
In-Reply-To: <1550469857-3968-1-git-send-email-rmanohar@codeaurora.org>

Adding support to allow mesh HWMP to measure link metrics on unexercised
direct mesh path by sending some data frames to other mesh points which
are not currently selected as a primary traffic path but only 1 hop away.
The absence of the primary path to the chosen node makes it necessary to
apply some form of marking on a chosen packet stream so that the packets
can be properly steered to the selected node for testing, and not by the
regular mesh path lookup.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
---
 include/net/cfg80211.h       |  6 +++++
 include/uapi/linux/nl80211.h | 16 +++++++++++++
 net/wireless/nl80211.c       | 54 ++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/rdev-ops.h      | 13 +++++++++++
 net/wireless/trace.h         | 19 ++++++++++++++++
 5 files changed, 108 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e0c41eb1c860..24ee3fc3e1f5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3379,6 +3379,9 @@ struct cfg80211_pmsr_request {
  *	Statistics should be cumulative, currently no way to reset is provided.
  * @start_pmsr: start peer measurement (e.g. FTM)
  * @abort_pmsr: abort peer measurement
+ *
+ * @probe_mesh_link: Probe direct Mesh peer's link quality by sending data frame
+ *	and overrule HWMP path selection algorithm.
  */
 struct cfg80211_ops {
 	int	(*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -3693,6 +3696,9 @@ struct cfg80211_ops {
 			      struct cfg80211_pmsr_request *request);
 	void	(*abort_pmsr)(struct wiphy *wiphy, struct wireless_dev *wdev,
 			      struct cfg80211_pmsr_request *request);
+
+	int	(*probe_mesh_link)(struct wiphy *wiphy, struct net_device *dev,
+				   const u8 *buf, size_t len);
 };
 
 /*
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 31ae5c7f10e3..e9184381cbdf 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1065,6 +1065,21 @@
  *	indicated by %NL80211_ATTR_WIPHY_FREQ and other attributes
  *	determining the width and type.
  *
+ * @NL80211_CMD_PROBE_MESH_LINK: The requirement for mesh link metric
+ *	refreshing, is that from one mesh point we be able to send some data
+ *	frames to other mesh points which are not currently selected as a
+ *	primary traffic path, but which are only 1 hop away. The absence of
+ *	the primary path to the chosen node makes it necessary to apply some
+ *	form of marking on a chosen packet stream so that the packets can be
+ *	properly steered to the selected node for testing, and not by the
+ *	regular mesh path lookup. Further, the packets must be of type data
+ *	so that the rate control (often embedded in firmware) is used for
+ *	rate selection.
+ *
+ *	Here attribute %NL80211_ATTR_MAC is used to specify connected mesh
+ *	peer MAC address and %NL80211_ATTR_FRAME is used to specify the frame
+ *	content. The frame is ethernet data.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1284,6 +1299,7 @@ enum nl80211_commands {
 	NL80211_CMD_PEER_MEASUREMENT_COMPLETE,
 
 	NL80211_CMD_NOTIFY_RADAR,
+	NL80211_CMD_PROBE_MESH_LINK,
 
 	/* add new commands above here */
 
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d91a408db113..c138bc817af8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13205,6 +13205,52 @@ static int nl80211_get_ftm_responder_stats(struct sk_buff *skb,
 	return -ENOBUFS;
 }
 
+static int nl80211_probe_mesh_link(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev = info->user_ptr[0];
+	struct net_device *dev = info->user_ptr[1];
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	struct station_info sinfo = {};
+	const u8 *buf;
+	size_t len;
+	u8 *dest;
+	int err;
+
+	if (!rdev->ops->probe_mesh_link || !rdev->ops->get_station)
+		return -EOPNOTSUPP;
+
+	if (!info->attrs[NL80211_ATTR_MAC] ||
+	    !info->attrs[NL80211_ATTR_FRAME]) {
+		GENL_SET_ERR_MSG(info, "Frame or MAC missing");
+		return -EINVAL;
+	}
+
+	wdev_lock(wdev);
+	if (wdev->iftype != NL80211_IFTYPE_MESH_POINT) {
+		wdev_unlock(wdev);
+		err = -EOPNOTSUPP;
+		return err;
+	}
+	wdev_unlock(wdev);
+
+	dest = nla_data(info->attrs[NL80211_ATTR_MAC]);
+	buf = nla_data(info->attrs[NL80211_ATTR_FRAME]);
+	len = nla_len(info->attrs[NL80211_ATTR_FRAME]);
+
+	if (len < sizeof(struct ethhdr))
+		return -EINVAL;
+
+	if (!ether_addr_equal(buf, dest) || is_multicast_ether_addr(buf) ||
+	    !ether_addr_equal(buf + ETH_ALEN, dev->dev_addr))
+		return -EINVAL;
+
+	err = rdev_get_station(rdev, dev, dest, &sinfo);
+	if (err)
+		return err;
+
+	return rdev_probe_mesh_link(rdev, dev, dest, buf, len);
+}
+
 #define NL80211_FLAG_NEED_WIPHY		0x01
 #define NL80211_FLAG_NEED_NETDEV	0x02
 #define NL80211_FLAG_NEED_RTNL		0x04
@@ -14139,6 +14185,14 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
 		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
 				  NL80211_FLAG_NEED_RTNL,
 	},
+	{
+		.cmd = NL80211_CMD_PROBE_MESH_LINK,
+		.doit = nl80211_probe_mesh_link,
+		.policy = nl80211_policy,
+		.flags = GENL_UNS_ADMIN_PERM,
+		.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+				  NL80211_FLAG_NEED_RTNL,
+	},
 };
 
 static struct genl_family nl80211_fam __ro_after_init = {
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 5cb48d135fab..ec1b4800872f 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -1272,4 +1272,17 @@ static inline int rdev_del_pmk(struct cfg80211_registered_device *rdev,
 	trace_rdev_return_void(&rdev->wiphy);
 }
 
+static inline int
+rdev_probe_mesh_link(struct cfg80211_registered_device *rdev,
+		     struct net_device *dev, const u8 *dest,
+		     const void *buf, size_t len)
+{
+	int ret;
+
+	trace_rdev_probe_mesh_link(&rdev->wiphy, dev, dest, buf, len);
+	ret = rdev->ops->probe_mesh_link(&rdev->wiphy, dev, buf, len);
+	trace_rdev_return_int(&rdev->wiphy, ret);
+	return ret;
+}
+
 #endif /* __CFG80211_RDEV_OPS */
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 44b2ce1bb13a..274a844c7ea9 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -3362,6 +3362,25 @@
 		  WIPHY_PR_ARG, WDEV_PR_ARG,
 		  (unsigned long long)__entry->cookie)
 );
+
+TRACE_EVENT(rdev_probe_mesh_link,
+	TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+		 const u8 *dest, const u8 *buf, size_t len),
+	TP_ARGS(wiphy, netdev, dest, buf, len),
+	TP_STRUCT__entry(
+		WIPHY_ENTRY
+		NETDEV_ENTRY
+		MAC_ENTRY(dest)
+	),
+	TP_fast_assign(
+		WIPHY_ASSIGN;
+		NETDEV_ASSIGN;
+		MAC_ASSIGN(dest, dest);
+	),
+	TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", " MAC_PR_FMT,
+		  WIPHY_PR_ARG, NETDEV_PR_ARG, MAC_PR_ARG(dest))
+);
+
 #endif /* !__RDEV_OPS_TRACE || TRACE_HEADER_MULTI_READ */
 
 #undef TRACE_INCLUDE_PATH
-- 
1.9.1


^ permalink raw reply related

* [PATCH 0/3] wireless: Add support to probe unexercised mesh link
From: Rajkumar Manoharan @ 2019-02-18  6:04 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Rajkumar Manoharan

Consider below mesh topology.

        MP1
       /    \
      /      \
     MP2 --- MP3

Assume that even though MP1 & MP3 have direct mesh links, the path was
established via MP2. (MP1 <-> MP2 <-> MP3). The 1-hop mesh link MP1 <-> MP3
never be excercised till the current path is terminated. As of now, there
is no option to send data frame to pick other than primary path. So mesh
link metric between MP1 & MP3 never be updated. This series allows user
to send data to 1-hop mesh peers through unexercised mesh path.

-Rajkumar

Initial series:
https://patchwork.kernel.org/project/linux-wireless/list/?series=80289&state=*

Rajkumar Manoharan (3):
  cfg80211: add support to probe unexercised mesh link
  mac80211: add option for setting control flags
  mac80211: probe unexercised mesh links

 include/net/cfg80211.h       |  6 +++++
 include/net/mac80211.h       |  2 ++
 include/uapi/linux/nl80211.h | 16 +++++++++++++
 net/mac80211/cfg.c           |  1 +
 net/mac80211/ieee80211_i.h   |  5 +++-
 net/mac80211/mesh_hwmp.c     |  4 ++++
 net/mac80211/tdls.c          |  2 +-
 net/mac80211/tx.c            | 47 ++++++++++++++++++++++++++++++++------
 net/wireless/nl80211.c       | 54 ++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/rdev-ops.h      | 13 +++++++++++
 net/wireless/trace.h         | 19 ++++++++++++++++
 11 files changed, 160 insertions(+), 9 deletions(-)

-- 
1.9.1


^ permalink raw reply

* Re: [PATCH 0/2] remove qid dependency from mt76-core code
From: Ryder Lee @ 2019-02-18  2:32 UTC (permalink / raw)
  To: lorenzo; +Cc: nbd, linux-wireless, sgruszka, roychl666, linux-mediatek
In-Reply-To: <cover.1550336347.git.lorenzo@kernel.org>

On Sat, 2019-02-16 at 18:47 +0100, lorenzo@kernel.org wrote:
> From: Lorenzo Bianconi <lorenzo@kernel.org>
> 
> Move queue id dependency in driver specific tx queue initialization code
> since new chipsets rely on a different tx queue enumeration scheme.
> Add the possibility to specify qid in mt76_tx routine
> 
> Lorenzo Bianconi (2):
>   mt76: add qid parameter to mt76_tx signature
>   mt76: move txq qid dependency in driver specific code
> 
>  drivers/net/wireless/mediatek/mt76/mac80211.c | 27 +++++++++++-------
>  drivers/net/wireless/mediatek/mt76/mt76.h     | 14 ++++++++--
>  .../net/wireless/mediatek/mt76/mt76x02_txrx.c |  8 +++++-
>  .../net/wireless/mediatek/mt76/mt76x02_util.c |  2 ++
>  drivers/net/wireless/mediatek/mt76/tx.c       | 28 +++++--------------
>  5 files changed, 45 insertions(+), 34 deletions(-)
> 

Thanks. This will help us to develop the new chipsets more easily.

Acked-by: Ryder Lee <ryder.lee@mediatek.com>



^ permalink raw reply

* [PATCH] orinoco : Replace function name in string with __func__
From: Keyur Patel @ 2019-02-17 16:25 UTC (permalink / raw)
  Cc: iamkeyur96, Kalle Valo, David S. Miller, Eric Biggers, Herbert Xu,
	linux-wireless, netdev, linux-kernel

From: Keyur Patel <iamkeyur96@gmail.com>

Replace hard coded function name with __func__, to
improve robustness and to conform to the Linux kernel coding
style. Issue found using checkpatch.

Signed-off-by: Keyur Patel <iamkeyur96@gmail.com>
---
 drivers/net/wireless/intersil/orinoco/mic.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/intersil/orinoco/mic.c b/drivers/net/wireless/intersil/orinoco/mic.c
index 709d9ab3e7bc..67b0c05afbdb 100644
--- a/drivers/net/wireless/intersil/orinoco/mic.c
+++ b/drivers/net/wireless/intersil/orinoco/mic.c
@@ -18,16 +18,16 @@ int orinoco_mic_init(struct orinoco_private *priv)
 {
 	priv->tx_tfm_mic = crypto_alloc_shash("michael_mic", 0, 0);
 	if (IS_ERR(priv->tx_tfm_mic)) {
-		printk(KERN_DEBUG "orinoco_mic_init: could not allocate "
-		       "crypto API michael_mic\n");
+		printk(KERN_DEBUG "%s: could not allocate "
+		       "crypto API michael_mic\n", __func__);
 		priv->tx_tfm_mic = NULL;
 		return -ENOMEM;
 	}
 
 	priv->rx_tfm_mic = crypto_alloc_shash("michael_mic", 0, 0);
 	if (IS_ERR(priv->rx_tfm_mic)) {
-		printk(KERN_DEBUG "orinoco_mic_init: could not allocate "
-		       "crypto API michael_mic\n");
+		printk(KERN_DEBUG "%s: could not allocate "
+		       "crypto API michael_mic\n", __func__);
 		priv->rx_tfm_mic = NULL;
 		return -ENOMEM;
 	}
@@ -52,7 +52,7 @@ int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
 	int err;
 
 	if (tfm_michael == NULL) {
-		printk(KERN_WARNING "orinoco_mic: tfm_michael == NULL\n");
+		printk(KERN_WARNING "%s: tfm_michael == NULL\n", __func__);
 		return -1;
 	}
 
-- 
2.20.1


^ permalink raw reply related

* Re: [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support
From: Alexander Wetzel @ 2019-02-17 19:19 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <790f69239a9635c62c9349323c069e4ac9ad51c9.camel@sipsolutions.net>

>> +/**
>> + * enum nl80211_key_install_mode - Key install mode
>> + *
>> + * @NL80211_KEY_RX_TX: Key must be installed for Rx and Tx
>> + * @NL80211_KEY_RX_ONLY: Allowed in combination with @NL80211_CMD_NEW_KEY:
>> + *	Unicast key has to be installed for Rx only.
>> + * @NL80211_KEY_SWITCH_TX: Allowed in combination with @NL80211_CMD_SET_KEY:
>> + *	Switch Tx to a Rx only, referenced by sta mac and idx.
> 
> Don't you mean the other way around? Or, well, what you say is true for
> the *other* keys?

I don't see the problem but I may simply be to set on my way to see 
it... So I'll just give an outline what's required of the API and how 
this implementation meets those. Hoping that answers your question or 
allowing you to pinpoint our differences in understanding. (I've added a 
  more than really required, it may be useful for other discussions to 
have that outlined in one piece, too.)

Extended Key ID has only two requirements for the kernel API:
1) Allow a key to be used for decryption first and switch it to a 
"normal" Rx/Tx key with a second call

2) Allow pairwise keys to use keyids 0 and 1 instead only 0.

"Legacy" key installs are using NL80211_CMD_NEW_KEY to install a new key 
and are allow to mark a key for WEP or management  default usages via 
NL80211_CMD_SET_KEY later.

With Extended Key ID we stick to a similar approach: NL80211_CMD_NEW_KEY 
is called to install the new key and nl80211_key_install_mode allows to 
select between a "legacy" or "extended" key install: NL80211_KEY_RX_TX 
for "legacy" or NL80211_KEY_RX_ONLY for "extended".

NL80211_KEY_SWITCH_TX is only allowed with NL80211_CMD_SET_KEY and is 
the only Extended Key ID action allowed for that function.

Any non-pairwise keys can only use NL80211_KEY_RX_TX which is of course 
always the default and also allowed for "legacy" pairwise keys.

A Extended Key Install will:
1) call NL80211_CMD_NEW_KEY with all the usual parameters of a new key 
install plus the flag NL80211_KEY_RX_ONLY set.

2) Once ready will call NL80211_CMD_SET_KEY with flag 
NL80211_KEY_SWITCH_TX to activate a specific key.


>>    *	by the %NL80211_SCAN_FLAG_MIN_PREQ_CONTENT flag.
>>    * @NL80211_EXT_FEATURE_ENABLE_FTM_RESPONDER: Driver supports enabling fine
>>    *	timing measurement responder role.
>> - *
> 
> no need to remove that :)

ok, I'll remove all the drive-by comment "cleanups".
It (often) looks kind of untidy and not really worth separate patches 
and I'm kind of responsible for (most) of them.. I see why you don't 
want to see those fixed drive-by...

My understanding is now that we prefer to not change those and I'll 
leave them alone.

> 
>> -	/* only support setting default key */
>> -	if (!key.def && !key.defmgmt)
>> +	/* Only support setting default key and
>> +	 * Extended Key ID action @NL80211_KEY_SWITCH_TX.
>> +	 */
> 
> you can remove the @, it's not a kernel-doc formatted comment
> 
>> -	}
>> +	} else if (key.p.install_mode == NL80211_KEY_SWITCH_TX &&
>> +		   wiphy_ext_feature_isset(&rdev->wiphy,
>> +					   NL80211_EXT_FEATURE_EXT_KEY_ID)) {
>> +		u8 *mac_addr = NULL;
>>   
>> +		if (info->attrs[NL80211_ATTR_MAC])
>> +			mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
>> +
>> +		if (!mac_addr || key.idx < 0 || key.idx > 1) {
>> +			err = -EINVAL;
>> +			goto out;
>> +		}
> 
> Really only 0 and 1 are allowed? Not 0-3?

Yes. Extended Key ID only allows to use Key ID 1 on top of the 
established ID 0. See "IEEE 802.11 - 2016 9.4.2.25.4 RSN capabilities":

Bit 13: Extended Key ID for Individually Addressed Frames. This subfield 
is set to 1 to indicate that the STA supports Key ID values in the range 
0 to 1 for a PTKSA and STKSA when the cipher suite is CCMP or GCMP. A 
value of 0 indicates that the STA only supports Key ID 0 for a PTKSA and
STKSA.

Or also "12.7.6.4 4-way handshake message 2":

If the Extended Key ID for Individually Addressed Frames subfield of the 
RSN Capabilities field is 1 for both the Authenticator and the 
Supplicant, then the Authenticator assigns a new Key ID for the PTKSA in
the range 0 to 1 that is different from the Key ID assigned in the 
previous handshake and uses the MLME-SETKEYS.request primitive to 
install the new key to receive individually addressed MPDUs protected by
the PTK with the assigned Key ID.

> 
>> +++ b/net/wireless/util.c
>> @@ -236,14 +236,22 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
>>   	case WLAN_CIPHER_SUITE_CCMP_256:
>>   	case WLAN_CIPHER_SUITE_GCMP:
>>   	case WLAN_CIPHER_SUITE_GCMP_256:
>> -		/* Disallow pairwise keys with non-zero index unless it's WEP
>> -		 * or a vendor specific cipher (because current deployments use
>> -		 * pairwise WEP keys with non-zero indices and for vendor
>> -		 * specific ciphers this should be validated in the driver or
>> -		 * hardware level - but 802.11i clearly specifies to use zero)
>> +		/* IEEE802.11-2016 allows only 0 and - when using Extended Key
>> +		 * ID - 1 as index for pairwise keys.
>> +		 * @NL80211_KEY_RX_ONLY is only allowed for pairwise keys when
>> +		 * the driver supports Extended Key ID.
>> +		 * @NL80211_KEY_SWITCH_TX must not be set when validating a key.
>>   		 */
>> -		if (pairwise && key_idx)
>> +		if (params->install_mode == NL80211_KEY_RX_ONLY) {
>> +			if (!wiphy_ext_feature_isset(&rdev->wiphy,
>> +						     NL80211_EXT_FEATURE_EXT_KEY_ID))
>> +				return -EINVAL;
>> +			else if (!pairwise || key_idx < 0 || key_idx > 1)
>> +				return -EINVAL;
> 
> same question here

same answer with one remark: The original code did only allow id 0 and 
and I made sure only with install mode NL80211_KEY_RX_ONLY is allowed to 
use non-zero IDs.

Alexander

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox