* [PATCH] ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
From: Tamizh chelvam @ 2019-03-06 17:36 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Anilkumar Kolli, Tamizh chelvam
From: Anilkumar Kolli <akolli@codeaurora.org>
Increase pulse width range from 1-2usec to 0-4usec.
During data traffic HW occasionally fails detecting radar pulses,
so that SW cannot get enough radar reports to achieve the success rate.
Tested ath10k hw and fw:
* QCA9888(10.4-3.5.1-00052)
* QCA4019(10.4-3.2.1.1-00017)
* QCA9984(10.4-3.6-00104)
* QCA988X(10.2.4-1.0-00041)
Tested ath9k hw: AR9300
Tested-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index d52b31b..a274eb0 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -111,7 +111,7 @@ struct radar_types {
JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 29, false),
JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 29, false),
JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
- JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
+ JP_PATTERN(3, 0, 4, 4000, 4000, 1, 18, 50, false),
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
--
1.9.1
^ permalink raw reply related
* [PATCH] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Yue Haibing @ 2019-03-06 11:56 UTC (permalink / raw)
To: ast, daniel, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
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>
---
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 f51f150..ffa379e 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.7.0
^ permalink raw reply related
* [PATCH] ray_cs: use remove_proc_subtree to simplify procfs code
From: Yue Haibing @ 2019-03-06 11:48 UTC (permalink / raw)
To: davem, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Use remove_proc_subtree to remove the whole subtree
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ray_cs.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index d561659..ee4d810 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -2820,11 +2820,7 @@ static void __exit exit_ray_cs(void)
pr_debug("ray_cs: cleanup_module\n");
#ifdef CONFIG_PROC_FS
- remove_proc_entry("driver/ray_cs/ray_cs", NULL);
- remove_proc_entry("driver/ray_cs/essid", NULL);
- remove_proc_entry("driver/ray_cs/net_type", NULL);
- remove_proc_entry("driver/ray_cs/translate", NULL);
- remove_proc_entry("driver/ray_cs", NULL);
+ remove_proc_subtree("driver/ray_cs", NULL);
#endif
pcmcia_unregister_driver(&ray_driver);
--
2.7.0
^ permalink raw reply related
* [PATCH] ray_cs: Check return value of pcmcia_register_driver
From: Yue Haibing @ 2019-03-06 11:46 UTC (permalink / raw)
To: davem, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
init_ray_cs does not check value of pcmcia_register_driver,
if it fails, there maybe cause a NULL pointer dereference in
exit_ray_cs.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ray_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index 44a943d..d561659 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -2795,6 +2795,8 @@ static int __init init_ray_cs(void)
rc = pcmcia_register_driver(&ray_driver);
pr_debug("raylink init_module register_pcmcia_driver returns 0x%x\n",
rc);
+ if (rc)
+ return rc;
#ifdef CONFIG_PROC_FS
proc_mkdir("driver/ray_cs", NULL);
--
2.7.0
^ permalink raw reply related
* Re: mediatek: duplicate usb devices
From: Stanislaw Gruszka @ 2019-03-06 11:03 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Xose Vazquez Perez, Felix Fietkau, Lorenzo Bianconi,
linux-wireless, Jakub Kicinski, Hans Ulli Kroll
In-Reply-To: <CAA2SeN+V_ug2JPNQ++ZTj4hYh-YDOkNhiyP_dsaYnpddXDb6PA@mail.gmail.com>
On Wed, Mar 06, 2019 at 11:09:12AM +0100, Lorenzo Bianconi wrote:
> >
> > On Tue, Mar 05, 2019 at 07:33:51PM +0100, Xose Vazquez Perez wrote:
> > > There a three duplicate devices at:
> > >
> > > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
> > > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
> > One duplicated entry should be removed.
> >
> > > mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
> > > mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
>
> IIUC this is not in the mt7601u driver available on mtk website.
The same apply to mt7610u. Vendor driver have only IDs for some
reference devices. Both mt7601u and mt7610u drivers do not include
0x7610.
For mt76x0u ids were provided by Hans
https://lore.kernel.org/linux-wireless/alpine.LNX.2.00.1804092042320.8369@T420s/
I'm not sure where they came from.
Stanislaw
^ permalink raw reply
* Re: mediatek: duplicate usb devices
From: Lorenzo Bianconi @ 2019-03-06 10:09 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Xose Vazquez Perez, Felix Fietkau, Lorenzo Bianconi,
linux-wireless, Jakub Kicinski
In-Reply-To: <20190306075053.GA12946@redhat.com>
>
> On Tue, Mar 05, 2019 at 07:33:51PM +0100, Xose Vazquez Perez wrote:
> > There a three duplicate devices at:
> >
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
> One duplicated entry should be removed.
>
> > mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
> > mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
IIUC this is not in the mt7601u driver available on mtk website.
@Jakub: should we remove it from mt7601u driver?
> Not sure about this.
>
> > mt76/mt76x0/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax / Elecom */
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
> According to wikidevi we really have duplicated IDs:
>
> https://wikidevi.com/wiki/Edimax_EW-7722UAC
> https://wikidevi.com/wiki/Elecom_WDC-433SU2M
>
> I think we can handle this by checking ASIC version from the EEPROM
> or registers at the beginning of probe and exit if it does not mach.
> This should assure we will load proper driver.
>
> Stanislaw
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* [PATCH] mt76x2u: remove duplicated entry in mt76x2u_device_table
From: Lorenzo Bianconi @ 2019-03-06 9:51 UTC (permalink / raw)
To: nbd; +Cc: rosenp, linux-wireless, xose.vazquez, sgruszka, lorenzo.bianconi
In-Reply-To: <cover.1551865527.git.lorenzo@kernel.org>
Remove duplicated entry in mt76x2u_device_table since Alfa AWUS036ACM
and Aukey USB-AC1200 have the same ids
Fixes: 62a25dc56990a ("mt76x2u: Add support for Alfa AWUS036ACM")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
index ddb6b2c48e01..7a5d539873ca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c
@@ -21,11 +21,10 @@
#include "mt76x2u.h"
static const struct usb_device_id mt76x2u_device_table[] = {
- { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
{ USB_DEVICE(0x0b05, 0x1833) }, /* Asus USB-AC54 */
{ USB_DEVICE(0x0b05, 0x17eb) }, /* Asus USB-AC55 */
{ USB_DEVICE(0x0b05, 0x180b) }, /* Asus USB-N53 B1 */
- { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
+ { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USBAC1200 - Alfa AWUS036ACM */
{ USB_DEVICE(0x057c, 0x8503) }, /* Avm FRITZ!WLAN AC860 */
{ USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
{ USB_DEVICE(0x0846, 0x9053) }, /* Netgear A6210 */
--
2.20.1
^ permalink raw reply related
* Re: mediatek: duplicate usb devices
From: Lorenzo Bianconi @ 2019-03-06 9:16 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Xose Vazquez Perez, Felix Fietkau, Lorenzo Bianconi,
linux-wireless, Jakub Kicinski
In-Reply-To: <20190306075053.GA12946@redhat.com>
>
> On Tue, Mar 05, 2019 at 07:33:51PM +0100, Xose Vazquez Perez wrote:
> > There a three duplicate devices at:
> >
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
This has been introduced in commit 62a25dc56990a, I will post a fix
Regards,
Lorenzo
> One duplicated entry should be removed.
>
> > mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
> > mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
> Not sure about this.
>
> > mt76/mt76x0/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax / Elecom */
> > mt76/mt76x2/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
> According to wikidevi we really have duplicated IDs:
>
> https://wikidevi.com/wiki/Edimax_EW-7722UAC
> https://wikidevi.com/wiki/Elecom_WDC-433SU2M
>
> I think we can handle this by checking ASIC version from the EEPROM
> or registers at the beginning of probe and exit if it does not mach.
> This should assure we will load proper driver.
>
> Stanislaw
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH 4/4] brcmfmac: reset PCIe bus on a firmware crash
From: Arend Van Spriel @ 2019-03-06 9:08 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190226131119.7907-5-zajec5@gmail.com>
On 2/26/2019 2:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This includes bus reset & reloading a firmware. It should be sufficient
> for a user space to (setup and) use a wireless device again.
>
> Support for reset on USB & SDIO can be added later.
It should be noted that you end up with a new wiphy instance though. We
could try to avoid that in subsequent change.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../broadcom/brcm80211/brcmfmac/bus.h | 10 ++++++
> .../broadcom/brcm80211/brcmfmac/core.c | 12 +++++++
> .../broadcom/brcm80211/brcmfmac/core.h | 2 ++
> .../broadcom/brcm80211/brcmfmac/pcie.c | 35 +++++++++++++++++++
> 4 files changed, 59 insertions(+)
^ permalink raw reply
* Re: [PATCH 3/4] brcmfmac: add a function designated for handling firmware fails
From: Arend Van Spriel @ 2019-03-06 9:02 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190226131119.7907-4-zajec5@gmail.com>
On 2/26/2019 2:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This improves handling PCIe firmware halts by printing a clear error
> message and replaces a similar code in the SDIO bus support.
>
> It will also allow further improvements like trying to recover from a
> firmware crash.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 2 ++
> .../net/wireless/broadcom/brcm80211/brcmfmac/core.c | 10 ++++++++++
> .../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
> .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 ++--
> 4 files changed, 15 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/4] brcmfmac: get RAM info right before downloading PCIe firmware
From: Arend Van Spriel @ 2019-03-06 8:59 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190226131119.7907-3-zajec5@gmail.com>
On 2/26/2019 2:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It's important as brcmf_chip_get_raminfo() also makes sure that memory
> is properly setup. Without it the firmware could report invalid RAM
> address like 0x04000001.
>
> During a normal brcmfmac lifetime brcmf_chip_get_raminfo() is called on
> probe by the brcmf_chip_recognition(). This change allows implementing
> further improvements like handling errors by resetting a device with
> the brcmf_pcie_reset_device() and redownloading a firmware afterwards.
Thanks, Rafał
How about avoiding the ramsize adjustment in redownloading scenario. We
could add a reinit field in devinfo and check that.
/* Some of the firmwares have the size of the memory of the device
* defined inside the firmware. This is because part of the memory in
* the device is shared and the devision is determined by FW. Parse
* the firmware and adjust the chip memory size now.
*/
if (!devinfo->reinit)
brcmf_pcie_adjust_ramsize(devinfo, (u8 *)fw->data, fw->size);
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 6 ++++--
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h | 1 +
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 6 ++++++
> 3 files changed, 11 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] mt76: Fix an IS_ERR() vs NULL check in mt76_wmac_probe()
From: Kalle Valo @ 2019-03-06 8:50 UTC (permalink / raw)
To: Dan Carpenter
Cc: Felix Fietkau, Lorenzo Bianconi, Matthias Brugger, linux-wireless,
linux-mediatek, kernel-janitors
In-Reply-To: <20190306072633.GA2625@kadam>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> The devm_ioremap_resource() function never returns NULL, it returns
> error pointers.
>
> Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt7603/soc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
> index e13fea80d970..b920be1f5718 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
> @@ -23,9 +23,9 @@ mt76_wmac_probe(struct platform_device *pdev)
> }
>
> mem_base = devm_ioremap_resource(&pdev->dev, res);
> - if (!mem_base) {
> + if (IS_ERR(mem_base)) {
> dev_err(&pdev->dev, "Failed to get memory resource\n");
> - return -EINVAL;
> + return PTR_ERR(mem_base);
> }
Wei already posted an identical patch:
https://patchwork.kernel.org/patch/10837285/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/4] brcmfmac: support repeated brcmf_fw_alloc_request() calls
From: Arend Van Spriel @ 2019-03-06 8:49 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Rafał Miłecki
In-Reply-To: <20190226131119.7907-2-zajec5@gmail.com>
On 2/26/2019 2:11 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> During a normal brcmfmac lifetime brcmf_fw_alloc_request() is called
> once only during the probe. It's safe to assume provided array is clear.
>
> Further brcmfmac improvements may require calling it multiple times
> though. This patch allows it by fixing invalid firmware paths like:
> brcm/brcmfmac4366c-pcie.binbrcm/brcmfmac4366c-pcie.bin
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 1 +
> 1 file changed, 1 insertion(+)
^ permalink raw reply
* Re: mediatek: duplicate usb devices
From: Stanislaw Gruszka @ 2019-03-06 7:50 UTC (permalink / raw)
To: Xose Vazquez Perez
Cc: Felix Fietkau, Lorenzo Bianconi, linux-wireless, Jakub Kicinski
In-Reply-To: <11161578-bb42-168b-1459-f22a98f5c6bb@gmail.com>
On Tue, Mar 05, 2019 at 07:33:51PM +0100, Xose Vazquez Perez wrote:
> There a three duplicate devices at:
>
> mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
> mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
One duplicated entry should be removed.
> mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
> mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
Not sure about this.
> mt76/mt76x0/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax / Elecom */
> mt76/mt76x2/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
According to wikidevi we really have duplicated IDs:
https://wikidevi.com/wiki/Edimax_EW-7722UAC
https://wikidevi.com/wiki/Elecom_WDC-433SU2M
I think we can handle this by checking ASIC version from the EEPROM
or registers at the beginning of probe and exit if it does not mach.
This should assure we will load proper driver.
Stanislaw
^ permalink raw reply
* [PATCH] mt76: Fix an IS_ERR() vs NULL check in mt76_wmac_probe()
From: Dan Carpenter @ 2019-03-06 7:26 UTC (permalink / raw)
To: Felix Fietkau
Cc: Lorenzo Bianconi, Kalle Valo, Matthias Brugger, linux-wireless,
linux-mediatek, kernel-janitors
The devm_ioremap_resource() function never returns NULL, it returns
error pointers.
Fixes: c8846e101502 ("mt76: add driver for MT7603E and MT7628/7688")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/wireless/mediatek/mt76/mt7603/soc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
index e13fea80d970..b920be1f5718 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
@@ -23,9 +23,9 @@ mt76_wmac_probe(struct platform_device *pdev)
}
mem_base = devm_ioremap_resource(&pdev->dev, res);
- if (!mem_base) {
+ if (IS_ERR(mem_base)) {
dev_err(&pdev->dev, "Failed to get memory resource\n");
- return -EINVAL;
+ return PTR_ERR(mem_base);
}
mdev = mt76_alloc_device(&pdev->dev, sizeof(*dev), &mt7603_ops,
--
2.17.1
^ permalink raw reply related
* Re: mediatek: duplicate usb devices
From: Kalle Valo @ 2019-03-06 5:14 UTC (permalink / raw)
To: Xose Vazquez Perez
Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka,
linux-wireless, Jakub Kicinski
In-Reply-To: <11161578-bb42-168b-1459-f22a98f5c6bb@gmail.com>
+ jakub
Xose Vazquez Perez <xose.vazquez@gmail.com> writes:
> There a three duplicate devices at:
[...]
> mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
> mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
This is not good, two drivers should not be competing about the same
device. So which driver should support this device?
--
Kalle Valo
^ permalink raw reply
* mediatek: duplicate usb devices
From: Xose Vazquez Perez @ 2019-03-05 18:33 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka,
linux-wireless
Hi,
There a three duplicate devices at:
mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Alfa AWUS036ACM */
mt76/mt76x2/usb.c: { USB_DEVICE(0x0e8d, 0x7612) }, /* Aukey USB-AC1200 */
mt76/mt76x0/usb.c: { USB_DEVICE(0x148f, 0x760a) }, /* TP-Link unknown */
mt7601u/usb.c: { USB_DEVICE(0x148f, 0x760a) },
mt76/mt76x0/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax / Elecom */
mt76/mt76x2/usb.c: { USB_DEVICE(0x7392, 0xb711) }, /* Edimax EW 7722 UAC */
Thanks.
^ permalink raw reply
* Re: [RFC/RFT] mac80211: Switch to a virtual time-based airtime scheduler
From: Toke Høiland-Jørgensen @ 2019-03-05 15:45 UTC (permalink / raw)
To: make-wifi-fast, linux-wireless; +Cc: Felix Fietkau, Rajkumar Manoharan, Kan Yan
In-Reply-To: <20190215170512.31512-1-toke@redhat.com>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> This switches the airtime scheduler in mac80211 to use a virtual time-based
> scheduler instead of the round-robin scheduler used before. This has a
> couple of advantages:
>
> - No need to sync up the round-robin scheduler in firmware/hardware with
> the round-robin airtime scheduler.
>
> - If several stations are eligible for transmission we can schedule both of
> them; no need to hard-block the scheduling rotation until the head of the
> queue has used up its quantum.
>
> - The check of whether a station is eligible for transmission becomes
> simpler (in ieee80211_txq_may_transmit()).
>
> The drawback is that scheduling becomes slightly more expensive, as we need
> to maintain an rbtree of TXQs sorted by virtual time. This means that
> ieee80211_register_airtime() becomes O(logN) in the number of currently
> scheduled TXQs. However, hopefully this number rarely grows too big (it's
> only TXQs currently backlogged, not all associated stations), so it
> shouldn't be too big of an issue.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
> This is basically the idea I mentioned earlier for a different way to
> handle the airtime scheduling.
>
> I've tested it on ath9k, where it achieves the same fairness and
> weighing properties as the old scheduler. It would be good if you could
> test it on your ath10k setup, Rajkumar; and all of you please comment on
> whether you agree that this is better from an API point of view.
So no one has any comments on this? :)
-Toke
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix 64-bit division
From: Luca Coelho @ 2019-03-05 11:46 UTC (permalink / raw)
To: Kalle Valo, Arnd Bergmann
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
David S. Miller, Avraham Stern, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87a7i9fuef.fsf@kamboji.qca.qualcomm.com>
On Tue, 2019-03-05 at 13:11 +0200, Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > do_div() expects unsigned operands and otherwise triggers a warning
> > like:
> >
> > drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2:
> > error: comparison of distinct pointer types ('typeof ((rtt_avg)) *'
> > (aka 'long long *') and 'uint64_t *' (aka 'unsigned long long *'))
> > [-Werror,-Wcompare-distinct-pointer-types]
> > do_div(rtt_avg, 6666);
> > ^~~~~~~~~~~~~~~~~~~~~
> > include/asm-generic/div64.h:222:28: note: expanded from macro
> > 'do_div'
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> > ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> > 1 error generated.
> >
> > Change the do_div() to the simpler div_s64() that can handle
> > negative inputs correctly.
> >
> > Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Luca, can I take this directly?
Yeah, I guess to make things simpler, and since you're planning to send
fixes to 5.1 already anyway, you can just take this one. I'll assign
it to you in patchwork.
Arnd, this way you'll get it earlier. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix 64-bit division
From: Kalle Valo @ 2019-03-05 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, David S. Miller, Avraham Stern,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20190304203924.2111146-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> do_div() expects unsigned operands and otherwise triggers a warning like:
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: error: comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long long *') and 'uint64_t *' (aka 'unsigned long long *')) [-Werror,-Wcompare-distinct-pointer-types]
> do_div(rtt_avg, 6666);
> ^~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> 1 error generated.
>
> Change the do_div() to the simpler div_s64() that can handle
> negative inputs correctly.
>
> Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Luca, can I take this directly?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix 64-bit division
From: Luciano Coelho @ 2019-03-05 8:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, David S. Miller, Avraham Stern, linux-wireless,
Networking, Linux Kernel Mailing List
In-Reply-To: <CAK8P3a3ziTxhEW5ea828jNjktR9qH-T2OknON5RVBrbiXT4kBw@mail.gmail.com>
On Tue, 2019-03-05 at 09:37 +0100, Arnd Bergmann wrote:
> On Tue, Mar 5, 2019 at 7:44 AM Luciano Coelho <
> luciano.coelho@intel.com> wrote:
> > On Mon, 2019-03-04 at 21:38 +0100, Arnd Bergmann wrote:
> > This was already fixed with this patch:
> >
> > https://patchwork.kernel.org/patch/10823267/
> >
> > ...but it hasn't reached the mainline yet.
> >
> > I'm planning to send it to the v5.1-rc series as soon as the merge
> > window closes. Is that quick enough for you?
>
> That's fine, I just want it to reach 5.1 so it does not regress
> against 5.0.
Okay, I'll push it to 5.1-rc series for sure.
> Sorry for the slightly bad timing of my submission. I had just
> restarted
> my randconfig tests the other day and wanted to get my 60 new patches
> out as quickly as possible.
No problem! I really appreciate your sending patches and reviews.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix 64-bit division
From: Arnd Bergmann @ 2019-03-05 8:37 UTC (permalink / raw)
To: Luciano Coelho
Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, David S. Miller, Avraham Stern, linux-wireless,
Networking, Linux Kernel Mailing List
In-Reply-To: <ec4e92fa787a7db1caf39920a62c3721849baee9.camel@intel.com>
On Tue, Mar 5, 2019 at 7:44 AM Luciano Coelho <luciano.coelho@intel.com> wrote:
> On Mon, 2019-03-04 at 21:38 +0100, Arnd Bergmann wrote:
> This was already fixed with this patch:
>
> https://patchwork.kernel.org/patch/10823267/
>
> ...but it hasn't reached the mainline yet.
>
> I'm planning to send it to the v5.1-rc series as soon as the merge
> window closes. Is that quick enough for you?
That's fine, I just want it to reach 5.1 so it does not regress against 5.0.
Sorry for the slightly bad timing of my submission. I had just restarted
my randconfig tests the other day and wanted to get my 60 new patches
out as quickly as possible.
Arnd
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix 64-bit division
From: Luciano Coelho @ 2019-03-05 6:43 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller
Cc: Avraham Stern, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190304203924.2111146-1-arnd@arndb.de>
Hi Arnd,
On Mon, 2019-03-04 at 21:38 +0100, Arnd Bergmann wrote:
> do_div() expects unsigned operands and otherwise triggers a warning
> like:
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: error:
> comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka
> 'long long *') and 'uint64_t *' (aka 'unsigned long long *')) [-
> Werror,-Wcompare-distinct-pointer-types]
> do_div(rtt_avg, 6666);
> ^~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/div64.h:222:28: note: expanded from macro
> 'do_div'
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> 1 error generated.
>
> Change the do_div() to the simpler div_s64() that can handle
> negative inputs correctly.
>
> Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
This was already fixed with this patch:
https://patchwork.kernel.org/patch/10823267/
...but it hasn't reached the mainline yet.
I'm planning to send it to the v5.1-rc series as soon as the merge
window closes. Is that quick enough for you?
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 2/2] rtlwifi: Convert the wake_match variable to local
From: Larry Finger @ 2019-03-04 21:59 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190304215940.2608-1-Larry.Finger@lwfinger.net>
In five of the drivers, the contents of bits 29-31 of one of the RX
descriptors is used to set bits in a variable that is used to save the
wakeup condition for output in a debugging statement. The resulting
variable is not used anywhere else even though it is stored in a struct
and could be available in other routines. This variable is changed to be
local.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 13 +++++++------
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 13 +++++++------
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 14 +++++++-------
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 14 +++++++-------
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 -
5 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index 3a70be92a77c..e5729dc5c832 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -373,6 +373,7 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
struct rx_fwinfo_88e *p_drvinfo;
struct ieee80211_hdr *hdr;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
+ u8 wake_match;
status->packet_report_type = (u8)GET_RX_STATUS_DESC_RPT_SEL(pdesc);
if (status->packet_report_type == TX_REPORT2)
@@ -400,17 +401,17 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
status->macid = GET_RX_DESC_MACID(pdesc);
if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
- status->wake_match = BIT(2);
+ wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
- status->wake_match = BIT(1);
+ wake_match = BIT(1);
else if (GET_RX_STATUS_DESC_UNICAST_MATCH(pdesc))
- status->wake_match = BIT(0);
+ wake_match = BIT(0);
else
- status->wake_match = 0;
- if (status->wake_match)
+ wake_match = 0;
+ if (wake_match)
RT_TRACE(rtlpriv, COMP_RXDESC, DBG_LOUD,
"GGGGGGGGGGGGGet Wakeup Packet!! WakeMatch=%d\n",
- status->wake_match);
+ wake_match);
rx_status->freq = hw->conf.chandef.chan->center_freq;
rx_status->band = hw->conf.chandef.chan->band;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index 49a4c84d193a..d297cfc0fd2b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -331,6 +331,7 @@ bool rtl92ee_rx_query_desc(struct ieee80211_hw *hw,
struct rx_fwinfo *p_drvinfo;
struct ieee80211_hdr *hdr;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
+ u8 wake_match;
if (GET_RX_STATUS_DESC_RPT_SEL(pdesc) == 0)
status->packet_report_type = NORMAL_RX;
@@ -351,17 +352,17 @@ bool rtl92ee_rx_query_desc(struct ieee80211_hw *hw,
status->macid = GET_RX_DESC_MACID(pdesc);
if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
- status->wake_match = BIT(2);
+ wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
- status->wake_match = BIT(1);
+ wake_match = BIT(1);
else if (GET_RX_STATUS_DESC_UNICAST_MATCH(pdesc))
- status->wake_match = BIT(0);
+ wake_match = BIT(0);
else
- status->wake_match = 0;
- if (status->wake_match)
+ wake_match = 0;
+ if (wake_match)
RT_TRACE(rtlpriv, COMP_RXDESC, DBG_LOUD,
"GGGGGGGGGGGGGet Wakeup Packet!! WakeMatch=%d\n",
- status->wake_match);
+ wake_match);
rx_status->freq = hw->conf.chandef.chan->center_freq;
rx_status->band = hw->conf.chandef.chan->band;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
index a382cdc668ed..d87ba03fe78f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
@@ -300,7 +300,7 @@ bool rtl8723be_rx_query_desc(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rx_fwinfo_8723be *p_drvinfo;
struct ieee80211_hdr *hdr;
-
+ u8 wake_match;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
status->length = (u16)GET_RX_DESC_PKT_LEN(pdesc);
@@ -330,17 +330,17 @@ bool rtl8723be_rx_query_desc(struct ieee80211_hw *hw,
if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
- status->wake_match = BIT(2);
+ wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
- status->wake_match = BIT(1);
+ wake_match = BIT(1);
else if (GET_RX_STATUS_DESC_UNICAST_MATCH(pdesc))
- status->wake_match = BIT(0);
+ wake_match = BIT(0);
else
- status->wake_match = 0;
- if (status->wake_match)
+ wake_match = 0;
+ if (wake_match)
RT_TRACE(rtlpriv, COMP_RXDESC, DBG_LOUD,
"GGGGGGGGGGGGGet Wakeup Packet!! WakeMatch=%d\n",
- status->wake_match);
+ wake_match);
rx_status->freq = hw->conf.chandef.chan->center_freq;
rx_status->band = hw->conf.chandef.chan->band;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c
index db5e628b17ed..7b6faf38e09c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c
@@ -436,7 +436,7 @@ bool rtl8821ae_rx_query_desc(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rx_fwinfo_8821ae *p_drvinfo;
struct ieee80211_hdr *hdr;
-
+ u8 wake_match;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
status->length = (u16)GET_RX_DESC_PKT_LEN(pdesc);
@@ -473,18 +473,18 @@ bool rtl8821ae_rx_query_desc(struct ieee80211_hw *hw,
status->packet_report_type = NORMAL_RX;
if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
- status->wake_match = BIT(2);
+ wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
- status->wake_match = BIT(1);
+ wake_match = BIT(1);
else if (GET_RX_STATUS_DESC_UNICAST_MATCH(pdesc))
- status->wake_match = BIT(0);
+ wake_match = BIT(0);
else
- status->wake_match = 0;
+ wake_match = 0;
- if (status->wake_match)
+ if (wake_match)
RT_TRACE(rtlpriv, COMP_RXDESC, DBG_LOUD,
"GGGGGGGGGGGGGet Wakeup Packet!! WakeMatch=%d\n",
- status->wake_match);
+ wake_match);
rx_status->freq = hw->conf.chandef.chan->center_freq;
rx_status->band = hw->conf.chandef.chan->band;
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index e32e9ffa3192..518aaa875361 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2138,7 +2138,6 @@ struct rtl_stats {
u8 packet_report_type;
u32 macid;
- u8 wake_match;
u32 bt_rx_rssi_percentage;
u32 macid_valid_entry[2];
};
--
2.21.0
^ permalink raw reply related
* [PATCH 1/2] rtlwifi: Fix duplicate tests of one of the RX descriptors
From: Larry Finger @ 2019-03-04 21:59 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190304215940.2608-1-Larry.Finger@lwfinger.net>
In drivers rtl8188ee, rtl8821ae, rtl8723be, and rtl8192ee, the reason
for a wake-up is returned in the fourth RX descriptor in bits 29-31. Due
to typographical errors, all but rtl8821ae test bit 31 twice and fail to
test bit 29.
This error causes no problems as the tests are only used to set bits in
a quantity output in an optional debugging statement.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index ae1ac8be3c5b..3a70be92a77c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -399,7 +399,7 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
status->is_cck = RTL8188_RX_HAL_IS_CCK_RATE(status->rate);
status->macid = GET_RX_DESC_MACID(pdesc);
- if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
+ if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
status->wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
status->wake_match = BIT(1);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index 09cf8180e4ff..49a4c84d193a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -350,7 +350,7 @@ bool rtl92ee_rx_query_desc(struct ieee80211_hw *hw,
status->is_cck = RTL92EE_RX_HAL_IS_CCK_RATE(status->rate);
status->macid = GET_RX_DESC_MACID(pdesc);
- if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
+ if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
status->wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
status->wake_match = BIT(1);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
index 9ada9a06c6ea..a382cdc668ed 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c
@@ -329,7 +329,7 @@ bool rtl8723be_rx_query_desc(struct ieee80211_hw *hw,
status->packet_report_type = NORMAL_RX;
- if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
+ if (GET_RX_STATUS_DESC_PATTERN_MATCH(pdesc))
status->wake_match = BIT(2);
else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc))
status->wake_match = BIT(1);
--
2.21.0
^ permalink raw reply related
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