* [PATCH AUTOSEL 4.4 16/92] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 09ac2694b0475f96be895848687ebcbba97eeecf ]
Syzkaller report this:
[ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
[ 1213.469530] #PF error: [normal kernel read fault]
[ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
[ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
[ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
[ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
[ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
[ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
[ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
[ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
[ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
[ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
[ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
[ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
[ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
[ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1213.473514] PKRU: 55555554
[ 1213.473514] Call Trace:
[ 1213.473514] led_trigger_register+0x112/0x3f0
[ 1213.473514] led_trigger_register_simple+0x7a/0x110
[ 1213.473514] ? 0xffffffffc1c10000
[ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
[ 1213.473514] do_one_initcall+0xbc/0x47d
[ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
[ 1213.473514] do_init_module+0x1b5/0x547
[ 1213.473514] load_module+0x6405/0x8c10
[ 1213.473514] ? module_frob_arch_sections+0x20/0x20
[ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
[ 1213.473514] ? find_held_lock+0x32/0x1c0
[ 1213.473514] ? cap_capable+0x1ae/0x210
[ 1213.473514] ? __do_sys_finit_module+0x162/0x190
[ 1213.473514] __do_sys_finit_module+0x162/0x190
[ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
[ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
[ 1213.473514] ? wait_for_completion+0x370/0x370
[ 1213.473514] ? vfs_write+0x204/0x4a0
[ 1213.473514] ? do_syscall_64+0x18/0x450
[ 1213.473514] do_syscall_64+0x9f/0x450
[ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1213.473514] RIP: 0033:0x462e99
[ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
[ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
[ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
[ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
[ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
[ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
If usb_register failed, no need to call led_trigger_register_simple.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 1264b951463a ("at76c50x-usb: add driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/at76c50x-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index dab25136214a4..da14eca2aa2c8 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2582,8 +2582,8 @@ static int __init at76_mod_init(void)
if (result < 0)
printk(KERN_ERR DRIVER_NAME
": usb_register failed (status %d)\n", result);
-
- led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
+ else
+ led_trigger_register_simple("at76_usb-tx", &ledtrig_tx);
return result;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 17/92] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Sasha Levin @ 2019-05-22 19:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Kalle Valo, Sasha Levin, linux-wireless,
netdev, bpf
In-Reply-To: <20190522193127.27079-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit b2c01aab9646ed8ffb7c549afe55d5349c482425 ]
Syzkaller report this:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 4492 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
RIP: 0010:sysfs_remove_file_ns+0x27/0x70 fs/sysfs/file.c:468
Code: 00 00 00 41 54 55 48 89 fd 53 49 89 d4 48 89 f3 e8 ee 76 9c ff 48 8d 7d 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 2d 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 8b 6d
RSP: 0018:ffff8881e9d9fc00 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffffffff900367e0 RCX: ffffffff81a95952
RDX: 0000000000000006 RSI: ffffc90001405000 RDI: 0000000000000030
RBP: 0000000000000000 R08: fffffbfff1fa22ed R09: fffffbfff1fa22ed
R10: 0000000000000001 R11: fffffbfff1fa22ec R12: 0000000000000000
R13: ffffffffc1abdac0 R14: 1ffff1103d3b3f8b R15: 0000000000000000
FS: 00007fe409dc1700(0000) GS:ffff8881f1200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2d721000 CR3: 00000001e98b6005 CR4: 00000000007606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
sysfs_remove_file include/linux/sysfs.h:519 [inline]
driver_remove_file+0x40/0x50 drivers/base/driver.c:122
pcmcia_remove_newid_file drivers/pcmcia/ds.c:163 [inline]
pcmcia_unregister_driver+0x7d/0x2b0 drivers/pcmcia/ds.c:209
ssb_modexit+0xa/0x1b [ssb]
__do_sys_delete_module kernel/module.c:1018 [inline]
__se_sys_delete_module kernel/module.c:961 [inline]
__x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe409dc0c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe409dc16bc
R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
Modules linked in: ssb(-) 3c59x nvme_core macvlan tap pata_hpt3x3 rt2x00pci null_blk tsc40 pm_notifier_error_inject notifier_error_inject mdio cdc_wdm nf_reject_ipv4 ath9k_common ath9k_hw ath pppox ppp_generic slhc ehci_platform wl12xx wlcore tps6507x_ts ioc4 nf_synproxy_core ide_gd_mod ax25 can_dev iwlwifi can_raw atm tm2_touchkey can_gw can sundance adp5588_keys rt2800mmio rt2800lib rt2x00mmio rt2x00lib eeprom_93cx6 pn533 lru_cache elants_i2c ip_set nfnetlink gameport tipc hampshire nhc_ipv6 nhc_hop nhc_udp nhc_fragment nhc_routing nhc_mobility nhc_dest 6lowpan silead brcmutil nfc mt76_usb mt76 mac80211 iptable_security iptable_raw iptable_mangle iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_gre sit hsr veth vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon vcan bridge stp llc ip6_gre ip6_tunnel tunnel6 tun joydev mousedev serio_raw ide_pci_generic piix floppy ide_core sch_fq_codel ip_tables x_tables ipv6
[last unloaded: 3c59x]
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace 3913cbf8011e1c05 ]---
In ssb_modinit, it does not fail SSB init when ssb_host_pcmcia_init failed,
however in ssb_modexit, ssb_host_pcmcia_exit calls pcmcia_unregister_driver
unconditionally, which may tigger a NULL pointer dereference issue as above.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 399500da18f7 ("ssb: pick PCMCIA host code support from b43 driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ssb/bridge_pcmcia_80211.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/bridge_pcmcia_80211.c b/drivers/ssb/bridge_pcmcia_80211.c
index d70568ea02d53..2ff7d90e166ac 100644
--- a/drivers/ssb/bridge_pcmcia_80211.c
+++ b/drivers/ssb/bridge_pcmcia_80211.c
@@ -113,16 +113,21 @@ static struct pcmcia_driver ssb_host_pcmcia_driver = {
.resume = ssb_host_pcmcia_resume,
};
+static int pcmcia_init_failed;
+
/*
* These are not module init/exit functions!
* The module_pcmcia_driver() helper cannot be used here.
*/
int ssb_host_pcmcia_init(void)
{
- return pcmcia_register_driver(&ssb_host_pcmcia_driver);
+ pcmcia_init_failed = pcmcia_register_driver(&ssb_host_pcmcia_driver);
+
+ return pcmcia_init_failed;
}
void ssb_host_pcmcia_exit(void)
{
- pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
+ if (!pcmcia_init_failed)
+ pcmcia_unregister_driver(&ssb_host_pcmcia_driver);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 020/114] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:28 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522193017.26567-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6e0aa296f1346..d787717140e54 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1072,9 +1072,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 09a353c6373a8..d6e6293157717 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14014,6 +14014,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 038/167] mwifiex: prevent an array overflow
From: Sasha Levin @ 2019-05-22 19:26 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190522192842.25858-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ]
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
index bfe84e55df776..f1522fb1c1e87 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -531,5 +531,8 @@ u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
rate_index = (rx_rate > MWIFIEX_RATE_INDEX_OFDM0) ?
rx_rate - 1 : rx_rate;
+ if (rate_index >= MWIFIEX_MAX_AC_RX_RATES)
+ rate_index = MWIFIEX_MAX_AC_RX_RATES - 1;
+
return rate_index;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 066/317] mac80211/cfg80211: update bss channel on channel switch
From: Sasha Levin @ 2019-05-22 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Matyukevich, Johannes Berg, Sasha Levin, linux-wireless,
netdev
In-Reply-To: <20190522192338.23715-1-sashal@kernel.org>
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ]
FullMAC STAs have no way to update bss channel after CSA channel switch
completion. As a result, user-space tools may provide inconsistent
channel info. For instance, consider the following two commands:
$ sudo iw dev wlan0 link
$ sudo iw dev wlan0 info
The latter command gets channel info from the hardware, so most probably
its output will be correct. However the former command gets channel info
from scan cache, so its output will contain outdated channel info.
In fact, current bss channel info will not be updated until the
next [re-]connect.
Note that mac80211 STAs have a workaround for this, but it requires
access to internal cfg80211 data, see ieee80211_chswitch_work:
/* XXX: shouldn't really modify cfg80211-owned data! */
ifmgd->associated->channel = sdata->csa_chandef.chan;
This patch suggests to convert mac80211 workaround into cfg80211 behavior
and to update current bss channel in cfg80211_ch_switch_notify.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 3 ---
net/wireless/nl80211.c | 5 +++++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 6878215672871..715ab0e6579cb 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1167,9 +1167,6 @@ static void ieee80211_chswitch_work(struct work_struct *work)
goto out;
}
- /* XXX: shouldn't really modify cfg80211-owned data! */
- ifmgd->associated->channel = sdata->csa_chandef.chan;
-
ifmgd->csa_waiting_bcn = true;
ieee80211_sta_reset_beacon_monitor(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 156ce708b5330..0044bfb526abc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15667,6 +15667,11 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
wdev->chandef = *chandef;
wdev->preset_chandef = *chandef;
+
+ if (wdev->iftype == NL80211_IFTYPE_STATION &&
+ !WARN_ON(!wdev->current_bss))
+ wdev->current_bss->pub.channel = chandef->chan;
+
nl80211_ch_switch_notify(rdev, dev, chandef, GFP_KERNEL,
NL80211_CMD_CH_SWITCH_NOTIFY, 0);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 041/375] brcm80211: potential NULL dereference in brcmf_cfg80211_vndr_cmds_dcmd_handler()
From: Sasha Levin @ 2019-05-22 19:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Kalle Valo, Sasha Levin, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev
In-Reply-To: <20190522192115.22666-1-sashal@kernel.org>
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit e025da3d7aa4770bb1d1b3b0aa7cc4da1744852d ]
If "ret_len" is negative then it could lead to a NULL dereference.
The "ret_len" value comes from nl80211_vendor_cmd(), if it's negative
then we don't allocate the "dcmd_buf" buffer. Then we pass "ret_len" to
brcmf_fil_cmd_data_set() where it is cast to a very high u32 value.
Most of the functions in that call tree check whether the buffer we pass
is NULL but there are at least a couple places which don't such as
brcmf_dbg_hex_dump() and brcmf_msgbuf_query_dcmd(). We memcpy() to and
from the buffer so it would result in a NULL dereference.
The fix is to change the types so that "ret_len" can't be negative. (If
we memcpy() zero bytes to NULL, that's a no-op and doesn't cause an
issue).
Fixes: 1bacb0487d0e ("brcmfmac: replace cfg80211 testmode with vendor command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index 8eff2753abade..d493021f60318 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -35,9 +35,10 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
struct brcmf_if *ifp;
const struct brcmf_vndr_dcmd_hdr *cmdhdr = data;
struct sk_buff *reply;
- int ret, payload, ret_len;
+ unsigned int payload, ret_len;
void *dcmd_buf = NULL, *wr_pointer;
u16 msglen, maxmsglen = PAGE_SIZE - 0x100;
+ int ret;
if (len < sizeof(*cmdhdr)) {
brcmf_err("vendor command too short: %d\n", len);
@@ -65,7 +66,7 @@ static int brcmf_cfg80211_vndr_cmds_dcmd_handler(struct wiphy *wiphy,
brcmf_err("oversize return buffer %d\n", ret_len);
ret_len = BRCMF_DCMD_MAXLEN;
}
- payload = max(ret_len, len) + 1;
+ payload = max_t(unsigned int, ret_len, len) + 1;
dcmd_buf = vzalloc(payload);
if (NULL == dcmd_buf)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related
* Logo printing
From: David @ 2019-05-22 11:40 UTC (permalink / raw)
To: linux-wireless
Hi,
Not sure if you received my last email?
Are you interested in purchasing your LOGO promotional and marketing
products for your company?
We produce USB Drives with your Logo Printed or artwork printed to be used
for gifts or marketing.
Here is more info from our website:
We can pre-load your media files, images, presentations and files onto the
drives for you.
Some reasons to get the USB drives from us:
We make Custom Shaped USB drives in the shape of your logo, product or
anything you like.
Our USB drives are Eco-friendly
We supply USB drives to Fortune 100 companies.
We have over 150 styles and colors to choose from.
People will keep the USB drive you give them and show it to others
increasing your marketing value
Please click
to see all of our stock models and get a quote.
If you are nonprofit, have further discounts for schools and charities.
Thanks,
David
USB Drive Specialist
http://walgreens.com/mail/link.php?M=8181310&N=2777&L=65&F=T
^ permalink raw reply
* [PATCH v3] ath10k: add support for firmware crash recovery on SDIO chip
From: Wen Gong @ 2019-05-22 6:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
The command to simulate firmware crash:
echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash
It will send WMI_FORCE_FW_HANG_ASSERT to firmware, then it will trigger
CPU interrupt status register for SDIO chip, ath10k driver need to
configure it while enable SDIO interrupt, otherwise ath10k driver will
not get the assert error info.
After this change, it will success for simulate firmware crash.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
v3: change commit log title
v2: add MBOX_CPU_STATUS_ENABLE_ASSERT_MASK for fw assert check
drivers/net/wireless/ath/ath10k/hw.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..60521ed 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -1095,6 +1095,7 @@ struct ath10k_hw_ops {
#define MBOX_CPU_INT_STATUS_ENABLE_ADDRESS 0x00000819
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_LSB 0
#define MBOX_CPU_INT_STATUS_ENABLE_BIT_MASK 0x000000ff
+#define MBOX_CPU_STATUS_ENABLE_ASSERT_MASK 0x00000001
#define MBOX_ERROR_STATUS_ENABLE_ADDRESS 0x0000081a
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_LSB 1
#define MBOX_ERROR_STATUS_ENABLE_RX_UNDERFLOW_MASK 0x00000002
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index fae56c6..1a3a7bf 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -850,6 +850,10 @@ static int ath10k_sdio_mbox_proc_cpu_intr(struct ath10k *ar)
out:
mutex_unlock(&irq_data->mtx);
+ if (cpu_int_status & MBOX_CPU_STATUS_ENABLE_ASSERT_MASK) {
+ ath10k_err(ar, "firmware crashed!\n");
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
return ret;
}
@@ -1495,8 +1499,10 @@ static int ath10k_sdio_hif_enable_intrs(struct ath10k *ar)
regs->int_status_en |=
FIELD_PREP(MBOX_INT_STATUS_ENABLE_MBOX_DATA_MASK, 1);
- /* Set up the CPU Interrupt status Register */
- regs->cpu_int_status_en = 0;
+ /* Set up the CPU Interrupt Status Register, enable CPU sourced interrupt #0
+ * #0 is used for report assertion from target
+ */
+ regs->cpu_int_status_en = FIELD_PREP(MBOX_CPU_STATUS_ENABLE_ASSERT_MASK, 1);
/* Set up the Error Interrupt status Register */
regs->err_int_status_en =
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2] ath10k: add support for simulate crash on SDIO chip
From: Wen Gong @ 2019-05-22 6:24 UTC (permalink / raw)
To: Claire Chang, Wen Gong
Cc: open list:NETWORKING DRIVERS (WIRELESS),
ath10k@lists.infradead.org
In-Reply-To: <CALiNf29_GwSEUJ_vdp+_1DeDyFZj0uuUY9kYh94w4P_eeDT=8g@mail.gmail.com>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Claire
> Chang
> Sent: Wednesday, May 15, 2019 10:53 AM
> To: Wen Gong <wgong@codeaurora.org>
> Cc: open list:NETWORKING DRIVERS (WIRELESS) <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH v2] ath10k: add support for simulate crash on SDIO
> chip
>
> Tested-by: Claire Chang <tientzu@chromium.org>
>
> If this patch adds support for detecting the real firmware assert,
> maybe the title should be "add support for _crash recovery_ on SDIO
> chip"
Yes, seems this title is more appropriate.
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [PATCH] ath10k: fix fw crash by moving chip reset after napi disabled
From: Miaoqing Pan @ 2019-05-22 2:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Miaoqing Pan
On SMP platform, when continuously running wifi up/down, the napi
poll can be scheduled during chip reset, which will call
ath10k_pci_has_fw_crashed() to check the fw status. But in the reset
period, the value from FW_INDICATOR_ADDRESS register will return
0xdeadbeef, which also be treated as fw crash. Fix the issue by
moving chip reset after napi disabled.
ath10k_pci 0000:01:00.0: firmware crashed! (guid 73b30611-5b1e-4bdd-90b4-64c81eb947b6)
ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1
ath10k_pci 0000:01:00.0: failed to get memcpy hi address for firmware address 4: -16
ath10k_pci 0000:01:00.0: failed to read firmware dump area: -16
ath10k_pci 0000:01:00.0: Copy Engine register dump:
ath10k_pci 0000:01:00.0: [00]: 0x0004a000 0 0 0 0
ath10k_pci 0000:01:00.0: [01]: 0x0004a400 0 0 0 0
ath10k_pci 0000:01:00.0: [02]: 0x0004a800 0 0 0 0
ath10k_pci 0000:01:00.0: [03]: 0x0004ac00 0 0 0 0
ath10k_pci 0000:01:00.0: [04]: 0x0004b000 0 0 0 0
ath10k_pci 0000:01:00.0: [05]: 0x0004b400 0 0 0 0
ath10k_pci 0000:01:00.0: [06]: 0x0004b800 0 0 0 0
ath10k_pci 0000:01:00.0: [07]: 0x0004bc00 1 0 1 0
ath10k_pci 0000:01:00.0: [08]: 0x0004c000 0 0 0 0
ath10k_pci 0000:01:00.0: [09]: 0x0004c400 0 0 0 0
ath10k_pci 0000:01:00.0: [10]: 0x0004c800 0 0 0 0
ath10k_pci 0000:01:00.0: [11]: 0x0004cc00 0 0 0 0
Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00035
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 2bd6cba..80bcb2e 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2059,6 +2059,11 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif stop\n");
+ ath10k_pci_irq_disable(ar);
+ ath10k_pci_irq_sync(ar);
+ napi_synchronize(&ar->napi);
+ napi_disable(&ar->napi);
+
/* Most likely the device has HTT Rx ring configured. The only way to
* prevent the device from accessing (and possible corrupting) host
* memory is to reset the chip now.
@@ -2072,10 +2077,6 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
*/
ath10k_pci_safe_chip_reset(ar);
- ath10k_pci_irq_disable(ar);
- ath10k_pci_irq_sync(ar);
- napi_synchronize(&ar->napi);
- napi_disable(&ar->napi);
ath10k_pci_flush(ar);
spin_lock_irqsave(&ar_pci->ps_lock, flags);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] ath10k: update HOST capability qmi message
From: Bjorn Andersson @ 2019-05-22 1:20 UTC (permalink / raw)
To: Govind Singh; +Cc: ath10k, linux-wireless
In-Reply-To: <20190204115555.17052-1-govinds@codeaurora.org>
On Mon 04 Feb 03:55 PST 2019, Govind Singh wrote:
> HOST capability interface data structures are updated
> in HL3.1 fw version. Update the qmi host capability
> members for compatibility across different firmware
> versions.
> Since this change breaks backward compatibility with
> HL2.0 fw, HL2.0 fw upgrade to WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
> or later version is required.
>
Sorry for not objecting earlier, I confused this with the "msa info req
rejected: 90" error that we see on some 845 devices.
Given that the wlan firmware is signed there's no way for people in the
community to upgrade their firmware, until such version has propagated
through the official channels for the specific device.
As such this patch inhibits the ability of bringing up wifi on devices
such as the Lenovo Yoga C630.
Is there any way we can detect if we're using the "old" firmware?
Regards,
Bjorn
> Testing:
> Tested on QCS404 platform(WCN3990 HW).
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1,
> WLAN.HL.2.0-01617-QCAHLSWMTPLZ-1
> ---
> .../net/wireless/ath/ath10k/qmi_wlfw_v01.c | 229 +++++++++++++++++-
> .../net/wireless/ath/ath10k/qmi_wlfw_v01.h | 34 ++-
> 2 files changed, 257 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> index ba79c2e4aed6..4102f7b0b5c3 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
> @@ -1763,14 +1763,239 @@ struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[] = {
> daemon_support_valid),
> },
> {
> - .data_type = QMI_UNSIGNED_1_BYTE,
> + .data_type = QMI_UNSIGNED_4_BYTE,
> .elem_len = 1,
> - .elem_size = sizeof(u8),
> + .elem_size = sizeof(u32),
> .array_type = NO_ARRAY,
> .tlv_type = 0x10,
> .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> daemon_support),
> },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x11,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + wake_msi_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x11,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + wake_msi),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios_valid),
> + },
> + {
> + .data_type = QMI_DATA_LEN,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios_len),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = QMI_WLFW_MAX_NUM_GPIO_V01,
> + .elem_size = sizeof(u32),
> + .array_type = VAR_LEN_ARRAY,
> + .tlv_type = 0x12,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + gpios),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x13,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + nm_modem_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x13,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + nm_modem),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x14,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x14,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x15,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x15,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + bdf_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x16,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x16,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x17,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x17,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + m3_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x18,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_filesys_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x18,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_filesys_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x19,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_cache_support_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x19,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_cache_support),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1A,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_done_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1A,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + cal_done),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1B,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_bucket_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_4_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u32),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1B,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_bucket),
> + },
> + {
> + .data_type = QMI_OPT_FLAG,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1C,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_cfg_mode_valid),
> + },
> + {
> + .data_type = QMI_UNSIGNED_1_BYTE,
> + .elem_len = 1,
> + .elem_size = sizeof(u8),
> + .array_type = NO_ARRAY,
> + .tlv_type = 0x1C,
> + .offset = offsetof(struct wlfw_host_cap_req_msg_v01,
> + mem_cfg_mode),
> + },
> {}
> };
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> index c5e3870b8871..ff668f5d8afd 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> +++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
> @@ -553,12 +553,38 @@ struct wlfw_mac_addr_resp_msg_v01 {
> #define WLFW_MAC_ADDR_RESP_MSG_V01_MAX_MSG_LEN 7
> extern struct qmi_elem_info wlfw_mac_addr_resp_msg_v01_ei[];
>
> +#define QMI_WLFW_MAX_NUM_GPIO_V01 32
> struct wlfw_host_cap_req_msg_v01 {
> u8 daemon_support_valid;
> - u8 daemon_support;
> -};
> -
> -#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 4
> + u32 daemon_support;
> + u8 wake_msi_valid;
> + u32 wake_msi;
> + u8 gpios_valid;
> + u32 gpios_len;
> + u32 gpios[QMI_WLFW_MAX_NUM_GPIO_V01];
> + u8 nm_modem_valid;
> + u8 nm_modem;
> + u8 bdf_support_valid;
> + u8 bdf_support;
> + u8 bdf_cache_support_valid;
> + u8 bdf_cache_support;
> + u8 m3_support_valid;
> + u8 m3_support;
> + u8 m3_cache_support_valid;
> + u8 m3_cache_support;
> + u8 cal_filesys_support_valid;
> + u8 cal_filesys_support;
> + u8 cal_cache_support_valid;
> + u8 cal_cache_support;
> + u8 cal_done_valid;
> + u8 cal_done;
> + u8 mem_bucket_valid;
> + u32 mem_bucket;
> + u8 mem_cfg_mode_valid;
> + u8 mem_cfg_mode;
> +};
> +
> +#define WLFW_HOST_CAP_REQ_MSG_V01_MAX_MSG_LEN 189
> extern struct qmi_elem_info wlfw_host_cap_req_msg_v01_ei[];
>
> struct wlfw_host_cap_resp_msg_v01 {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: remove redundant masking of pkt_offset
From: Adham.Abozaeid @ 2019-05-21 18:43 UTC (permalink / raw)
To: colin.king, Ajay.Kathat, gregkh, linux-wireless, devel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190521131706.30236-1-colin.king@canonical.com>
On 5/21/19 6:17 AM, Colin King wrote:
> External E-Mail
>
>
> From: Colin Ian King <colin.king@canonical.com>
>
> The masking update of pkg_offset is redundant as the updated
> value is never read and pkg_offset is re-assigned on the next
> iteration of the loop. Clean this up by removing the redundant
> assignment.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Adham Abozaeid <adham.abozaeid@microchip.com>
Thanks,
Adham
> ---
> drivers/staging/wilc1000/wilc_wlan.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index 95eaf8fdf4f2..dcd728557958 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -709,9 +709,6 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8 *buffer, int size)
> break;
>
> if (pkt_offset & IS_MANAGMEMENT) {
> - pkt_offset &= ~(IS_MANAGMEMENT |
> - IS_MANAGMEMENT_CALLBACK |
> - IS_MGMT_STATUS_SUCCES);
> buff_ptr += HOST_HDR_OFFSET;
> wilc_wfi_mgmt_rx(wilc, buff_ptr, pkt_len);
> } else {
^ permalink raw reply
* Re: [RFC PATCH 2/2] rtl8xxxu: Add watchdog to update rate mask by signal strength
From: Daniel Drake @ 2019-05-21 18:38 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAB4CAwf26pdCY7FJA5H7d1aEY2xpjSto4JxARwczmVJ==41yng@mail.gmail.com>
On Fri, May 10, 2019 at 2:37 AM Chris Chiu <chiu@endlessm.com> wrote:
> I've verified that multiple virtual interface can not work simultaneously in
> STA mode. I assigned different mac address for different vifs, I can only
> bring only one interface up. If I want to bring the second vif up, it always
> complains "SIOCSIFFLAGS: Device or resource busy".
Interesting. Can you go deeper into that so that we can be more
confident of this limitation?
ieee80211_open() is the starting point.
ieee80211_check_concurrent_iface() is one candidate to generate -EBUSY
but from inspection, I don't think that's happening in this case,
perhaps you can keep following through in order to figure out which
part of the code is not allowing the 2nd STA interface to come up.
Daniel
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for new channels on 60GHz band
From: Kalle Valo @ 2019-05-21 15:15 UTC (permalink / raw)
To: Alexei Avshalom Lazar; +Cc: Johannes Berg, linux-wireless, wil6210
In-Reply-To: <1558364020-11064-1-git-send-email-ailizaro@codeaurora.org>
Alexei Avshalom Lazar <ailizaro@codeaurora.org> writes:
> The following set of patches add support for new channels on
> 60GHz band and EDMG channels:
> -Nl80211 support for EDMG channels
> -Wil6210 support for EDMG channels
>
> Alexei Avshalom Lazar (2):
> nl80211: Add support for EDMG channels
> wil6210: Add EDMG channel support
Please always add a changelog to help the reviewers:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
Kalle Valo
^ permalink raw reply
* [PATCH 1/2] mac80211: add ieee80211_get_he_iftype_cap() helper
From: John Crispin @ 2019-05-21 15:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k, John Crispin, Shashidhar Lakkavalli
This function is similar to ieee80211_get_he_sta_cap() but allows passing
the iftype. Also make ieee80211_get_he_sta_cap() use the new helper
rather than duplicating the code.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
include/net/cfg80211.h | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 3f67f01b5f7a..379202ff3d14 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -395,16 +395,18 @@ ieee80211_get_sband_iftype_data(const struct ieee80211_supported_band *sband,
}
/**
- * ieee80211_get_he_sta_cap - return HE capabilities for an sband's STA
- * @sband: the sband to search for the STA on
+ * ieee80211_get_he_iftype_cap - return HE capabilities for an sband's iftype
+ * @sband: the sband to search for the iftype on
+ * @iftype: enum nl80211_iftype
*
* Return: pointer to the struct ieee80211_sta_he_cap, or NULL is none found
*/
static inline const struct ieee80211_sta_he_cap *
-ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
+ieee80211_get_he_iftype_cap(const struct ieee80211_supported_band *sband,
+ u8 iftype)
{
const struct ieee80211_sband_iftype_data *data =
- ieee80211_get_sband_iftype_data(sband, NL80211_IFTYPE_STATION);
+ ieee80211_get_sband_iftype_data(sband, iftype);
if (data && data->he_cap.has_he)
return &data->he_cap;
@@ -412,6 +414,18 @@ ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
return NULL;
}
+/**
+ * ieee80211_get_he_sta_cap - return HE capabilities for an sband's STA
+ * @sband: the sband to search for the STA on
+ *
+ * Return: pointer to the struct ieee80211_sta_he_cap, or NULL is none found
+ */
+static inline const struct ieee80211_sta_he_cap *
+ieee80211_get_he_sta_cap(const struct ieee80211_supported_band *sband)
+{
+ return ieee80211_get_he_iftype_cap(sband, NL80211_IFTYPE_STATION);
+}
+
/**
* wiphy_read_of_freq_limits - read frequency limits from device tree
*
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] mac80211: add support for the ADDBA extension element
From: John Crispin @ 2019-05-21 15:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k, John Crispin, Shashidhar Lakkavalli
In-Reply-To: <20190521150259.2414-1-john@phrozen.org>
HE allows peers to negotiate the aggregation fragmentation level to be used
during transmission. The level can be 1-3. The Ext element is added behind
the ADDBA request inside the action frame. The responder will then reply
with the same level or a lower one if the requested one is not supported.
This patch only handles the negotiation part as the ADDBA frames get passed
to the ATH11k firmware, which does the rest of the magic for us aswell as
generating the requests.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
include/linux/ieee80211.h | 15 ++++++++
net/mac80211/agg-rx.c | 73 ++++++++++++++++++++++++++++++++++----
net/mac80211/ht.c | 2 +-
net/mac80211/ieee80211_i.h | 3 +-
4 files changed, 84 insertions(+), 9 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6109aa4024ad..987c0f07397a 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -884,6 +884,18 @@ struct ieee80211_tpc_report_ie {
u8 link_margin;
} __packed;
+#define IEEE80211_ADDBA_EXT_ELEM_ID 0x9f
+#define IEEE80211_ADDBA_EXT_ELEM_ID_LEN 0x01
+#define IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK GENMASK(2, 1)
+#define IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT 1
+#define IEEE80211_ADDBA_EXT_NO_FRAG BIT(0)
+
+struct ieee80211_addbaext {
+ u8 eid;
+ u8 length;
+ u8 data;
+} __packed;
+
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
@@ -976,6 +988,8 @@ struct ieee80211_mgmt {
__le16 capab;
__le16 timeout;
__le16 start_seq_num;
+ /* followed by BA Extension */
+ u8 variable[0];
} __packed addba_req;
struct{
u8 action_code;
@@ -1734,6 +1748,7 @@ int ieee80211_get_vht_max_nss(struct ieee80211_vht_cap *cap,
#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_2 0x10
#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_3 0x18
#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK 0x18
+#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT 3
#define IEEE80211_HE_MAC_CAP0_MAX_NUM_FRAG_MSDU_1 0x00
#define IEEE80211_HE_MAC_CAP0_MAX_NUM_FRAG_MSDU_2 0x20
#define IEEE80211_HE_MAC_CAP0_MAX_NUM_FRAG_MSDU_4 0x40
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 6a4f154c99f6..b7a3d99dc779 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -181,9 +181,57 @@ static void sta_rx_agg_reorder_timer_expired(struct timer_list *t)
rcu_read_unlock();
}
+static void ieee80211_add_addbaext(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb,
+ struct ieee80211_addbaext *req)
+{
+ struct ieee80211_addbaext *resp;
+ struct ieee80211_supported_band *sband;
+ const struct ieee80211_sta_he_cap *he_cap;
+ u8 frag_level, cap_frag_level;
+
+ sband = ieee80211_get_sband(sdata);
+ he_cap = ieee80211_get_he_iftype_cap(sband, sdata->vif.type);
+ if (!he_cap)
+ return;
+
+ resp = skb_put_zero(skb, sizeof(struct ieee80211_addbaext));
+ resp->eid = IEEE80211_ADDBA_EXT_ELEM_ID;
+ resp->length = IEEE80211_ADDBA_EXT_ELEM_ID_LEN;
+ resp->data = req->data & IEEE80211_ADDBA_EXT_NO_FRAG;
+
+ frag_level = (req->data & IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK) >>
+ IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT;
+ cap_frag_level = (he_cap->he_cap_elem.mac_cap_info[0] &
+ IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK) >>
+ IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT;
+ if (frag_level > cap_frag_level)
+ frag_level = cap_frag_level;
+ resp->data |= (frag_level << IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT) &
+ IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK;
+}
+
+static struct ieee80211_addbaext *
+ieee80211_check_addbaext(struct ieee80211_mgmt *mgmt, int len)
+{
+ struct ieee80211_addbaext *addbaext = (struct ieee80211_addbaext *)
+ mgmt->u.action.u.addba_req.variable;
+ int sz = 24 + 1 + sizeof(mgmt->u.action.u.addba_resp);
+
+ if ((len - sz) < sizeof(struct ieee80211_addbaext))
+ return NULL;
+
+ if (addbaext->eid != IEEE80211_ADDBA_EXT_ELEM_ID ||
+ addbaext->length != IEEE80211_ADDBA_EXT_ELEM_ID_LEN)
+ return NULL;
+
+ return addbaext;
+}
+
static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *da, u16 tid,
u8 dialog_token, u16 status, u16 policy,
- u16 buf_size, u16 timeout)
+ u16 buf_size, u16 timeout,
+ struct ieee80211_addbaext *addbaext)
{
struct ieee80211_local *local = sdata->local;
struct sk_buff *skb;
@@ -191,7 +239,9 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
bool amsdu = ieee80211_hw_check(&local->hw, SUPPORTS_AMSDU_IN_AMPDU);
u16 capab;
- skb = dev_alloc_skb(sizeof(*mgmt) + local->hw.extra_tx_headroom);
+ skb = dev_alloc_skb(sizeof(*mgmt) +
+ (addbaext ? sizeof(struct ieee80211_addbaext) : 0) +
+ local->hw.extra_tx_headroom);
if (!skb)
return;
@@ -225,13 +275,17 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
mgmt->u.action.u.addba_resp.timeout = cpu_to_le16(timeout);
mgmt->u.action.u.addba_resp.status = cpu_to_le16(status);
+ if (addbaext)
+ ieee80211_add_addbaext(sdata, skb, addbaext);
+
ieee80211_tx_skb(sdata, skb);
}
void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
u8 dialog_token, u16 timeout,
u16 start_seq_num, u16 ba_policy, u16 tid,
- u16 buf_size, bool tx, bool auto_seq)
+ u16 buf_size, bool tx, bool auto_seq,
+ struct ieee80211_addbaext *addbaext)
{
struct ieee80211_local *local = sta->sdata->local;
struct tid_ampdu_rx *tid_agg_rx;
@@ -415,19 +469,20 @@ void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
if (tx)
ieee80211_send_addba_resp(sta->sdata, sta->sta.addr, tid,
dialog_token, status, 1, buf_size,
- timeout);
+ timeout, addbaext);
}
static void __ieee80211_start_rx_ba_session(struct sta_info *sta,
u8 dialog_token, u16 timeout,
u16 start_seq_num, u16 ba_policy,
u16 tid, u16 buf_size, bool tx,
- bool auto_seq)
+ bool auto_seq,
+ struct ieee80211_addbaext *addbaext)
{
mutex_lock(&sta->ampdu_mlme.mtx);
___ieee80211_start_rx_ba_session(sta, dialog_token, timeout,
start_seq_num, ba_policy, tid,
- buf_size, tx, auto_seq);
+ buf_size, tx, auto_seq, addbaext);
mutex_unlock(&sta->ampdu_mlme.mtx);
}
@@ -437,6 +492,7 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
size_t len)
{
u16 capab, tid, timeout, ba_policy, buf_size, start_seq_num;
+ struct ieee80211_addbaext *addbaext = NULL;
u8 dialog_token;
/* extract session parameters from addba request frame */
@@ -450,9 +506,12 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
tid = (capab & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
+ if (sta->sta.he_cap.has_he)
+ addbaext = ieee80211_check_addbaext(mgmt, len);
+
__ieee80211_start_rx_ba_session(sta, dialog_token, timeout,
start_seq_num, ba_policy, tid,
- buf_size, true, false);
+ buf_size, true, false, addbaext);
}
void ieee80211_manage_rx_ba_offl(struct ieee80211_vif *vif,
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index c62101857b9b..3ea08e7ba0d1 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -362,7 +362,7 @@ void ieee80211_ba_session_work(struct work_struct *work)
sta->ampdu_mlme.tid_rx_manage_offl))
___ieee80211_start_rx_ba_session(sta, 0, 0, 0, 1, tid,
IEEE80211_MAX_AMPDU_BUF_HT,
- false, true);
+ false, true, NULL);
if (test_and_clear_bit(tid + IEEE80211_NUM_TIDS,
sta->ampdu_mlme.tid_rx_manage_offl))
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d82469754d34..4beda46acd0a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1805,7 +1805,8 @@ void __ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
void ___ieee80211_start_rx_ba_session(struct sta_info *sta,
u8 dialog_token, u16 timeout,
u16 start_seq_num, u16 ba_policy, u16 tid,
- u16 buf_size, bool tx, bool auto_seq);
+ u16 buf_size, bool tx, bool auto_seq,
+ struct ieee80211_addbaext *addbaext);
void ieee80211_sta_tear_down_BA_sessions(struct sta_info *sta,
enum ieee80211_agg_stop_reason reason);
void ieee80211_process_delba(struct ieee80211_sub_if_data *sdata,
--
2.20.1
^ permalink raw reply related
* [PATCH] staging: wilc1000: remove redundant masking of pkt_offset
From: Colin King @ 2019-05-21 13:17 UTC (permalink / raw)
To: Adham Abozaeid, Ajay Singh, Greg Kroah-Hartman, linux-wireless,
devel
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The masking update of pkg_offset is redundant as the updated
value is never read and pkg_offset is re-assigned on the next
iteration of the loop. Clean this up by removing the redundant
assignment.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/staging/wilc1000/wilc_wlan.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
index 95eaf8fdf4f2..dcd728557958 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -709,9 +709,6 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8 *buffer, int size)
break;
if (pkt_offset & IS_MANAGMEMENT) {
- pkt_offset &= ~(IS_MANAGMEMENT |
- IS_MANAGMEMENT_CALLBACK |
- IS_MGMT_STATUS_SUCCES);
buff_ptr += HOST_HDR_OFFSET;
wilc_wfi_mgmt_rx(wilc, buff_ptr, pkt_len);
} else {
--
2.20.1
^ permalink raw reply related
* [PATCH] brcmfmac: use strlcpy() instead of strcpy()
From: neojou @ 2019-05-21 9:12 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, kvalo, davem, rafal, hdegoedg, p.figiel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
netdev, linux-kernel, Neo Jou
From: Neo Jou <neojou@gmail.com>
The function strcpy() is inherently not safe. Though the function
works without problems here, it would be better to use other safer
function, e.g. strlcpy(), to replace strcpy() still.
Signed-off-by: Neo Jou <neojou@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 96b8d5b..9e0bd2b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -269,7 +269,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
- strcpy(buf, "ver");
+ strlcpy(buf, "ver", sizeof(buf));
err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
if (err < 0) {
bphy_err(drvr, "Retrieving version information failed, %d\n",
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier
From: Arend Van Spriel @ 2019-05-21 8:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87mujhoymm.fsf@codeaurora.org>
On 5/20/2019 6:54 PM, Kalle Valo wrote:
> Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
>
>> On 5/16/2019 10:57 PM, Arend Van Spriel wrote:
>>> On 5/16/2019 2:04 PM, Arend van Spriel wrote:
>>>> With ISC license text in place under the LICENSES folder switch
>>>> to using the SPDX license identifier to refer to the ISC license.
>>>
>>> Hi Kalle,
>>>
>>> Given the feedback on checkpatch (or spdxcheck) failures let me
>>> respin this series.
>>
>> Actually let's *NOT* respin and leave this series as is and ignore the
>> warning for the header files as Thomas wrote in his response: " So we
>> can fixup the documentation and allow // style for headers as well.".
>
> What about patch 3, should I drop that patch? Wasn't the conclusion that
> you need separately change led.c?
Okay. Let's do that. Or do you want me to resend the whole series
without patch 3?
Regards,
Arend
^ permalink raw reply
* Inquiry 20/May/2019
From: Daniel Murray @ 2019-05-20 13:32 UTC (permalink / raw)
To: linux-wireless
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd in Russia.
We are glad to know about your company from the web and we are interested in your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Purchasing Manager
^ permalink raw reply
* Re: [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep
From: Brian Norris @ 2019-05-21 0:23 UTC (permalink / raw)
To: Avri Altman
Cc: Douglas Anderson, Ulf Hansson, Kalle Valo, Adrian Hunter,
Arend van Spriel, linux-rockchip@lists.infradead.org, Double Lo,
Madhan Mohan R, mka@chromium.org, Wright Feng, Chi-Hsien Lin,
linux-mmc@vger.kernel.org, Shawn Lin,
brcm80211-dev-list@cypress.com, YueHaibing, Hante Meuleman,
Martin Hicks, Ritesh Harjani, Michael Trimarchi, Wolfram Sang,
Franky Lin, Jiong Wu, brcm80211-dev-list.pdl@broadcom.com,
David S. Miller, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Naveen Gupta
In-Reply-To: <SN6PR04MB49258D4FBE0B4D739E8BAF7EFC040@SN6PR04MB4925.namprd04.prod.outlook.com>
On Sat, May 18, 2019 at 03:09:44PM +0000, Avri Altman wrote:
> >
> > This series attempts to deal better with the expected transmission
> > errors that we get when waking up the SDIO-based WiFi on
> > rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey.
> >
> > Some details about those errors can be found in
> > <https://crbug.com/960222>, but to summarize it here: if we try to
> > send the wakeup command to the WiFi card at the same time it has
> > decided to wake up itself then it will behave badly on the SDIO bus.
> > This can cause timeouts or CRC errors.
> Wake-up itself: as part of a WoWlan, or d0i3?
Neither, IIUC. (It's definitely not WoWLAN, and D0i3 sounds like an
Intel thing.)
I believe it's a Broadcom-specific mode. See also Arend's response to
this thread:
http://lkml.kernel.org/linux-wireless/8c3fa57a-3843-947c-ec6b-a6144ccde1e9@broadcom.com
> Looks like this calls for a wifi driver fix, and not WA in the mmc driver.
Basically asked and answered in patch 2's thread:
https://lkml.kernel.org/lkml/20190520085201.GA1021@kunai/
^ permalink raw reply
* Printing for your logo
From: Heather @ 2019-05-20 12:55 UTC (permalink / raw)
To: linux-wireless
Hi,
I didn’t know if you had received my email from last week?
We manufacture ALL custom LOGO and branded products – over 300,000 to
choose from.
The most asked about product that we make, is the custom printed USB flash
drives!
We can print your logo on them and load your digital images, videos and
files!
Here is what we include:
-Any size memory you need: 64MB up to 128GB
-We will print your logo on both sides, just ask!
-Very Low Order Minimums
-Need them quickly? Not a problem, we offer Rush Service
Email over a copy of your logo and we will create a design mock up for you
at no cost!
Our higher memory sizes are a really good option right now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.
We always offer great rates for schools and nonprofits as well.
Let us know what you would like quoted?
Regards,
Heather Millons
Custom USB Account Manager
^ permalink raw reply
* Re: [PATCH v2] mmc: dw_mmc: Disable SDIO interrupts while suspended to fix suspend/resume
From: Doug Anderson @ 2019-05-20 18:41 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kalle Valo, Heiko Stübner, open list:ARM/Rockchip SoC...,
Guenter Roeck, Brian Norris, linux-wireless, Sonny Rao,
Emil Renner Berthing, Matthias Kaehlcke, Ryan Case, stable,
Linux MMC List, LKML, Jaehoon Chung, Shawn Lin
In-Reply-To: <20190429204040.18725-1-dianders@chromium.org>
Hi,
On Mon, Apr 29, 2019 at 1:41 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> Processing SDIO interrupts while dw_mmc is suspended (or partly
> suspended) seems like a bad idea. We really don't want to be
> processing them until we've gotten ourselves fully powered up.
>
> You might be wondering how it's even possible to become suspended when
> an SDIO interrupt is active. As can be seen in
> dw_mci_enable_sdio_irq(), we explicitly keep dw_mmc out of runtime
> suspend when the SDIO interrupt is enabled. ...but even though we
> stop normal runtime suspend transitions when SDIO interrupts are
> enabled, the dw_mci_runtime_suspend() can still get called for a full
> system suspend.
>
> Let's handle all this by explicitly masking SDIO interrupts in the
> suspend call and unmasking them later in the resume call. To do this
> cleanly I'll keep track of whether the client requested that SDIO
> interrupts be enabled so that we can reliably restore them regardless
> of whether we're masking them for one reason or another.
>
> It should be noted that if dw_mci_enable_sdio_irq() is never called
> (for instance, if we don't have an SDIO card plugged in) that
> "client_sdio_enb" will always be false. In those cases this patch
> adds a tiny bit of overhead to suspend/resume (a spinlock and a
> read/write of INTMASK) but other than that is a no-op. The
> SDMMC_INT_SDIO bit should always be clear and clearing it again won't
> hurt.
>
> Without this fix it can be seen that rk3288-veyron Chromebooks with
> Marvell WiFi would sometimes fail to resume WiFi even after picking my
> recent mwifiex patch [1]. Specifically you'd see messages like this:
> mwifiex_sdio mmc1:0001:1: Firmware wakeup failed
> mwifiex_sdio mmc1:0001:1: PREP_CMD: FW in reset state
>
> ...and tracing through the resume code in the failing cases showed
> that we were processing a SDIO interrupt really early in the resume
> call.
>
> NOTE: downstream in Chrome OS 3.14 and 3.18 kernels (both of which
> support the Marvell SDIO WiFi card) we had a patch ("CHROMIUM: sdio:
> Defer SDIO interrupt handling until after resume") [2]. Presumably
> this is the same problem that was solved by that patch.
>
> [1] https://lkml.kernel.org/r/20190404040106.40519-1-dianders@chromium.org
> [2] https://crrev.com/c/230765
>
> Cc: <stable@vger.kernel.org> # 4.14.x
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> I didn't put any "Fixes" tag here, but presumably this could be
> backported to whichever kernels folks found it useful for. I have at
> least confirmed that kernels v4.14 and v4.19 (as well as v5.1-rc2)
> show the problem. It is very easy to pick this to v4.19 and it
> definitely fixes the problem there.
>
> I haven't spent the time to pick this to 4.14 myself, but presumably
> it wouldn't be too hard to backport this as far as v4.13 since that
> contains commit 32dba73772f8 ("mmc: dw_mmc: Convert to use
> MMC_CAP2_SDIO_IRQ_NOTHREAD for SDIO IRQs"). Prior to that it might
> make sense for anyone experiencing this problem to just pick the old
> CHROMIUM patch to fix them.
>
> Changes in v2:
> - Suggested 4.14+ in the stable tag (Sasha-bot)
> - Extra note that this is a noop on non-SDIO (Shawn / Emil)
> - Make boolean logic cleaner as per https://crrev.com/c/1586207/1
> - Hopefully clear comments as per https://crrev.com/c/1586207/1
>
> drivers/mmc/host/dw_mmc.c | 27 +++++++++++++++++++++++----
> drivers/mmc/host/dw_mmc.h | 3 +++
> 2 files changed, 26 insertions(+), 4 deletions(-)
Ulf: are you the right person to land this? With 5.2-rc1 out it might
be a good time for it? To refresh your memory about this patch:
* Patch v1 was posted back on April 10th [1] so we're at about 1.5
months of time for people to comment about it now. Should be more
than enough.
* Shawn Lin saw it and didn't hate it. He had some confusion about
how it worked and I've hopefully alleviated via extra comments / text.
* Emil Renner Berthing thought it caused a regression for him but then
tested further and was convinced that it didn't. This is extra
confirmation that someone other than me did try the patch and found it
to not break things. ;-)
* It has been reviewed by Guenter Roeck (in v2)
[1] https://lkml.kernel.org/r/20190410221237.160856-1-dianders@chromium.org
-Doug
^ permalink raw reply
* Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354
From: Doug Anderson @ 2019-05-20 18:20 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Ulf Hansson, Kalle Valo, Adrian Hunter,
open list:ARM/Rockchip SoC..., Double Lo, Brian Norris,
Madhan Mohan R, Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin,
brcm80211-dev-list.pdl, Franky Lin, netdev, linux-wireless, LKML,
Hante Meuleman, Naveen Gupta, brcm80211-dev-list, YueHaibing,
David S. Miller
In-Reply-To: <e3f54bcb-8d10-1336-1458-2bd11cfc1010@broadcom.com>
Hi,
On Mon, May 20, 2019 at 1:09 AM Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
>
> On 5/18/2019 12:54 AM, Douglas Anderson wrote:
> > In commit 29f6589140a1 ("brcmfmac: disable command decode in
> > sdio_aos") we disabled something called "command decode in sdio_aos"
> > for a whole bunch of Broadcom SDIO WiFi parts.
> >
> > After that patch landed I find that my kernel log on
> > rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
> > brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
> >
> > This seems to happen every time the Broadcom WiFi transitions out of
> > sleep mode. Reverting the part of the commit that affects the WiFi on
> > my boards fixes the problem for me, so that's what this patch does.
>
> This sounds very similar to the issue we had during integration of wifi
> on rk3288 chromebooks years ago.
I'm working on those same Chromebooks. ;-) I'm working on trying to
make them well on newer kernels.
...but I guess you're saying that the problem faced by the people who
wanted commit 29f6589140a1 ("brcmfmac: disable command decode in
sdio_aos") are similar to the problems we saw in the past on those
Chromebooks. I'd tend to agree. In general it's difficult to get a
SD Host Controller to be fully robust in the fact of any/all errors on
the bus. While dw_mmc is pretty robust these days I'm assuming that
some other host controllers aren't.
> > Note that, in general, the justification in the original commit seemed
> > a little weak. It looked like someone was testing on a SD card
> > controller that would sometimes die if there were CRC errors on the
> > bus. This used to happen back in early days of dw_mmc (the controller
> > on my boards), but we fixed it. Disabling a feature on all boards
> > just because one SD card controller is broken seems bad. ...so
> > instead of just this patch possibly the right thing to do is to fully
> > revert the original commit.
>
> I am leaning towards a full revert, but let's wait for more background info.
I'd be fine with a full revert too. Presumably that will break
someone but maybe they need to come up with a better solution?
-Doug
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: fix typos in code comments
From: Rafał Miłecki @ 2019-05-20 13:31 UTC (permalink / raw)
To: Weitao Hou
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, kvalo, davem, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <20190520122825.981-1-houweitaoo@gmail.com>
On 2019-05-20 14:28, Weitao Hou wrote:
> fix lengh to length
>
> Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
> ---
> - fix prefix
Nice, thanks!
^ 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