* Re: [PATCH] ray_cs: use remove_proc_subtree to simplify procfs code
From: Kalle Valo @ 2019-04-25 16:39 UTC (permalink / raw)
To: Yue Haibing; +Cc: davem, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190306114812.30480-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> Use remove_proc_subtree to remove the whole subtree
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
3b6edcb3fffe ray_cs: use remove_proc_subtree to simplify procfs code
--
https://patchwork.kernel.org/patch/10840991/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
From: Kalle Valo @ 2019-04-25 16:40 UTC (permalink / raw)
To: Yue Haibing; +Cc: ast, daniel, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190306115658.25076-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> 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>
Patch applied to wireless-drivers-next.git, thanks.
b2c01aab9646 ssb: Fix possible NULL pointer dereference in ssb_host_pcmcia_exit
--
https://patchwork.kernel.org/patch/10841029/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: cw1200: fix a NULL pointer dereference
From: Kalle Valo @ 2019-04-25 16:40 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, Solomon Peachy, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20190312080502.2953-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> In case create_singlethread_workqueue fails, the fix free the
> hardware and returns NULL to avoid NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Patch applied to wireless-drivers-next.git, thanks.
0ed2a0053474 net: cw1200: fix a NULL pointer dereference
--
https://patchwork.kernel.org/patch/10848701/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 2/4] rt2x00: use ratelimited variants dev_warn/dev_err
From: Kalle Valo @ 2019-04-25 16:41 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <1552384303-29529-3-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> As reported by Randy we can overwhelm logs on some USB error conditions.
> To avoid that use dev_warn_ratelimited() and dev_err_ratelimitd().
>
> Reported-and-tested-by: Randy Oostdyk <linux-kernel@oostdyk.com>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
3 patches applied to wireless-drivers-next.git, thanks.
bb3b18c92533 rt2x00: use ratelimited variants dev_warn/dev_err
e383c70474db rt2x00: check number of EPROTO errors
61a4e5ff0d72 rt2x00: do not print error when queue is full
--
https://patchwork.kernel.org/patch/10848959/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rt2x00: code-style fix in rt2800usb.c
From: Kalle Valo @ 2019-04-25 16:41 UTC (permalink / raw)
To: Tomislav Požega; +Cc: linux-wireless
In-Reply-To: <1552573160-3268-1-git-send-email-pozega.tomislav@gmail.com>
Tomislav Požega wrote:
> Remove space leftovers.
>
> Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
9490c5602445 rt2x00: code-style fix in rt2800usb.c
--
https://patchwork.kernel.org/patch/10852955/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Al Viro @ 2019-04-25 16:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mauro Carvalho Chehab, Linux FS-devel Mailing List,
y2038 Mailman List, Linux Kernel Mailing List, Jason Gunthorpe,
Daniel Vetter, Greg Kroah-Hartman, David Sterba, Darren Hart,
Jonathan Cameron, Bjorn Andersson, driverdevel, qat-linux,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
Linux Media Mailing List, dri-devel, linaro-mm-sig, amd-gfx,
open list:HID CORE LAYER, linux-iio, linux-rdma, linux-nvdimm,
linux-nvme, linux-pci, Platform Driver, linux-remoteproc,
sparclinux, linux-scsi, USB list, linux-btrfs, ceph-devel,
linux-wireless, Networking, Sean Young
In-Reply-To: <CAK8P3a2HmiYQJ2FV2FgLiFsD8M9UKteC9Jetx7ja06PQVZWYfA@mail.gmail.com>
On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> >
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument. IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
>
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this, but not
> copy_to_user(), which overwrites 4 bytes after the end of
> the 20-byte user structure.
D'oh! FWIW, it might be worth putting into Documentation/ somewhere;
basically, what is and what isn't biarch-neutral.
Or arch-neutral, for that matter - it's very close. The only real
exception, IIRC, is an extra twist on m68k, where int behaves
like x86 long long - its alignment is only half its size, so
sizeof(struct {char c; int x;}) is 6, not 8 as everywhere
else. Irrelevant for biarch, thankfully (until somebody gets insane
enough to implement 64bit coldfire, kernel port for it *and* biarch
support for m68k binaries on that thing, that is)...
^ permalink raw reply
* Re: [PATCH v2] rsi: Fix NULL pointer dereference in kmalloc
From: Kalle Valo @ 2019-04-25 16:42 UTC (permalink / raw)
To: Aditya Pakki
Cc: pakki001, kjlu, Amitkumar Karwar, Siva Rebbagondla,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190323204916.8368-1-pakki001@umn.edu>
Aditya Pakki <pakki001@umn.edu> wrote:
> kmalloc can fail in rsi_register_rates_channels but memcpy still attempts
> to write to channels. The patch replaces these calls with kmemdup and
> passes the error upstream.
>
> Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Patch applied to wireless-drivers-next.git, thanks.
d5414c2355b2 rsi: Fix NULL pointer dereference in kmalloc
--
https://patchwork.kernel.org/patch/10866983/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/8] rt2800: partially restore old mmio txstatus behaviour
From: Kalle Valo @ 2019-04-25 16:44 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin
In-Reply-To: <1553680711-15730-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Do not disable txstatus interrupt and add quota of processed tx statuses in
> one tasklet. Quota is needed to allow to fed device with new frames during
> processing of tx statuses.
>
> Patch fixes about 15% performance degradation on some scenarios caused by
> 0b0d556e0ebb ("rt2800mmio: use txdone/txstatus routines from lib").
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
8 patches applied to wireless-drivers-next.git, thanks.
889bb866baaf rt2800: partially restore old mmio txstatus behaviour
f61131505e85 rt2800: new flush implementation for SoC devices
6efa79876486 rt2800: move txstatus pending routine
2c7ba758cc4b rt2800mmio: fetch tx status changes
e5ceab9df437 rt2800mmio: use timer and work for handling tx statuses timeouts
eb662b1dc62e rt2x00: remove last_nostatus_check
d954f9e3fb42 rt2x00: remove not used entry field
9ea3812f015b rt2x00mmio: remove legacy comment
--
https://patchwork.kernel.org/patch/10873121/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/8] rsi: add new device model for 9116
From: Kalle Valo @ 2019-04-25 16:45 UTC (permalink / raw)
To: Siva Rebbagondla
Cc: linux-wireless, amitkarwar, krishna.pedda, Ganapathiraju Kondraju,
Siva Rebbagondla
In-Reply-To: <20190403041309.12829-2-siva8118@gmail.com>
Siva Rebbagondla <siva8118@gmail.com> wrote:
> 9116 device id entry is added in both SDIO and USB interfaces.
> New enumberation value taken for the device model. Based on the
> device model detected run time, few device specific operations
> needs to be performed.
>
> adding rsi_dev_model to get device type in run time, as we can use
> same driver for 9113 and 9116 except few firmware load changes.
>
> Signed-off-by: Siva Rebbagondla <siva8118@gmail.com>
8 patches applied to wireless-drivers-next.git, thanks.
54fdb318c111 rsi: add new device model for 9116
3ac61578fbd4 rsi: move common part of firmware load to separate function
e5a1ecc97e5f rsi: add firmware loading for 9116 device
9ba4562ac195 rsi: change in device init frame sequence for 9116
f911c86166d5 rsi: new bootup parameters for 9116
1533f976c668 rsi: send new tx command frame wlan9116 features
17ff2c794f39 rsi: reset device changes for 9116
0a60014b76f5 rsi: miscallaneous changes for 9116 and common
--
https://patchwork.kernel.org/patch/10882717/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] mwifiex: use struct_size() in kzalloc()
From: Kalle Valo @ 2019-04-25 16:45 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S. Miller, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20190403164052.GA26381@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable regd_size is not necessary,
> hence it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
ae187ba91541 mwifiex: use struct_size() in kzalloc()
--
https://patchwork.kernel.org/patch/10884249/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] zd1211rw: use struct_size() helper
From: Kalle Valo @ 2019-04-25 16:50 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Daniel Drake, Ulrich Kunitz, David S. Miller, linux-wireless,
netdev, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20190403185905.GA8650@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace code of the following form:
>
> sizeof(struct usb_req_write_regs) + count * sizeof(struct reg_data)
>
> with:
>
> struct_size(req, reg_writes, count)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
0c7beb2db9a5 zd1211rw: use struct_size() helper
--
https://patchwork.kernel.org/patch/10884349/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: prevent an array overflow
From: Kalle Valo @ 2019-04-25 16:50 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amitkumar Karwar, Xinming Hu, Nishant Sarmukadam, Ganapathi Bhat,
linux-wireless, kernel-janitors
In-Reply-To: <20190404084423.GB20193@kadam>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> 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>
Patch applied to wireless-drivers-next.git, thanks.
b4c35c17227f mwifiex: prevent an array overflow
--
https://patchwork.kernel.org/patch/10885297/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] b43: Remove empty function lpphy_papd_cal()
From: Kalle Valo @ 2019-04-25 16:51 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger, Arnd Bergmann
In-Reply-To: <20190404184914.12819-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit d825db346270e ("b43: shut up clang -Wuninitialized variable
> warning"), the message noted that function lpphy_papd_cal() was empty
> and had an old TODO regarding its implementation. As the reverse
> engineering project that created the LP-PHY version of this driver
> has not been active for some time, it is safe to remove this empty
> function.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
b25105e126e7 b43: Remove empty function lpphy_papd_cal()
--
https://patchwork.kernel.org/patch/10886095/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: fix error handling in mwl8k_post_cmd()
From: Kalle Valo @ 2019-04-25 16:52 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Lennert Buytenhek, Alexey Khoroshilov, David S. Miller,
linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <1554499598-29351-1-git-send-email-khoroshilov@ispras.ru>
Alexey Khoroshilov <khoroshilov@ispras.ru> wrote:
> If pci_map_single() fails in mwl8k_post_cmd(),
> it returns -ENOMEM immediately, while cleanup is required.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Patch applied to wireless-drivers-next.git, thanks.
d1717282afd5 mwl8k: fix error handling in mwl8k_post_cmd()
--
https://patchwork.kernel.org/patch/10887851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Kalle Valo @ 2019-04-25 16:52 UTC (permalink / raw)
To: Yue Haibing; +Cc: linux-kernel, linux-wireless, davem, netdev, YueHaibing
In-Reply-To: <20190408034529.27500-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> 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>
Patch applied to wireless-drivers-next.git, thanks.
09ac2694b047 at76c50x-usb: Don't register led_trigger if usb_register_driver failed
--
https://patchwork.kernel.org/patch/10888765/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: Fix rate_idx underflow
From: Kalle Valo @ 2019-04-25 16:53 UTC (permalink / raw)
To: Petr Štetiar
Cc: linux-wireless, Lennert Buytenhek, Petr Štetiar, stable
In-Reply-To: <1555006410-6090-1-git-send-email-ynezz@true.cz>
Petr Štetiar wrote:
> It was reported on OpenWrt bug tracking system[1], that several users
> are affected by the endless reboot of their routers if they configure
> 5GHz interface with channel 44 or 48.
>
> The reboot loop is caused by the following excessive number of WARN_ON
> messages:
>
> WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
> ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
>
> as the messages are being correctly emitted by the following guard:
>
> case RX_ENC_LEGACY:
> if (WARN_ON(status->rate_idx >= sband->n_bitrates))
>
> as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
> simply converts previously used magic number to proper constant and
> guards against substraction which is leading to the currently observed
> underflow.
>
> 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
>
> Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive")
> Cc: <stable@vger.kernel.org>
> Tested-by: Eubert Bao <bunnier@gmail.com>
> Reported-by: Eubert Bao <bunnier@gmail.com>
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
Patch applied to wireless-drivers-next.git, thanks.
6b583201fa21 mwl8k: Fix rate_idx underflow
--
https://patchwork.kernel.org/patch/10896599/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/1] mwifiex: add support for SD8987 chipset
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Tamás Szűcs
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Hemantkumar Suthar,
Tamás Szűcs
In-Reply-To: <20190414183641.7539-2-tszucs@protonmail.ch>
Tamás Szűcs wrote:
> This patch adds support for Marvell 88W8987 chipset with SDIO interface.
> Register offsets and supported feature flags are updated. The corresponding
> firmware image file shall be "mrvl/sd8987_uapsta.bin".
>
> Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch>
Patch applied to wireless-drivers-next.git, thanks.
938c7c80c78e mwifiex: add support for SD8987 chipset
--
https://patchwork.kernel.org/patch/10899927/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190415103703.11254-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Fix spelling mistakes in rx stats text. I missed these from an earlier
> round of fixing the same spelling mistake.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
b9574ce1d05e iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
--
https://patchwork.kernel.org/patch/10900491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: fix spelling mistake "capabilties" -> "capabilities"
From: Kalle Valo @ 2019-04-25 16:55 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190415142649.18452-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There various spelling mistakes in function names and in message
> text. Fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
3b989e58e88a mwifiex: fix spelling mistake "capabilties" -> "capabilities"
--
https://patchwork.kernel.org/patch/10900921/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 wireless-drivers-next] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Kalle Valo @ 2019-04-25 16:56 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Ping-Ke Shih, David S. Miller, Larry Finger, linux-wireless,
netdev, linux-kernel, Gustavo A. R. Silva, Kees Cook
In-Reply-To: <20190416151722.GA31598@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Add missing break statement in order to prevent the code from falling
> through to case 0x1025, and erroneously setting rtlhal->oem_id to
> RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
> none of the cases in switch (rtlefuse->eeprom_smid) match.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
84242b82d81c rtlwifi: rtl8723ae: Fix missing break in switch statement
--
https://patchwork.kernel.org/patch/10903325/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: p54: drop device reference count if fails to enable device
From: Kalle Valo @ 2019-04-25 16:57 UTC (permalink / raw)
To: Pan Bian
Cc: Christian Lamparter, David S. Miller, linux-wireless, netdev,
linux-kernel, Pan Bian
In-Reply-To: <1555494083-130833-1-git-send-email-bianpan2016@163.com>
Pan Bian <bianpan2016@163.com> wrote:
> The function p54p_probe takes an extra reference count of the PCI
> device. However, the extra reference count is not dropped when it fails
> to enable the PCI device. This patch fixes the bug.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
8149069db818 p54: drop device reference count if fails to enable device
--
https://patchwork.kernel.org/patch/10905039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Hans de Goede
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Hans de Goede,
linux-wireless, brcm80211-dev-list.pdl, stable
In-Reply-To: <20190422204123.6123-1-hdegoede@redhat.com>
Hans de Goede <hdegoede@redhat.com> wrote:
> The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor
> and product_name DMI strings, without this patch brcmfmac will try to load:
> "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which
> is way too generic.
>
> The DMI strings on which we are matching are somewhat generic too, but
> "To be filled by O.E.M." is less common then "Default string" and the
> system-sku and bios-version strings are pretty unique. Beside the DMI
> strings we also check the wifi-module chip-id and revision. I'm confident
> that the combination of all this is unique.
>
> Both the T8 and T11 use the same wifi-module, this commit adds DMI
> quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt .
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
b1a0ba8f772d brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
--
https://patchwork.kernel.org/patch/10911607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: add RT3883 support
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin, Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1556092164-23823-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> From: Gabor Juhos <juhosg@openwrt.org>
>
> Patch add support for RT3883 chip. Code was taken direclty
> from openwrt project and merge into one patch.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
d0e61a0f7cca rt2x00: add RT3883 support
--
https://patchwork.kernel.org/patch/10914303/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: send mailbox interrupt twice for specific hardware device
From: Kalle Valo @ 2019-04-25 16:59 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, Chi-Hsien Lin, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <1556175939-174559-1-git-send-email-wright.feng@cypress.com>
Wright Feng <Wright.Feng@cypress.com> wrote:
> For PCIE wireless device with core revision less than 14, device may miss
> PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending
> mail box interrupt twice as a hardware workaround.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Failed to compile:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c: In function 'brcmf_pcie_send_mb_data':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: error: 'core' undeclared (first use in this function); did you mean 'cred'?
core = brcmf_chip_get_core(devinfo->ci, BCMA_CORE_PCIE2);
^~~~
cred
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.o] Error 1
make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
make[3]: *** [drivers/net/wireless/broadcom] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10916093/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v8 03/15] wlcore: simplify/fix/optimize reg_ch_conf_pending operations
From: Kalle Valo @ 2019-04-25 17:12 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li , Christopherson Sean J, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless, Fenghua Yu
In-Reply-To: <1556134382-58814-4-git-send-email-fenghua.yu@intel.com>
Fenghua Yu <fenghua.yu@intel.com> wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> Bitmaps are defined on unsigned longs, so the usage of u32[2] in the
> wlcore driver is incorrect. As noted by Peter Zijlstra, casting arrays
> to a bitmap is incorrect for big-endian architectures.
>
> When looking at it I observed that:
>
> - operations on reg_ch_conf_pending is always under the wl_lock mutex,
> so set_bit is overkill
>
> - the only case where reg_ch_conf_pending is accessed a u32 at a time is
> unnecessary too.
>
> This patch cleans up everything in this area, and changes tmp_ch_bitmap
> to have the proper alignment.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Patch applied to wireless-drivers-next.git, thanks.
147b502bda33 wlcore: simplify/fix/optimize reg_ch_conf_pending operations
--
https://patchwork.kernel.org/patch/10915635/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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