* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Larry Finger @ 2019-06-06 3:06 UTC (permalink / raw)
To: Aaro Koskinen, Christoph Hellwig, Christian Zigotzky,
Michael Ellerman
Cc: linux-kernel, linux-wireless, linuxppc-dev
In-Reply-To: <20190605225059.GA9953@darkstar.musicnaut.iki.fi>
On 6/5/19 5:50 PM, Aaro Koskinen wrote:
> Hi,
>
> When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
> not work anymore:
>
> [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
> [ 42.184837] b43legacy-phy0 debug: Chip initialized
> [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support the required 30-bit DMA mask
>
> The same happens with the current mainline.
>
> Bisected to:
>
> commit 65a21b71f948406201e4f62e41f06513350ca390
> Author: Christoph Hellwig <hch@lst.de>
> Date: Wed Feb 13 08:01:26 2019 +0100
>
> powerpc/dma: remove dma_nommu_dma_supported
>
> This function is largely identical to the generic version used
> everywhere else. Replace it with the generic version.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Aaro,
First of all, you have my sympathy for the laborious bisection on a PowerBook
G4. I have done several myself. Thank you.
I confirm your results.
The ppc code has a maximum DMA size of 31 bits, thus a 32-bit request will fail.
Why the 30-bit fallback fails in b43legacy fails while it works in b43 is a mystery.
Although dma_nommu_dma_supported() may be "largely identical" to
dma_direct_supported(), they obviously differ. Routine dma_nommu_dma_supported()
returns 1 for 32-bit systems, but I do not know what dma_direct_supported() returns.
I am trying to find a patch.
Larry
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-06 6:40 UTC (permalink / raw)
To: Larry Finger
Cc: Aaro Koskinen, Christoph Hellwig, Christian Zigotzky,
Michael Ellerman, linux-kernel, linux-wireless, linuxppc-dev
In-Reply-To: <35b3f09b-b371-e2cc-4436-120c67e2f1fb@lwfinger.net>
On Wed, Jun 05, 2019 at 10:06:18PM -0500, Larry Finger wrote:
> First of all, you have my sympathy for the laborious bisection on a
> PowerBook G4. I have done several myself. Thank you.
>
> I confirm your results.
>
> The ppc code has a maximum DMA size of 31 bits, thus a 32-bit request will
> fail. Why the 30-bit fallback fails in b43legacy fails while it works in
> b43 is a mystery.
>
> Although dma_nommu_dma_supported() may be "largely identical" to
> dma_direct_supported(), they obviously differ. Routine
> dma_nommu_dma_supported() returns 1 for 32-bit systems, but I do not know
> what dma_direct_supported() returns.
>
> I am trying to find a patch.
if (IS_ENABLED(CONFIG_ZONE_DMA))
min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
else
min_mask = DMA_BIT_MASK(32);
min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
return mask >= __phys_to_dma(dev, min_mask);
So the smaller or:
(1) 32-bit
(2) ARCH_ZONE_DMA_BITS
(3) the actual amount of memory in the system
modolo any DMA offsets that come into play.
No offsets should exists on pmac, and ARCH_ZONE_DMA_BITS is 31 on
powerpc. So unless the system has 1GB or less memory it will probably
return false for b43, because it can't actually guarantee reliable
allocation. It will work fine on x86 with the smaller ZONE_DMA.
^ permalink raw reply
* Re: [PATCH v2 0/2] mt76: usb: fix A-MSDU support
From: Felix Fietkau @ 2019-06-06 8:47 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: kvalo, linux-wireless, lorenzo.bianconi, sgruszka
In-Reply-To: <cover.1559293385.git.lorenzo@kernel.org>
On 2019-05-31 11:38, Lorenzo Bianconi wrote:
> Reallocate the skb if there is no enough space to manage the AMSDU rx packets.
> Do not always copy the first part of received frames if A-MSDU is enabled
> for SG capable devices
>
> Changes since v1:
> - do not allocate multiple page buffers but rely on fragmented skbs
> if there is no enough space to manage the AMSDU rx packets
>
> @Felix: do you prefer to take this series in your tree or is it better
> to merge it in wireless-drivers?
Going through wireless-drivers is fine with me.
Acked-by: Felix Fietkau <nbd@nbd.name>
- Felix
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Aaro Koskinen @ 2019-06-06 9:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Christian Zigotzky, Michael Ellerman,
Larry Finger, linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <dfe6451c93574b61d4bdde4a05c5f8ccf86b31a0.camel@kernel.crashing.org>
Hi,
On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
> > not work anymore:
> >
> > [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
> > [ 42.184837] b43legacy-phy0 debug: Chip initialized
> > [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support the required 30-bit DMA mask
> >
> > The same happens with the current mainline.
>
> How much RAM do you have ?
The system has 1129 MB RAM. Booting with mem=1G makes it work.
A.
^ permalink raw reply
* KMSAN: uninit-value in rt2500usb_bbp_read
From: syzbot @ 2019-06-06 9:42 UTC (permalink / raw)
To: davem, glider, helmut.schaa, kvalo, linux-kernel, linux-wireless,
netdev, sgruszka, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=12f8b01ea00000
kernel config: https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a
dashboard link: https://syzkaller.appspot.com/bug?extid=a106a5b084a6890d2607
compiler: clang version 9.0.0 (/home/glider/llvm/clang
06d00afa61eef8f7f501ebdb4e8612ea43ec2d78)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f746f2a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153072d2a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a106a5b084a6890d2607@syzkaller.appspotmail.com
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: reset high-speed USB device number 2 using dummy_hcd
usb 1-1: device descriptor read/64, error -71
ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x09
failed for offset 0x0000 with error -71
ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07
failed for offset 0x04d0 with error -71
==================================================================
BUG: KMSAN: uninit-value in rt2500usb_regbusy_read
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116 [inline]
BUG: KMSAN: uninit-value in rt2500usb_bbp_read+0x174/0x640
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
CPU: 1 PID: 4943 Comm: kworker/1:2 Not tainted 5.1.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
__msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116
[inline]
rt2500usb_bbp_read+0x174/0x640
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
rt2500usb_validate_eeprom
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline]
rt2500usb_probe_hw+0x3b1/0x2230
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764
rt2x00lib_probe_dev+0xb81/0x3090
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c:1427
rt2x00usb_probe+0x7c7/0xf70
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:837
rt2500usb_probe+0x50/0x60
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1977
usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361
really_probe+0xdae/0x1d80 drivers/base/dd.c:513
driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
__device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
__device_attach+0x454/0x730 drivers/base/dd.c:844
device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
bus_probe_device+0x137/0x390 drivers/base/bus.c:514
device_add+0x288d/0x30e0 drivers/base/core.c:2106
usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027
generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210
usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266
really_probe+0xdae/0x1d80 drivers/base/dd.c:513
driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
__device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
__device_attach+0x454/0x730 drivers/base/dd.c:844
device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
bus_probe_device+0x137/0x390 drivers/base/bus.c:514
device_add+0x288d/0x30e0 drivers/base/core.c:2106
usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534
hub_port_connect drivers/usb/core/hub.c:5089 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
port_event drivers/usb/core/hub.c:5350 [inline]
hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432
process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269
worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
kthread+0x4b5/0x4f0 kernel/kthread.c:254
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
Local variable description: ----reg.i.i@rt2500usb_bbp_read
Variable was created at:
rt2500usb_register_read_lock
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:72 [inline]
rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:115
[inline]
rt2500usb_bbp_read+0xa4/0x640
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
rt2500usb_validate_eeprom
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline]
rt2500usb_probe_hw+0x3b1/0x2230
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Sebastian Gottschall @ 2019-06-06 10:11 UTC (permalink / raw)
To: Ryder Lee, Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <a1ff446dfc06e2443552e7ec2d754099aacce7df.1559541944.git.ryder.lee@mediatek.com>
i tested your patch against a qca 9984 chipset using SAE and without
encryption. both did not work. the devices are connecting, but no data
connection is possible
Sebastian
Am 03.06.2019 um 08:08 schrieb Ryder Lee:
> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> Changes since v3 - fix a wrong expression
> Changes since v2 - remove unused definitions
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
> 4 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> index 59f604f3161f..f860af6a42da 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
> {
> .max = MT7615_MAX_INTERFACES,
> .types = BIT(NL80211_IFTYPE_AP) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_STATION)
> }
> };
> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
> dev->mt76.antenna_mask = 0xf;
>
> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_AP);
>
> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> index b0bb7cc12385..585e67fa2728 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> /* ap use hw bssid 0 and ext bssid */
> if (~mask & BIT(HW_BSSID_0))
> return HW_BSSID_0;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index 43f70195244c..e82297048449 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>
> switch (vif->type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> tx_wlan_idx = mvif->sta.wcid.idx;
> conn_type = CONNECTION_INFRA_AP;
> break;
> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> .rx_wtbl = {
> .tag = cpu_to_le16(WTBL_RX),
> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> - .rca1 = vif->type != NL80211_IFTYPE_AP,
> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
> .rca2 = 1,
> .rv = 1,
> },
> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
> {
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> if (conn_type)
> *conn_type = CONNECTION_INFRA_STA;
> break;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> index e96efb13fa4d..0915cb735699 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> @@ -105,25 +105,19 @@ enum {
> #define STA_TYPE_STA BIT(0)
> #define STA_TYPE_AP BIT(1)
> #define STA_TYPE_ADHOC BIT(2)
> -#define STA_TYPE_TDLS BIT(3)
> #define STA_TYPE_WDS BIT(4)
> #define STA_TYPE_BC BIT(5)
>
> #define NETWORK_INFRA BIT(16)
> #define NETWORK_P2P BIT(17)
> #define NETWORK_IBSS BIT(18)
> -#define NETWORK_MESH BIT(19)
> -#define NETWORK_BOW BIT(20)
> #define NETWORK_WDS BIT(21)
>
> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>
^ permalink raw reply
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Sebastian Gottschall @ 2019-06-06 10:14 UTC (permalink / raw)
To: Ryder Lee, Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <a1ff446dfc06e2443552e7ec2d754099aacce7df.1559541944.git.ryder.lee@mediatek.com>
in addition you should take care about this problem which is raised up
if SAE is used. since AES-CMAC required tid to be non zero
WARNING: CPU: 2 PID: 15324 at
/home/seg/DEV/mt7621/src/router/private/compat-wireless-2017-09-03/net/mac80211/key.c:1096
mt76_wcid_key_setup+0x58/0x9c [mt76]
Modules linked in: shortcut_fe gcm ghash_generic ctr gf128mul mt7615e
mt76 mac80211 compat
CPU: 2 PID: 15324 Comm: wpa_supplicant Tainted: G W 4.14.123 #106
Stack : 00000000 87c2d000 00000000 8007d8b4 80480000 80482b9c 80610000
805a4390
8057e2b4 854fb99c 87ed045c 805e4767 80578288 00000001 854fb940
805e9f78
00000000 00000000 80640000 00000000 81147bb8 00000584 00000007
00000000
00000000 80650000 80650000 20202020 80000000 00000000 80610000
872b9fe0
872a2b14 00000448 00000000 87c2d000 00000010 8022d660 00000008
80640008
...
Call Trace:
[<800153e0>] show_stack+0x58/0x100
[<8042e83c>] dump_stack+0x9c/0xe0
[<800349f0>] __warn+0xe4/0x144
[<8003468c>] warn_slowpath_null+0x1c/0x30
[<872b9fe0>] mt76_wcid_key_setup+0x58/0x9c [mt76]
[<87611690>] mt7615_eeprom_init+0x7b4/0xe9c [mt7615e]
---[ end trace e24aeb4b542e0dea ]---
Am 03.06.2019 um 08:08 schrieb Ryder Lee:
> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> Changes since v3 - fix a wrong expression
> Changes since v2 - remove unused definitions
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
> 4 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> index 59f604f3161f..f860af6a42da 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
> {
> .max = MT7615_MAX_INTERFACES,
> .types = BIT(NL80211_IFTYPE_AP) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_STATION)
> }
> };
> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
> dev->mt76.antenna_mask = 0xf;
>
> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_AP);
>
> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> index b0bb7cc12385..585e67fa2728 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> /* ap use hw bssid 0 and ext bssid */
> if (~mask & BIT(HW_BSSID_0))
> return HW_BSSID_0;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index 43f70195244c..e82297048449 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>
> switch (vif->type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> tx_wlan_idx = mvif->sta.wcid.idx;
> conn_type = CONNECTION_INFRA_AP;
> break;
> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> .rx_wtbl = {
> .tag = cpu_to_le16(WTBL_RX),
> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> - .rca1 = vif->type != NL80211_IFTYPE_AP,
> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
> .rca2 = 1,
> .rv = 1,
> },
> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
> {
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> if (conn_type)
> *conn_type = CONNECTION_INFRA_STA;
> break;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> index e96efb13fa4d..0915cb735699 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> @@ -105,25 +105,19 @@ enum {
> #define STA_TYPE_STA BIT(0)
> #define STA_TYPE_AP BIT(1)
> #define STA_TYPE_ADHOC BIT(2)
> -#define STA_TYPE_TDLS BIT(3)
> #define STA_TYPE_WDS BIT(4)
> #define STA_TYPE_BC BIT(5)
>
> #define NETWORK_INFRA BIT(16)
> #define NETWORK_P2P BIT(17)
> #define NETWORK_IBSS BIT(18)
> -#define NETWORK_MESH BIT(19)
> -#define NETWORK_BOW BIT(20)
> #define NETWORK_WDS BIT(21)
>
> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-06 10:56 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Christoph Hellwig, Christian Zigotzky, Michael Ellerman,
Larry Finger, linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <20190606093149.GA11598@darkstar.musicnaut.iki.fi>
On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN
> > > does
> > > not work anymore:
> > >
> > > [ 42.004303] b43legacy-phy0: Loading firmware version 0x127,
> > > patch level 14 (2005-04-18 02:36:27)
> > > [ 42.184837] b43legacy-phy0 debug: Chip initialized
> > > [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not
> > > support the required 30-bit DMA mask
> > >
> > > The same happens with the current mainline.
> >
> > How much RAM do you have ?
>
> The system has 1129 MB RAM. Booting with mem=1G makes it work.
Wow... that's an odd amount. One thing we could possibly do is add code
to limit the amount of RAM when we detect that device....
Cheers,
Ben.
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-06 10:57 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Christoph Hellwig, Christian Zigotzky, Michael Ellerman,
Larry Finger, linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <d87ac9a7faac0d5522cb496d74afc586410fed9c.camel@kernel.crashing.org>
On Thu, 2019-06-06 at 20:56 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2019-06-06 at 12:31 +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt
> > wrote:
> > > On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote:
> > > > Hi,
> > > >
> > > > When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN
> > > > does
> > > > not work anymore:
> > > >
> > > > [ 42.004303] b43legacy-phy0: Loading firmware version 0x127,
> > > > patch level 14 (2005-04-18 02:36:27)
> > > > [ 42.184837] b43legacy-phy0 debug: Chip initialized
> > > > [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not
> > > > support the required 30-bit DMA mask
> > > >
> > > > The same happens with the current mainline.
> > >
> > > How much RAM do you have ?
> >
> > The system has 1129 MB RAM. Booting with mem=1G makes it work.
>
> Wow... that's an odd amount. One thing we could possibly do is add code
> to limit the amount of RAM when we detect that device....
Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems based
on detecting the presence of that device in the device-tree.
Cheers,
Ben.
^ permalink raw reply
* Re: KMSAN: uninit-value in rt2500usb_bbp_read
From: Alexander Potapenko @ 2019-06-06 10:59 UTC (permalink / raw)
To: syzbot
Cc: David Miller, helmut.schaa, kvalo, LKML, linux-wireless,
Networking, sgruszka, syzkaller-bugs
In-Reply-To: <000000000000cf6a70058aa48695@google.com>
On Thu, Jun 6, 2019 at 11:42 AM syzbot
<syzbot+a106a5b084a6890d2607@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
> git tree: kmsan
> console output: https://syzkaller.appspot.com/x/log.txt?x=12f8b01ea00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a
> dashboard link: https://syzkaller.appspot.com/bug?extid=a106a5b084a6890d2607
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 06d00afa61eef8f7f501ebdb4e8612ea43ec2d78)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f746f2a00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153072d2a00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a106a5b084a6890d2607@syzkaller.appspotmail.com
>
> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 1-1: config 0 descriptor??
> usb 1-1: reset high-speed USB device number 2 using dummy_hcd
> usb 1-1: device descriptor read/64, error -71
> ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x09
> failed for offset 0x0000 with error -71
> ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07
As this line suggests:
> failed for offset 0x04d0 with error -71
, rt2x00usb_vendor_req_buff_lock() fails with error -71, which means
it doesn't initialize the buffer.
But rt2500usb_register_read_lock() ignores that status code and just
assumes the data is always initialized.
> ==================================================================
> BUG: KMSAN: uninit-value in rt2500usb_regbusy_read
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116 [inline]
> BUG: KMSAN: uninit-value in rt2500usb_bbp_read+0x174/0x640
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
> CPU: 1 PID: 4943 Comm: kworker/1:2 Not tainted 5.1.0+ #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x191/0x1f0 lib/dump_stack.c:113
> kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
> __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
> rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116
> [inline]
> rt2500usb_bbp_read+0x174/0x640
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
> rt2500usb_validate_eeprom
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline]
> rt2500usb_probe_hw+0x3b1/0x2230
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764
> rt2x00lib_probe_dev+0xb81/0x3090
> drivers/net/wireless/ralink/rt2x00/rt2x00dev.c:1427
> rt2x00usb_probe+0x7c7/0xf70
> drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:837
> rt2500usb_probe+0x50/0x60
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1977
> usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361
> really_probe+0xdae/0x1d80 drivers/base/dd.c:513
> driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
> __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
> bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
> __device_attach+0x454/0x730 drivers/base/dd.c:844
> device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
> bus_probe_device+0x137/0x390 drivers/base/bus.c:514
> device_add+0x288d/0x30e0 drivers/base/core.c:2106
> usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027
> generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210
> usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266
> really_probe+0xdae/0x1d80 drivers/base/dd.c:513
> driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671
> __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778
> bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454
> __device_attach+0x454/0x730 drivers/base/dd.c:844
> device_initial_probe+0x4a/0x60 drivers/base/dd.c:891
> bus_probe_device+0x137/0x390 drivers/base/bus.c:514
> device_add+0x288d/0x30e0 drivers/base/core.c:2106
> usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534
> hub_port_connect drivers/usb/core/hub.c:5089 [inline]
> hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
> port_event drivers/usb/core/hub.c:5350 [inline]
> hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432
> process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269
> worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
> kthread+0x4b5/0x4f0 kernel/kthread.c:254
> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355
>
> Local variable description: ----reg.i.i@rt2500usb_bbp_read
> Variable was created at:
> rt2500usb_register_read_lock
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:72 [inline]
> rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:115
> [inline]
> rt2500usb_bbp_read+0xa4/0x640
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172
> rt2500usb_validate_eeprom
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline]
> rt2500usb_probe_hw+0x3b1/0x2230
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-06 11:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Aaro Koskinen, Christoph Hellwig, Christian Zigotzky,
Michael Ellerman, Larry Finger, linuxppc-dev, linux-wireless,
linux-kernel
In-Reply-To: <f8df19ffe5b75537045119037459ae9ad4a1de39.camel@kernel.crashing.org>
On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
> > Wow... that's an odd amount. One thing we could possibly do is add code
> > to limit the amount of RAM when we detect that device....
>
> Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems based
> on detecting the presence of that device in the device-tree.
swiotlb doesn't really help you, as these days swiotlb on matters for
the dma_map* case. What would help is a ZONE_DMA that covers these
devices. No need to do the 24-bit x86 does, but 30-bit would do it.
WIP patch for testing below:
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b8286a2013b4..7a367ce87c41 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -319,6 +319,10 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
+#if 1 /* XXX: pmac? dynamic discovery? */
+#define ARCH_ZONE_DMA_BITS 30
+#else
#define ARCH_ZONE_DMA_BITS 31
+#endif
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cba29131bccc..2540d3b2588c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -248,7 +248,8 @@ void __init paging_init(void)
(long int)((top_of_ram - total_ram) >> 20));
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
+ ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
^ permalink raw reply related
* [PATCH] mt7601u: do not schedule rx_tasklet when the device has been disconnected
From: Lorenzo Bianconi @ 2019-06-06 12:26 UTC (permalink / raw)
To: kubakici; +Cc: linux-wireless, lorenzo.bianconi
Do not schedule rx_tasklet when the usb dongle is disconnected. This
patch fixes the common kernel warning reported when the device is
removed.
[ 24.921354] usb 3-14: USB disconnect, device number 7
[ 24.921593] ------------[ cut here ]------------
[ 24.921594] RX urb mismatch
[ 24.921675] WARNING: CPU: 4 PID: 163 at drivers/net/wireless/mediatek/mt7601u/dma.c:200 mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
[ 24.921769] CPU: 4 PID: 163 Comm: kworker/4:2 Tainted: G OE 4.19.31-041931-generic #201903231635
[ 24.921770] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.30 05/23/2014
[ 24.921782] Workqueue: usb_hub_wq hub_event
[ 24.921797] RIP: 0010:mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
[ 24.921800] RSP: 0018:ffff9bd9cfd03d08 EFLAGS: 00010086
[ 24.921802] RAX: 0000000000000000 RBX: ffff9bd9bf043540 RCX: 0000000000000006
[ 24.921803] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff9bd9cfd16420
[ 24.921804] RBP: ffff9bd9cfd03d28 R08: 0000000000000002 R09: 00000000000003a8
[ 24.921805] R10: 0000002f485fca34 R11: 0000000000000000 R12: ffff9bd9bf043c1c
[ 24.921806] R13: ffff9bd9c62fa3c0 R14: 0000000000000082 R15: 0000000000000000
[ 24.921807] FS: 0000000000000000(0000) GS:ffff9bd9cfd00000(0000) knlGS:0000000000000000
[ 24.921808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.921808] CR2: 00007fb2648b0000 CR3: 0000000142c0a004 CR4: 00000000001606e0
[ 24.921809] Call Trace:
[ 24.921812] <IRQ>
[ 24.921819] __usb_hcd_giveback_urb+0x8b/0x140
[ 24.921821] usb_hcd_giveback_urb+0xca/0xe0
[ 24.921828] xhci_giveback_urb_in_irq.isra.42+0x82/0xf0
[ 24.921834] handle_cmd_completion+0xe02/0x10d0
[ 24.921837] xhci_irq+0x274/0x4a0
[ 24.921838] xhci_msi_irq+0x11/0x20
[ 24.921851] __handle_irq_event_percpu+0x44/0x190
[ 24.921856] handle_irq_event_percpu+0x32/0x80
[ 24.921861] handle_irq_event+0x3b/0x5a
[ 24.921867] handle_edge_irq+0x80/0x190
[ 24.921874] handle_irq+0x20/0x30
[ 24.921889] do_IRQ+0x4e/0xe0
[ 24.921891] common_interrupt+0xf/0xf
[ 24.921892] </IRQ>
[ 24.921900] RIP: 0010:usb_hcd_flush_endpoint+0x78/0x180
[ 24.921354] usb 3-14: USB disconnect, device number 7
Fixes: c869f77d6abb ("add mt7601u driver")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
I will post a patch to fix tx side as well
---
drivers/net/wireless/mediatek/mt7601u/dma.c | 33 ++++++++++-----------
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
index f7edeffb2b19..e7703990b291 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -193,10 +193,20 @@ static void mt7601u_complete_rx(struct urb *urb)
struct mt7601u_rx_queue *q = &dev->rx_q;
unsigned long flags;
- spin_lock_irqsave(&dev->rx_lock, flags);
+ switch (urb->status) {
+ case -ECONNRESET:
+ case -ESHUTDOWN:
+ case -ENOENT:
+ return;
+ default:
+ dev_err_ratelimited(dev->dev, "rx urb failed: %d\n",
+ urb->status);
+ /* fall through */
+ case 0:
+ break;
+ }
- if (mt7601u_urb_has_error(urb))
- dev_err(dev->dev, "Error: RX urb failed:%d\n", urb->status);
+ spin_lock_irqsave(&dev->rx_lock, flags);
if (WARN_ONCE(q->e[q->end].urb != urb, "RX urb mismatch"))
goto out;
@@ -363,19 +373,10 @@ int mt7601u_dma_enqueue_tx(struct mt7601u_dev *dev, struct sk_buff *skb,
static void mt7601u_kill_rx(struct mt7601u_dev *dev)
{
int i;
- unsigned long flags;
-
- spin_lock_irqsave(&dev->rx_lock, flags);
- for (i = 0; i < dev->rx_q.entries; i++) {
- int next = dev->rx_q.end;
-
- spin_unlock_irqrestore(&dev->rx_lock, flags);
- usb_poison_urb(dev->rx_q.e[next].urb);
- spin_lock_irqsave(&dev->rx_lock, flags);
- }
-
- spin_unlock_irqrestore(&dev->rx_lock, flags);
+ for (i = 0; i < dev->rx_q.entries; i++)
+ usb_poison_urb(dev->rx_q.e[i].urb);
+ tasklet_kill(&dev->rx_tasklet);
}
static int mt7601u_submit_rx_buf(struct mt7601u_dev *dev,
@@ -525,8 +526,6 @@ void mt7601u_dma_cleanup(struct mt7601u_dev *dev)
{
mt7601u_kill_rx(dev);
- tasklet_kill(&dev->rx_tasklet);
-
mt7601u_free_rx(dev);
mt7601u_free_tx(dev);
--
2.21.0
^ permalink raw reply related
* Update to wireless-regdb about Italy
From: Giorgio Bernardi @ 2019-06-06 13:49 UTC (permalink / raw)
To: linux-wireless
Hi
I'm Italian and I work in Italy, I realize that nowadays the regdb entry
for Italy is as follows:
country IT: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
And it misses the lines:
# Short Range Devices (SRD) (ETSI EN 300 440)
(5725 - 5875 @ 80), (25 mW)
Common to may European Countries.
I dug a bit in the current Italian regulation that is online on the
website of the
Ministry of Economic Development: https://www.mise.gov.it/index.php/en/
In the section about the "National Plan of Frequencies" (only in
Italian) at the URL:
https://www.mise.gov.it/index.php/it/comunicazioni/radio/pnrf-piano-nazionale-di-ripartizione-delle-frequenze
Two PDF files are linked:
--Tabelle di attribuzione Tabella B (27,50 MHz – 10.000 MHz) (pdf)
https://www.mise.gov.it/images/stories/documenti/Tabella_B_2750_MHz-10000_Mhz.pdf
Which at page 28 allows the use for ISM according to the general
European legislation: 2006/771/CE ERC/REC 70-03
--Note (esplicative, di carattere tecnico e con attribuzioni in deroga
al piano) (pdf)
https://www.mise.gov.it/images/stories/documenti/NOTE-pnrf.pdf
Which at page 334, in the paragraph 3.2.3 states in a explicit way the
permit to operate the in the band 5.725 ÷ 5.875 MHz,
with SRD and max power at 25 mW.
According to this regulation there's no reason not to have the:
(5725 - 5875 @ 80), (25 mW)
Inserted for Italy in the regdb
Who can do it ?
--
Giorgio Bernardi
^ permalink raw reply
* Re: [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Adrian Hunter @ 2019-06-06 13:59 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Kalle Valo, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, David S. Miller,
Franky Lin, linux-kernel, Hante Meuleman, YueHaibing,
Michael Trimarchi
In-Reply-To: <20190603183740.239031-4-dianders@chromium.org>
On 3/06/19 9:37 PM, Douglas Anderson wrote:
> There are certain cases, notably when transitioning between sleep and
> active state, when Broadcom SDIO WiFi cards will produce errors on the
> SDIO bus. This is evident from the source code where you can see that
> we try commands in a loop until we either get success or we've tried
> too many times. The comment in the code reinforces this by saying
> "just one write attempt may fail"
>
> Unfortunately these failures sometimes end up causing an "-EILSEQ"
> back to the core which triggers a retuning of the SDIO card and that
> blocks all traffic to the card until it's done.
>
> Let's disable retuning around the commands we expect might fail.
It seems to me that re-tuning needs to be prevented before the
first access otherwise it might be attempted there, and it needs
to continue to be prevented during the transition when it might
reasonably be expected to fail.
What about something along these lines:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4e15ea57d4f5..d932780ef56e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -664,9 +664,18 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
int err = 0;
int err_cnt = 0;
int try_cnt = 0;
+ int need_retune = 0;
+ bool retune_release = false;
brcmf_dbg(TRACE, "Enter: on=%d\n", on);
+ /* Cannot re-tune if device is asleep */
+ if (on) {
+ need_retune = sdio_retune_get_needed(bus->sdiodev->func1); // TODO: host->can_retune ? host->need_retune : 0
+ sdio_retune_hold_now(bus->sdiodev->func1); // TODO: add sdio_retune_hold_now()
+ retune_release = true;
+ }
+
wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
/* 1st KSO write goes to AOS wake up core if device is asleep */
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, &err);
@@ -711,8 +720,16 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
err_cnt = 0;
}
/* bail out upon subsequent access errors */
- if (err && (err_cnt++ > BRCMF_SDIO_MAX_ACCESS_ERRORS))
- break;
+ if (err && (err_cnt++ > BRCMF_SDIO_MAX_ACCESS_ERRORS)) {
+ if (!retune_release)
+ break;
+ /*
+ * Allow one more retry with re-tuning released in case
+ * it helps.
+ */
+ sdio_retune_release(bus->sdiodev->func1);
+ retune_release = false;
+ }
udelay(KSO_WAIT_US);
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val,
@@ -727,6 +744,18 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
if (try_cnt > MAX_KSO_ATTEMPTS)
brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
+ if (retune_release) {
+ /*
+ * CRC errors are not unexpected during the transition but they
+ * also trigger re-tuning. Clear that here to avoid an
+ * unnecessary re-tune if it wasn't already triggered to start
+ * with.
+ */
+ if (!need_retune)
+ sdio_retune_clear_needed(bus->sdiodev->func1); // TODO: host->need_retune = 0
+ sdio_retune_release(bus->sdiodev->func1); // TODO: add sdio_retune_release()
+ }
+
return err;
}
^ permalink raw reply related
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-06-06 15:18 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Felix Fietkau, Lorenzo Bianconi, Roy Luo, YF Luo, Yiwei Chung,
Sean Wang, Chih-Min Chen, linux-wireless, linux-mediatek,
linux-kernel
In-Reply-To: <a0a6f631-2eb1-87cc-5653-338c6126690c@newmedia-net.de>
On Thu, 2019-06-06 at 12:14 +0200, Sebastian Gottschall wrote:
> in addition you should take care about this problem which is raised up
> if SAE is used. since AES-CMAC required tid to be non zero
>
> WARNING: CPU: 2 PID: 15324 at
> /home/seg/DEV/mt7621/src/router/private/compat-wireless-2017-09-03/net/mac80211/key.c:1096
> mt76_wcid_key_setup+0x58/0x9c [mt76]
> Modules linked in: shortcut_fe gcm ghash_generic ctr gf128mul mt7615e
> mt76 mac80211 compat
> CPU: 2 PID: 15324 Comm: wpa_supplicant Tainted: G W 4.14.123 #106
> Stack : 00000000 87c2d000 00000000 8007d8b4 80480000 80482b9c 80610000
> 805a4390
> 8057e2b4 854fb99c 87ed045c 805e4767 80578288 00000001 854fb940
> 805e9f78
> 00000000 00000000 80640000 00000000 81147bb8 00000584 00000007
> 00000000
> 00000000 80650000 80650000 20202020 80000000 00000000 80610000
> 872b9fe0
> 872a2b14 00000448 00000000 87c2d000 00000010 8022d660 00000008
> 80640008
> ...
> Call Trace:
> [<800153e0>] show_stack+0x58/0x100
> [<8042e83c>] dump_stack+0x9c/0xe0
> [<800349f0>] __warn+0xe4/0x144
> [<8003468c>] warn_slowpath_null+0x1c/0x30
> [<872b9fe0>] mt76_wcid_key_setup+0x58/0x9c [mt76]
> [<87611690>] mt7615_eeprom_init+0x7b4/0xe9c [mt7615e]
> ---[ end trace e24aeb4b542e0dea ]---
This is fixed by Lorenzo's patch -
https://patchwork.kernel.org/patch/10976191/
Thanks.
Ryder
^ permalink raw reply
* [PATCH] mt7601u: fix possible memory leak when the device is disconnected
From: Lorenzo Bianconi @ 2019-06-06 15:34 UTC (permalink / raw)
To: kubakici; +Cc: linux-wireless, lorenzo.bianconi
When the device is disconnected while passing traffic it is possible
to receive out of order urbs causing a memory leak since the skb liked
to the current tx urb is not removed. Fix the issue deallocating the skb
cleaning up the tx ring. Moreover this patch fixes the following kernel
warning
[ 57.480771] usb 1-1: USB disconnect, device number 2
[ 57.483451] ------------[ cut here ]------------
[ 57.483462] TX urb mismatch
[ 57.483481] WARNING: CPU: 1 PID: 32 at drivers/net/wireless/mediatek/mt7601u/dma.c:245 mt7601u_complete_tx+0x165/00
[ 57.483483] Modules linked in:
[ 57.483496] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #72
[ 57.483498] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
[ 57.483502] Workqueue: usb_hub_wq hub_event
[ 57.483507] RIP: 0010:mt7601u_complete_tx+0x165/0x1e0
[ 57.483510] Code: 8b b5 10 04 00 00 8b 8d 14 04 00 00 eb 8b 80 3d b1 cb e1 00 00 75 9e 48 c7 c7 a4 ea 05 82 c6 05 f
[ 57.483513] RSP: 0000:ffffc900000a0d28 EFLAGS: 00010092
[ 57.483516] RAX: 000000000000000f RBX: ffff88802c0a62c0 RCX: ffffc900000a0c2c
[ 57.483518] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff810a8371
[ 57.483520] RBP: ffff88803ced6858 R08: 0000000000000000 R09: 0000000000000001
[ 57.483540] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000046
[ 57.483542] R13: ffff88802c0a6c88 R14: ffff88803baab540 R15: ffff88803a0cc078
[ 57.483548] FS: 0000000000000000(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000
[ 57.483550] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 57.483552] CR2: 000055e7f6780100 CR3: 0000000028c86000 CR4: 00000000000006a0
[ 57.483554] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 57.483556] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 57.483559] Call Trace:
[ 57.483561] <IRQ>
[ 57.483565] __usb_hcd_giveback_urb+0x77/0xe0
[ 57.483570] xhci_giveback_urb_in_irq.isra.0+0x8b/0x140
[ 57.483574] handle_cmd_completion+0xf5b/0x12c0
[ 57.483577] xhci_irq+0x1f6/0x1810
[ 57.483581] ? lockdep_hardirqs_on+0x9e/0x180
[ 57.483584] ? _raw_spin_unlock_irq+0x24/0x30
[ 57.483588] __handle_irq_event_percpu+0x3a/0x260
[ 57.483592] handle_irq_event_percpu+0x1c/0x60
[ 57.483595] handle_irq_event+0x2f/0x4c
[ 57.483599] handle_edge_irq+0x7e/0x1a0
[ 57.483603] handle_irq+0x17/0x20
[ 57.483607] do_IRQ+0x54/0x110
[ 57.483610] common_interrupt+0xf/0xf
[ 57.483612] </IRQ>
Fixes: c869f77d6abb ("add mt7601u driver")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt7601u/dma.c | 24 +++++++++++++++------
drivers/net/wireless/mediatek/mt7601u/tx.c | 4 ++--
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
index e7703990b291..bbf1deed7f3b 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -238,14 +238,25 @@ static void mt7601u_complete_tx(struct urb *urb)
struct sk_buff *skb;
unsigned long flags;
- spin_lock_irqsave(&dev->tx_lock, flags);
+ switch (urb->status) {
+ case -ECONNRESET:
+ case -ESHUTDOWN:
+ case -ENOENT:
+ return;
+ default:
+ dev_err_ratelimited(dev->dev, "tx urb failed: %d\n",
+ urb->status);
+ /* fall through */
+ case 0:
+ break;
+ }
- if (mt7601u_urb_has_error(urb))
- dev_err(dev->dev, "Error: TX urb failed:%d\n", urb->status);
+ spin_lock_irqsave(&dev->tx_lock, flags);
if (WARN_ONCE(q->e[q->start].urb != urb, "TX urb mismatch"))
goto out;
skb = q->e[q->start].skb;
+ q->e[q->start].skb = NULL;
trace_mt_tx_dma_done(dev, skb);
__skb_queue_tail(&dev->tx_skb_done, skb);
@@ -446,10 +457,10 @@ static void mt7601u_free_tx_queue(struct mt7601u_tx_queue *q)
{
int i;
- WARN_ON(q->used);
-
for (i = 0; i < q->entries; i++) {
usb_poison_urb(q->e[i].urb);
+ if (q->e[i].skb)
+ mt7601u_tx_status(q->dev, q->e[i].skb);
usb_free_urb(q->e[i].urb);
}
}
@@ -463,6 +474,7 @@ static void mt7601u_free_tx(struct mt7601u_dev *dev)
for (i = 0; i < __MT_EP_OUT_MAX; i++)
mt7601u_free_tx_queue(&dev->tx_q[i]);
+ tasklet_kill(&dev->tx_tasklet);
}
static int mt7601u_alloc_tx_queue(struct mt7601u_dev *dev,
@@ -528,6 +540,4 @@ void mt7601u_dma_cleanup(struct mt7601u_dev *dev)
mt7601u_free_rx(dev);
mt7601u_free_tx(dev);
-
- tasklet_kill(&dev->tx_tasklet);
}
diff --git a/drivers/net/wireless/mediatek/mt7601u/tx.c b/drivers/net/wireless/mediatek/mt7601u/tx.c
index 3600e911a63e..4d81c45722fb 100644
--- a/drivers/net/wireless/mediatek/mt7601u/tx.c
+++ b/drivers/net/wireless/mediatek/mt7601u/tx.c
@@ -117,9 +117,9 @@ void mt7601u_tx_status(struct mt7601u_dev *dev, struct sk_buff *skb)
info->status.rates[0].idx = -1;
info->flags |= IEEE80211_TX_STAT_ACK;
- spin_lock(&dev->mac_lock);
+ spin_lock_bh(&dev->mac_lock);
ieee80211_tx_status(dev->hw, skb);
- spin_unlock(&dev->mac_lock);
+ spin_unlock_bh(&dev->mac_lock);
}
static int mt7601u_skb_rooms(struct mt7601u_dev *dev, struct sk_buff *skb)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Lorenzo Bianconi @ 2019-06-06 16:19 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Ryder Lee, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek,
Linux Kernel Mailing List
In-Reply-To: <ade7ef01-8b06-ec7d-4caf-e581f4033819@newmedia-net.de>
>
> i tested your patch against a qca 9984 chipset using SAE and without
> encryption. both did not work. the devices are connecting, but no data
> connection is possible
Hi Sebastian,
I tested Ryder's patch using mt76x2 as mesh peer and it works fine for me.
Could you please provide some more info?
Regards,
Lorenzo
>
>
> Sebastian
>
> Am 03.06.2019 um 08:08 schrieb Ryder Lee:
> > Enable NL80211_IFTYPE_MESH_POINT and update its path.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > Changes since v3 - fix a wrong expression
> > Changes since v2 - remove unused definitions
> > ---
> > drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> > drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> > drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
> > drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
> > 4 files changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > index 59f604f3161f..f860af6a42da 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> > @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
> > {
> > .max = MT7615_MAX_INTERFACES,
> > .types = BIT(NL80211_IFTYPE_AP) |
> > +#ifdef CONFIG_MAC80211_MESH
> > + BIT(NL80211_IFTYPE_MESH_POINT) |
> > +#endif
> > BIT(NL80211_IFTYPE_STATION)
> > }
> > };
> > @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
> > dev->mt76.antenna_mask = 0xf;
> >
> > wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> > +#ifdef CONFIG_MAC80211_MESH
> > + BIT(NL80211_IFTYPE_MESH_POINT) |
> > +#endif
> > BIT(NL80211_IFTYPE_AP);
> >
> > ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > index b0bb7cc12385..585e67fa2728 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> > @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
> >
> > switch (type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > /* ap use hw bssid 0 and ext bssid */
> > if (~mask & BIT(HW_BSSID_0))
> > return HW_BSSID_0;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > index 43f70195244c..e82297048449 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> > @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
> >
> > switch (vif->type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > tx_wlan_idx = mvif->sta.wcid.idx;
> > conn_type = CONNECTION_INFRA_AP;
> > break;
> > @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> > .rx_wtbl = {
> > .tag = cpu_to_le16(WTBL_RX),
> > .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> > - .rca1 = vif->type != NL80211_IFTYPE_AP,
> > + .rca1 = vif->type == NL80211_IFTYPE_STATION,
> > .rca2 = 1,
> > .rv = 1,
> > },
> > @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
> > {
> > switch (type) {
> > case NL80211_IFTYPE_AP:
> > + case NL80211_IFTYPE_MESH_POINT:
> > if (conn_type)
> > *conn_type = CONNECTION_INFRA_STA;
> > break;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> > index e96efb13fa4d..0915cb735699 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
> > @@ -105,25 +105,19 @@ enum {
> > #define STA_TYPE_STA BIT(0)
> > #define STA_TYPE_AP BIT(1)
> > #define STA_TYPE_ADHOC BIT(2)
> > -#define STA_TYPE_TDLS BIT(3)
> > #define STA_TYPE_WDS BIT(4)
> > #define STA_TYPE_BC BIT(5)
> >
> > #define NETWORK_INFRA BIT(16)
> > #define NETWORK_P2P BIT(17)
> > #define NETWORK_IBSS BIT(18)
> > -#define NETWORK_MESH BIT(19)
> > -#define NETWORK_BOW BIT(20)
> > #define NETWORK_WDS BIT(21)
> >
> > #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
> > #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
> > #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
> > #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
> > -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
> > -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
> > #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
> > -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
> > #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
> > #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
> >
^ permalink raw reply
* Help with encrypting PMF management frames
From: Ben Greear @ 2019-06-06 16:54 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hello,
My variant of ath10k uses the normal 'native-wifi' tx path for management frames.
Internally in the firmware, it seems that the management TID is flagged to expect
raw frames, and I think that is why I see Action frames on-air that are not actually
encrypted but which have some space added to their packet that should be filled in by
the hw-crypt engine.
Is there a way to get mac80211 to software-crypt just management-tid PMF frames?
So far, I have not been able to find the correct place in the tx logic of
mac80211...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Tom Psyborg @ 2019-06-06 18:41 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <c8484254-f4f7-9955-e3f8-8a423cc6c325@codeaurora.org>
On 31/05/2019, Manikanta Pubbisetty <mpubbise@codeaurora.org> wrote:
>
> On 5/14/2019 2:08 PM, Johannes Berg wrote:
>> On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote:
>>> +++ b/net/mac80211/util.c
>>> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct
>>> ieee80211_sub_if_data *sdata,
>>> }
>>>
>>> /* Always allow software iftypes */
>>> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) {
>>> + if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
>>> + (iftype == NL80211_IFTYPE_AP_VLAN &&
>>> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
>>> if (radar_detect)
>>> return -EINVAL;
>> Shouldn't this check if 4addr is actually enabled too, like here:
>
>
> Sure Johannes, I'll look into it.
>
>
>>> case NETDEV_PRE_UP:
>>> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
>>> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
>>> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
>>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
>>> + wdev->use_4addr))
>>> return notifier_from_errno(-EOPNOTSUPP);
>> ?
>> Or is there some reason it doesn't matter?
>>
>>> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff
>>> *skb, struct genl_info *info)
>>> return err;
>>> }
>>>
>>> + if (!(rdev->wiphy.interface_modes & (1 << type)) &&
>>> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
>>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
>>> + return -EOPNOTSUPP;
>>> +
>> I also wonder if we shouldn't go "all in" and actually make the check
>> something like
>>
>> check_interface_allowed(iftype, 4addr):
>> if (iftype == AP_VLAN && 4addr)
>> return wiphy.flags & WIPHY_FLAG_4ADDR_AP;
>>
>> else return wiphy.interface_modes & BIT(iftype);
>>
>> i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN
>> interfaces", rather than "also allow it in this case".
>>
>> That would seem like the clearer semantics to me?
>
>
> Yeah, it can be better; I'll check if this is feasible.
>
>
> Thanks,
>
> Manikanta
>
>
Hi
Applying this patch instead of v1 broke WDS operation between two
Litebeam AC Gen2 devices:
Thu Jun 6 19:38:43 2019 kern.info kernel: [ 625.840896] device
wlan0.sta1 left promiscuous mode
Thu Jun 6 19:38:43 2019 kern.info kernel: [ 625.846146] br-lan: port
3(wlan0.sta1) entered disabled state
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.854349]
------------[ cut here ]------------
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.859253] WARNING:
CPU: 0 PID: 1417 at backports-4.19.32-1/net/mac80211/key.c:907
ieee80211_free_keys+0x170/0x228 [mac80211]
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.870871] Modules
linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci
ath10k_core ath pppox ppp_generic mac80211 iptable_nat iptable_mangle
iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables cfg80211 xt_time
xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit
xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD
x_tables thermal_sys slhc nf_reject_ipv4 nf_nat_redirect
nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat
nf_log_ipv4 nf_log_common nf_flow_table_hw nf_flow_table
nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack hwmon crc_ccitt
compat ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base
usb_common
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.930674] CPU: 0 PID:
1417 Comm: hostapd Not tainted 4.14.118 #0
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.936958] Stack :
804d0000 80489150 00000000 00000000 80460fc0 82e79a9c 82e9d35c
804b1307
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.945494]
8045d190 00000589 80603670 0000038b 804838a0 00000001 82e79a50
688195c4
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.954197]
00000000 00000000 80600000 00003dd0 00000000 00000000 00000008
00000000
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.962745]
000000c8 d9e4e916 000000c7 00000000 80000000 00000000 83266130
83234cfc
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.971247]
00000009 0000038b 804838a0 00000100 00000001 8026bd44 00000000
80600000
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.979754] ...
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.982249] Call Trace:
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.984764] [<8006a9ec>]
show_stack+0x58/0x100
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.989305] [<80085080>]
__warn+0xe4/0x118
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.993492] [<80085144>]
warn_slowpath_null+0x1c/0x28
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.998793] [<83234cfc>]
ieee80211_free_keys+0x170/0x228 [mac80211]
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.005308] [<8321611c>]
ieee80211_ibss_leave+0xa70/0x1940 [mac80211]
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.011970] [<802f4998>]
rollback_registered_many+0x2dc/0x414
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.017813] [<802f60b0>]
unregister_netdevice_queue+0x94/0xec
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.023762] [<8321fd8c>]
ieee80211_nan_func_match+0x2894/0x29a0 [mac80211]
Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.030795] ---[ end
trace 5309fee2cf0ee39d ]---
Thu Jun 6 19:38:43 2019 daemon.notice hostapd: wlan0:
WDS-STA-INTERFACE-REMOVED ifname=wlan0.sta1 sta_addr=18:e8:29:30:9b:2c
Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA
18:e8:29:30:9b:2c IEEE 802.11: authenticated
Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA
18:e8:29:30:9b:2c IEEE 802.11: associated (aid 1)
Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.114522] br-lan: port
3(wlan0.sta1) entered blocking state
Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.120364] br-lan: port
3(wlan0.sta1) entered disabled state
Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.126603] device
wlan0.sta1 entered promiscuous mode
Thu Jun 6 19:38:48 2019 daemon.notice hostapd: wlan0:
WDS-STA-INTERFACE-ADDED ifname=wlan0.sta1 sta_addr=18:e8:29:30:9b:2c
Thu Jun 6 19:38:48 2019 daemon.err hostapd: Could not set interface
wlan0.sta1 flags (UP): Invalid argument
Thu Jun 6 19:38:48 2019 daemon.err hostapd: nl80211: Failed to set
WDS STA interface wlan0.sta1 up
Thu Jun 6 19:38:48 2019 daemon.err hostapd: nl80211:
NL80211_ATTR_STA_VLAN (addr=18:e8:29:30:9b:2c ifname=wlan0.sta1
vlan_id=0) failed: -127 (Network is down)
Thu Jun 6 19:38:48 2019 daemon.notice hostapd: wlan0:
AP-STA-CONNECTED 18:e8:29:30:9b:2c
Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA
18:e8:29:30:9b:2c WPA: pairwise key handshake completed (RSN)
Reverting v1 of the patch restored connection.
Regards, Tom
^ permalink raw reply
* Re: [PATCH] mt7601u: fix possible memory leak when the device is disconnected
From: Jakub Kicinski @ 2019-06-06 18:48 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, lorenzo.bianconi
In-Reply-To: <27c6d00cfb5936978cfb8304c6e1f03973905848.1559835089.git.lorenzo@kernel.org>
On Thu, 6 Jun 2019 17:34:16 +0200, Lorenzo Bianconi wrote:
> When the device is disconnected while passing traffic it is possible
> to receive out of order urbs causing a memory leak since the skb liked
> to the current tx urb is not removed. Fix the issue deallocating the skb
> cleaning up the tx ring. Moreover this patch fixes the following kernel
> warning
Ugh if we don't have ordering guarantees then the entire "ring" scheme
no longer works :( Should we move to URB queues, I don't remember now,
but there seem to had been a better way to manage URBs :S
> [ 57.480771] usb 1-1: USB disconnect, device number 2
> [ 57.483451] ------------[ cut here ]------------
> [ 57.483462] TX urb mismatch
> [ 57.483481] WARNING: CPU: 1 PID: 32 at drivers/net/wireless/mediatek/mt7601u/dma.c:245 mt7601u_complete_tx+0x165/00
> [ 57.483483] Modules linked in:
> [ 57.483496] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #72
> [ 57.483498] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
> [ 57.483502] Workqueue: usb_hub_wq hub_event
> [ 57.483507] RIP: 0010:mt7601u_complete_tx+0x165/0x1e0
> [ 57.483510] Code: 8b b5 10 04 00 00 8b 8d 14 04 00 00 eb 8b 80 3d b1 cb e1 00 00 75 9e 48 c7 c7 a4 ea 05 82 c6 05 f
> [ 57.483513] RSP: 0000:ffffc900000a0d28 EFLAGS: 00010092
> [ 57.483516] RAX: 000000000000000f RBX: ffff88802c0a62c0 RCX: ffffc900000a0c2c
> [ 57.483518] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff810a8371
> [ 57.483520] RBP: ffff88803ced6858 R08: 0000000000000000 R09: 0000000000000001
> [ 57.483540] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000046
> [ 57.483542] R13: ffff88802c0a6c88 R14: ffff88803baab540 R15: ffff88803a0cc078
> [ 57.483548] FS: 0000000000000000(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000
> [ 57.483550] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 57.483552] CR2: 000055e7f6780100 CR3: 0000000028c86000 CR4: 00000000000006a0
> [ 57.483554] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 57.483556] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 57.483559] Call Trace:
> [ 57.483561] <IRQ>
> [ 57.483565] __usb_hcd_giveback_urb+0x77/0xe0
> [ 57.483570] xhci_giveback_urb_in_irq.isra.0+0x8b/0x140
> [ 57.483574] handle_cmd_completion+0xf5b/0x12c0
> [ 57.483577] xhci_irq+0x1f6/0x1810
> [ 57.483581] ? lockdep_hardirqs_on+0x9e/0x180
> [ 57.483584] ? _raw_spin_unlock_irq+0x24/0x30
> [ 57.483588] __handle_irq_event_percpu+0x3a/0x260
> [ 57.483592] handle_irq_event_percpu+0x1c/0x60
> [ 57.483595] handle_irq_event+0x2f/0x4c
> [ 57.483599] handle_edge_irq+0x7e/0x1a0
> [ 57.483603] handle_irq+0x17/0x20
> [ 57.483607] do_IRQ+0x54/0x110
> [ 57.483610] common_interrupt+0xf/0xf
> [ 57.483612] </IRQ>
>
> Fixes: c869f77d6abb ("add mt7601u driver")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt7601u/dma.c | 24 +++++++++++++++------
> drivers/net/wireless/mediatek/mt7601u/tx.c | 4 ++--
> 2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
> index e7703990b291..bbf1deed7f3b 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/dma.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
> @@ -238,14 +238,25 @@ static void mt7601u_complete_tx(struct urb *urb)
> struct sk_buff *skb;
> unsigned long flags;
>
> - spin_lock_irqsave(&dev->tx_lock, flags);
> + switch (urb->status) {
> + case -ECONNRESET:
> + case -ESHUTDOWN:
> + case -ENOENT:
> + return;
> + default:
> + dev_err_ratelimited(dev->dev, "tx urb failed: %d\n",
> + urb->status);
> + /* fall through */
> + case 0:
> + break;
> + }
>
> - if (mt7601u_urb_has_error(urb))
> - dev_err(dev->dev, "Error: TX urb failed:%d\n", urb->status);
> + spin_lock_irqsave(&dev->tx_lock, flags);
> if (WARN_ONCE(q->e[q->start].urb != urb, "TX urb mismatch"))
> goto out;
>
> skb = q->e[q->start].skb;
> + q->e[q->start].skb = NULL;
> trace_mt_tx_dma_done(dev, skb);
>
> __skb_queue_tail(&dev->tx_skb_done, skb);
> @@ -446,10 +457,10 @@ static void mt7601u_free_tx_queue(struct mt7601u_tx_queue *q)
> {
> int i;
>
> - WARN_ON(q->used);
> -
> for (i = 0; i < q->entries; i++) {
> usb_poison_urb(q->e[i].urb);
> + if (q->e[i].skb)
> + mt7601u_tx_status(q->dev, q->e[i].skb);
Perhaps a separate patch?
> usb_free_urb(q->e[i].urb);
> }
> }
> @@ -463,6 +474,7 @@ static void mt7601u_free_tx(struct mt7601u_dev *dev)
>
> for (i = 0; i < __MT_EP_OUT_MAX; i++)
> mt7601u_free_tx_queue(&dev->tx_q[i]);
> + tasklet_kill(&dev->tx_tasklet);
> }
>
> static int mt7601u_alloc_tx_queue(struct mt7601u_dev *dev,
> @@ -528,6 +540,4 @@ void mt7601u_dma_cleanup(struct mt7601u_dev *dev)
>
> mt7601u_free_rx(dev);
> mt7601u_free_tx(dev);
> -
> - tasklet_kill(&dev->tx_tasklet);
> }
> diff --git a/drivers/net/wireless/mediatek/mt7601u/tx.c b/drivers/net/wireless/mediatek/mt7601u/tx.c
> index 3600e911a63e..4d81c45722fb 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/tx.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/tx.c
> @@ -117,9 +117,9 @@ void mt7601u_tx_status(struct mt7601u_dev *dev, struct sk_buff *skb)
> info->status.rates[0].idx = -1;
> info->flags |= IEEE80211_TX_STAT_ACK;
>
> - spin_lock(&dev->mac_lock);
> + spin_lock_bh(&dev->mac_lock);
> ieee80211_tx_status(dev->hw, skb);
> - spin_unlock(&dev->mac_lock);
> + spin_unlock_bh(&dev->mac_lock);
> }
>
> static int mt7601u_skb_rooms(struct mt7601u_dev *dev, struct sk_buff *skb)
^ permalink raw reply
* Re: [PATCH] mt7601u: do not schedule rx_tasklet when the device has been disconnected
From: Jakub Kicinski @ 2019-06-06 18:42 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, lorenzo.bianconi
In-Reply-To: <a3c72b07e229e1d16e93438d741d69abba6a18cf.1559822991.git.lorenzo@kernel.org>
On Thu, 6 Jun 2019 14:26:12 +0200, Lorenzo Bianconi wrote:
> Do not schedule rx_tasklet when the usb dongle is disconnected. This
> patch fixes the common kernel warning reported when the device is
> removed.
>
> [ 24.921354] usb 3-14: USB disconnect, device number 7
> [ 24.921593] ------------[ cut here ]------------
> [ 24.921594] RX urb mismatch
> [ 24.921675] WARNING: CPU: 4 PID: 163 at drivers/net/wireless/mediatek/mt7601u/dma.c:200 mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
> [ 24.921769] CPU: 4 PID: 163 Comm: kworker/4:2 Tainted: G OE 4.19.31-041931-generic #201903231635
> [ 24.921770] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.30 05/23/2014
> [ 24.921782] Workqueue: usb_hub_wq hub_event
> [ 24.921797] RIP: 0010:mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
> [ 24.921800] RSP: 0018:ffff9bd9cfd03d08 EFLAGS: 00010086
> [ 24.921802] RAX: 0000000000000000 RBX: ffff9bd9bf043540 RCX: 0000000000000006
> [ 24.921803] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff9bd9cfd16420
> [ 24.921804] RBP: ffff9bd9cfd03d28 R08: 0000000000000002 R09: 00000000000003a8
> [ 24.921805] R10: 0000002f485fca34 R11: 0000000000000000 R12: ffff9bd9bf043c1c
> [ 24.921806] R13: ffff9bd9c62fa3c0 R14: 0000000000000082 R15: 0000000000000000
> [ 24.921807] FS: 0000000000000000(0000) GS:ffff9bd9cfd00000(0000) knlGS:0000000000000000
> [ 24.921808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 24.921808] CR2: 00007fb2648b0000 CR3: 0000000142c0a004 CR4: 00000000001606e0
> [ 24.921809] Call Trace:
> [ 24.921812] <IRQ>
> [ 24.921819] __usb_hcd_giveback_urb+0x8b/0x140
> [ 24.921821] usb_hcd_giveback_urb+0xca/0xe0
> [ 24.921828] xhci_giveback_urb_in_irq.isra.42+0x82/0xf0
> [ 24.921834] handle_cmd_completion+0xe02/0x10d0
> [ 24.921837] xhci_irq+0x274/0x4a0
> [ 24.921838] xhci_msi_irq+0x11/0x20
> [ 24.921851] __handle_irq_event_percpu+0x44/0x190
> [ 24.921856] handle_irq_event_percpu+0x32/0x80
> [ 24.921861] handle_irq_event+0x3b/0x5a
> [ 24.921867] handle_edge_irq+0x80/0x190
> [ 24.921874] handle_irq+0x20/0x30
> [ 24.921889] do_IRQ+0x4e/0xe0
> [ 24.921891] common_interrupt+0xf/0xf
> [ 24.921892] </IRQ>
> [ 24.921900] RIP: 0010:usb_hcd_flush_endpoint+0x78/0x180
> [ 24.921354] usb 3-14: USB disconnect, device number 7
Is this a new thing? I def tested unplugging the dongle under
traffic, but that must had been in 3.19 days :S
> Fixes: c869f77d6abb ("add mt7601u driver")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> I will post a patch to fix tx side as well
> ---
> drivers/net/wireless/mediatek/mt7601u/dma.c | 33 ++++++++++-----------
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
> index f7edeffb2b19..e7703990b291 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/dma.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
> @@ -193,10 +193,20 @@ static void mt7601u_complete_rx(struct urb *urb)
> struct mt7601u_rx_queue *q = &dev->rx_q;
> unsigned long flags;
>
> - spin_lock_irqsave(&dev->rx_lock, flags);
> + switch (urb->status) {
> + case -ECONNRESET:
> + case -ESHUTDOWN:
> + case -ENOENT:
> + return;
So we assume this is non-recoverable? Everything will fail after?
Because pending is incremented linearly :S That's why there is a
warning here.
> + default:
> + dev_err_ratelimited(dev->dev, "rx urb failed: %d\n",
> + urb->status);
> + /* fall through */
> + case 0:
> + break;
> + }
>
> - if (mt7601u_urb_has_error(urb))
> - dev_err(dev->dev, "Error: RX urb failed:%d\n", urb->status);
> + spin_lock_irqsave(&dev->rx_lock, flags);
> if (WARN_ONCE(q->e[q->end].urb != urb, "RX urb mismatch"))
> goto out;
>
> @@ -363,19 +373,10 @@ int mt7601u_dma_enqueue_tx(struct mt7601u_dev *dev, struct sk_buff *skb,
> static void mt7601u_kill_rx(struct mt7601u_dev *dev)
> {
> int i;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&dev->rx_lock, flags);
>
> - for (i = 0; i < dev->rx_q.entries; i++) {
> - int next = dev->rx_q.end;
> -
> - spin_unlock_irqrestore(&dev->rx_lock, flags);
> - usb_poison_urb(dev->rx_q.e[next].urb);
> - spin_lock_irqsave(&dev->rx_lock, flags);
> - }
Why is there no need to take the lock? Admittedly it's not clear what
this lock is protecting here :P Perhaps a separate patch to remove the
unnecessary locking with an explanation?
> - spin_unlock_irqrestore(&dev->rx_lock, flags);
> + for (i = 0; i < dev->rx_q.entries; i++)
> + usb_poison_urb(dev->rx_q.e[i].urb);
> + tasklet_kill(&dev->rx_tasklet);
> }
>
> static int mt7601u_submit_rx_buf(struct mt7601u_dev *dev,
> @@ -525,8 +526,6 @@ void mt7601u_dma_cleanup(struct mt7601u_dev *dev)
> {
> mt7601u_kill_rx(dev);
>
> - tasklet_kill(&dev->rx_tasklet);
Why the move? Looks a bit unnecessary..
> mt7601u_free_rx(dev);
> mt7601u_free_tx(dev);
>
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Larry Finger @ 2019-06-06 19:26 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt
Cc: Aaro Koskinen, Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <20190606114325.GA7497@lst.de>
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
> On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
>>> Wow... that's an odd amount. One thing we could possibly do is add code
>>> to limit the amount of RAM when we detect that device....
>>
>> Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems based
>> on detecting the presence of that device in the device-tree.
>
> swiotlb doesn't really help you, as these days swiotlb on matters for
> the dma_map* case. What would help is a ZONE_DMA that covers these
> devices. No need to do the 24-bit x86 does, but 30-bit would do it.
>
> WIP patch for testing below:
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index b8286a2013b4..7a367ce87c41 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -319,6 +319,10 @@ struct vm_area_struct;
> #endif /* __ASSEMBLY__ */
> #include <asm/slice.h>
>
> +#if 1 /* XXX: pmac? dynamic discovery? */
> +#define ARCH_ZONE_DMA_BITS 30
> +#else
> #define ARCH_ZONE_DMA_BITS 31
> +#endif
>
> #endif /* _ASM_POWERPC_PAGE_H */
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index cba29131bccc..2540d3b2588c 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -248,7 +248,8 @@ void __init paging_init(void)
> (long int)((top_of_ram - total_ram) >> 20));
>
> #ifdef CONFIG_ZONE_DMA
> - max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
> + max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
> + ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
> #endif
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> #ifdef CONFIG_HIGHMEM
>
I am generating a test kernel with this patch.
FYI, the "free" command on my machine shows 1.5+ G of memory. That likely means
I have 2G installed.
I have tested a patched kernel in which b43legacy falls back to a 31-bit DMA
mask when the 32-bit one failed. That worked, but would likely kill the x86
version. Let me know if think a fix in the driver rather than the kernel would
be better. I still need to understand why the same setup works in b43 and fails
in b43legacy. :(
Larry
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Larry Finger @ 2019-06-06 20:11 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt
Cc: Aaro Koskinen, Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <20190606114325.GA7497@lst.de>
On 6/6/19 6:43 AM, Christoph Hellwig wrote:
> On Thu, Jun 06, 2019 at 08:57:49PM +1000, Benjamin Herrenschmidt wrote:
>>> Wow... that's an odd amount. One thing we could possibly do is add code
>>> to limit the amount of RAM when we detect that device....
>>
>> Sent too quickly... I mean that *or* force swiotlb at 30-bits on those systems based
>> on detecting the presence of that device in the device-tree.
>
> swiotlb doesn't really help you, as these days swiotlb on matters for
> the dma_map* case. What would help is a ZONE_DMA that covers these
> devices. No need to do the 24-bit x86 does, but 30-bit would do it.
>
> WIP patch for testing below:
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index b8286a2013b4..7a367ce87c41 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -319,6 +319,10 @@ struct vm_area_struct;
> #endif /* __ASSEMBLY__ */
> #include <asm/slice.h>
>
> +#if 1 /* XXX: pmac? dynamic discovery? */
> +#define ARCH_ZONE_DMA_BITS 30
> +#else
> #define ARCH_ZONE_DMA_BITS 31
> +#endif
>
> #endif /* _ASM_POWERPC_PAGE_H */
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index cba29131bccc..2540d3b2588c 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -248,7 +248,8 @@ void __init paging_init(void)
> (long int)((top_of_ram - total_ram) >> 20));
>
> #ifdef CONFIG_ZONE_DMA
> - max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
> + max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
> + ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
> #endif
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> #ifdef CONFIG_HIGHMEM
>
This trial patch failed.
Larry
^ permalink raw reply
* Hi Jaganath
From: TG Kiran @ 2019-06-06 20:39 UTC (permalink / raw)
To: Jaganath Vemala, linux wireless, maheshkumar shiv, maheshrpc2002,
tg kiran, tgkiran, vijaya raghavan
Hi Jaganath
http://namasterestoran.ee/locate.php?rqyn=EOW9901
Thanks so much
TG Kiran
^ permalink raw reply
* Re: [PATCH] mt7601u: do not schedule rx_tasklet when the device has been disconnected
From: Lorenzo Bianconi @ 2019-06-06 21:02 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Lorenzo Bianconi, linux-wireless
In-Reply-To: <20190606114228.7a0ba115@cakuba.netronome.com>
>
> On Thu, 6 Jun 2019 14:26:12 +0200, Lorenzo Bianconi wrote:
> > Do not schedule rx_tasklet when the usb dongle is disconnected. This
> > patch fixes the common kernel warning reported when the device is
> > removed.
> >
> > [ 24.921354] usb 3-14: USB disconnect, device number 7
> > [ 24.921593] ------------[ cut here ]------------
> > [ 24.921594] RX urb mismatch
> > [ 24.921675] WARNING: CPU: 4 PID: 163 at drivers/net/wireless/mediatek/mt7601u/dma.c:200 mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
> > [ 24.921769] CPU: 4 PID: 163 Comm: kworker/4:2 Tainted: G OE 4.19.31-041931-generic #201903231635
> > [ 24.921770] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.30 05/23/2014
> > [ 24.921782] Workqueue: usb_hub_wq hub_event
> > [ 24.921797] RIP: 0010:mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
> > [ 24.921800] RSP: 0018:ffff9bd9cfd03d08 EFLAGS: 00010086
> > [ 24.921802] RAX: 0000000000000000 RBX: ffff9bd9bf043540 RCX: 0000000000000006
> > [ 24.921803] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff9bd9cfd16420
> > [ 24.921804] RBP: ffff9bd9cfd03d28 R08: 0000000000000002 R09: 00000000000003a8
> > [ 24.921805] R10: 0000002f485fca34 R11: 0000000000000000 R12: ffff9bd9bf043c1c
> > [ 24.921806] R13: ffff9bd9c62fa3c0 R14: 0000000000000082 R15: 0000000000000000
> > [ 24.921807] FS: 0000000000000000(0000) GS:ffff9bd9cfd00000(0000) knlGS:0000000000000000
> > [ 24.921808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 24.921808] CR2: 00007fb2648b0000 CR3: 0000000142c0a004 CR4: 00000000001606e0
> > [ 24.921809] Call Trace:
> > [ 24.921812] <IRQ>
> > [ 24.921819] __usb_hcd_giveback_urb+0x8b/0x140
> > [ 24.921821] usb_hcd_giveback_urb+0xca/0xe0
> > [ 24.921828] xhci_giveback_urb_in_irq.isra.42+0x82/0xf0
> > [ 24.921834] handle_cmd_completion+0xe02/0x10d0
> > [ 24.921837] xhci_irq+0x274/0x4a0
> > [ 24.921838] xhci_msi_irq+0x11/0x20
> > [ 24.921851] __handle_irq_event_percpu+0x44/0x190
> > [ 24.921856] handle_irq_event_percpu+0x32/0x80
> > [ 24.921861] handle_irq_event+0x3b/0x5a
> > [ 24.921867] handle_edge_irq+0x80/0x190
> > [ 24.921874] handle_irq+0x20/0x30
> > [ 24.921889] do_IRQ+0x4e/0xe0
> > [ 24.921891] common_interrupt+0xf/0xf
> > [ 24.921892] </IRQ>
> > [ 24.921900] RIP: 0010:usb_hcd_flush_endpoint+0x78/0x180
> > [ 24.921354] usb 3-14: USB disconnect, device number 7
>
Hi Jakub,
thx for the fast review :)
> Is this a new thing? I def tested unplugging the dongle under
> traffic, but that must had been in 3.19 days :S
>
I do not know if the issue has been introduced in recent kernel, I am
able to trigger it in a vm running
wireless-drivers-next and it has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=203249
> > Fixes: c869f77d6abb ("add mt7601u driver")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > I will post a patch to fix tx side as well
> > ---
> > drivers/net/wireless/mediatek/mt7601u/dma.c | 33 ++++++++++-----------
> > 1 file changed, 16 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
> > index f7edeffb2b19..e7703990b291 100644
> > --- a/drivers/net/wireless/mediatek/mt7601u/dma.c
> > +++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
> > @@ -193,10 +193,20 @@ static void mt7601u_complete_rx(struct urb *urb)
> > struct mt7601u_rx_queue *q = &dev->rx_q;
> > unsigned long flags;
> >
> > - spin_lock_irqsave(&dev->rx_lock, flags);
> > + switch (urb->status) {
> > + case -ECONNRESET:
> > + case -ESHUTDOWN:
> > + case -ENOENT:
> > + return;
>
> So we assume this is non-recoverable? Everything will fail after?
> Because pending is incremented linearly :S That's why there is a
> warning here.
AFAIK -ECONNRESET/-ENOENT are related to urb unlink/kill while
-ESHUTDOWN is related to device disconnection.
I guess we can assume the device has been removed if we get these errors
>
> > + default:
> > + dev_err_ratelimited(dev->dev, "rx urb failed: %d\n",
> > + urb->status);
> > + /* fall through */
> > + case 0:
> > + break;
> > + }
> >
> > - if (mt7601u_urb_has_error(urb))
> > - dev_err(dev->dev, "Error: RX urb failed:%d\n", urb->status);
> > + spin_lock_irqsave(&dev->rx_lock, flags);
> > if (WARN_ONCE(q->e[q->end].urb != urb, "RX urb mismatch"))
> > goto out;
> >
> > @@ -363,19 +373,10 @@ int mt7601u_dma_enqueue_tx(struct mt7601u_dev *dev, struct sk_buff *skb,
> > static void mt7601u_kill_rx(struct mt7601u_dev *dev)
> > {
> > int i;
> > - unsigned long flags;
> > -
> > - spin_lock_irqsave(&dev->rx_lock, flags);
> >
> > - for (i = 0; i < dev->rx_q.entries; i++) {
> > - int next = dev->rx_q.end;
> > -
> > - spin_unlock_irqrestore(&dev->rx_lock, flags);
> > - usb_poison_urb(dev->rx_q.e[next].urb);
> > - spin_lock_irqsave(&dev->rx_lock, flags);
> > - }
>
> Why is there no need to take the lock? Admittedly it's not clear what
> this lock is protecting here :P Perhaps a separate patch to remove the
> unnecessary locking with an explanation?
usb_poison_urb() can run concurrently with urb completion so I guess
we do not need locks here.
I guess we need to maintain this chunk in the same patch since now
when the device is disconnected
we do not increment dev->rx_q.end. What do you think?
>
> > - spin_unlock_irqrestore(&dev->rx_lock, flags);
> > + for (i = 0; i < dev->rx_q.entries; i++)
> > + usb_poison_urb(dev->rx_q.e[i].urb);
> > + tasklet_kill(&dev->rx_tasklet);
> > }
> >
> > static int mt7601u_submit_rx_buf(struct mt7601u_dev *dev,
> > @@ -525,8 +526,6 @@ void mt7601u_dma_cleanup(struct mt7601u_dev *dev)
> > {
> > mt7601u_kill_rx(dev);
> >
> > - tasklet_kill(&dev->rx_tasklet);
>
> Why the move? Looks a bit unnecessary..
>
ack, I will put it back in v2 :)
Regards,
Lorenzo
> > mt7601u_free_rx(dev);
> > mt7601u_free_tx(dev);
> >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox