* 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] 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] 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] 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] ray_cs: Check return value of pcmcia_register_driver
From: Kalle Valo @ 2019-04-25 16:38 UTC (permalink / raw)
To: Yue Haibing; +Cc: davem, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190306114614.19116-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> 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>
Patch applied to wireless-drivers-next.git, thanks.
444efbde3281 ray_cs: Check return value of pcmcia_register_driver
--
https://patchwork.kernel.org/patch/10840927/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] rndis_wlan: use struct_size() helper
From: Kalle Valo @ 2019-04-25 16:38 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jussi Kivilinna, David S. Miller, linux-wireless, netdev,
linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20190403182334.GA3986@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(*pmkids) + max_pmkids * sizeof(pmkids->bssid_info[0])
>
> with:
>
> struct_size(pmkids, bssid_info, num_pmkids)
>
> 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.
d442af2e1bcb rndis_wlan: use struct_size() helper
--
https://patchwork.kernel.org/patch/10884341/
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: Arnd Bergmann @ 2019-04-25 15:55 UTC (permalink / raw)
To: Al Viro
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: <20190425153534.GS2217@ZenIV.linux.org.uk>
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.
Arnd
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Mauro Carvalho Chehab @ 2019-04-25 15:53 UTC (permalink / raw)
To: Al Viro
Cc: Arnd Bergmann, linux-fsdevel, y2038, linux-kernel,
Jason Gunthorpe, Daniel Vetter, Greg Kroah-Hartman, David Sterba,
Darren Hart, Jonathan Cameron, Bjorn Andersson, devel, qat-linux,
linux-crypto, linux-media, dri-devel, linaro-mm-sig, amd-gfx,
linux-input, linux-iio, linux-rdma, linux-nvdimm, linux-nvme,
linux-pci, platform-driver-x86, linux-remoteproc, sparclinux,
linux-scsi, linux-usb, linux-btrfs, ceph-devel, linux-wireless,
netdev, Sean Young
In-Reply-To: <20190425153534.GS2217@ZenIV.linux.org.uk>
Em Thu, 25 Apr 2019 16:35:34 +0100
Al Viro <viro@zeniv.linux.org.uk> escreveu:
> 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
That's the case for all LIRC ioctls: they all use a pointer to u32
argument.
> pointer to string => OK
> pointer to u64 => OK
> pointer to struct {u64 addr; char s[11];} => OK
> pointer to long => needs explicit handler
> pointer to struct {void *addr; char s[11];} => needs explicit handler
> pointer to struct {int x; u64 y;} => needs explicit handler on amd64
> For "just use ->unlocked_ioctl for ->ioctl" we have
> argument ignored => OK
> any arithmetical type => OK
> any pointer => instant breakage on s390, in addtion to cases that break
> with compat_ptr_ioctl().
>
> Probably some form of that ought to go into commit message for compat_ptr_ioctl()
> introduction...
Agreed.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Al Viro @ 2019-04-25 15:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Arnd Bergmann, linux-fsdevel, y2038, linux-kernel,
Jason Gunthorpe, Daniel Vetter, Greg Kroah-Hartman, David Sterba,
Darren Hart, Jonathan Cameron, Bjorn Andersson, devel, qat-linux,
linux-crypto, linux-media, dri-devel, linaro-mm-sig, amd-gfx,
linux-input, linux-iio, linux-rdma, linux-nvdimm, linux-nvme,
linux-pci, platform-driver-x86, linux-remoteproc, sparclinux,
linux-scsi, linux-usb, linux-btrfs, ceph-devel, linux-wireless,
netdev, Sean Young
In-Reply-To: <20190425122153.450fc094@coco.lan>
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
pointer to long => needs explicit handler
pointer to struct {void *addr; char s[11];} => needs explicit handler
pointer to struct {int x; u64 y;} => needs explicit handler on amd64
For "just use ->unlocked_ioctl for ->ioctl" we have
argument ignored => OK
any arithmetical type => OK
any pointer => instant breakage on s390, in addtion to cases that break
with compat_ptr_ioctl().
Probably some form of that ought to go into commit message for compat_ptr_ioctl()
introduction...
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Arnd Bergmann @ 2019-04-25 15:32 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Alexander Viro, 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: <20190425122153.450fc094@coco.lan>
On Thu, Apr 25, 2019 at 5:22 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> Em Tue, 16 Apr 2019 22:25:33 +0200 Arnd Bergmann <arnd@arndb.de> escreveu:
>
> If I understand your patch description well, using compat_ptr_ioctl
> only works if the driver is not for s390, right?
No, the purpose of compat_ptr_ioctl() is to make sure it works
everywhere including s390.
Even on s390 it tends to work most of the time, but for correctness
the upper bit of a 32-bit pointer needs to be cleared, as
compat_ptr_ioctl does, in case some application passes a pointer
with that bit set. [IIRC, in the instruction pointer, the high bit is set, in
data references it is ignored but usually cleared, but it may be left
on for IP-relative address generation]
Arnd
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2019-04-18-2
From: Kalle Valo @ 2019-04-25 15:29 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi, david.e.box, joe.konno
In-Reply-To: <560ba2b6a20ac9842fd6a5a5d786def1077811f4.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is a new version of my pull request on top of your tree after you
> fast-forwarded to net-next, to avoid a small conflict.
>
> This is the third batch of patches intended for v5.2. This includes
> the last patchset I sent. Usual development work. More details about
> the contents in the tag description.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 5c2e6e14a0ad24a35d9d2b318204c8c012d9d618:
>
> Merge branch 'net-add-reset-controller-driven-PHY-reset' (2019-04-18 17:43:11 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2019-04-18-2
>
> for you to fetch changes up to 69166f7a37dc0bde5a3c26945e3cdbfc740b0562:
>
> iwlwifi: dbg_ini: set dump bit only when trigger collection is certain (2019-04-19 10:27:34 +0300)
>
> ----------------------------------------------------------------
> Third batch of patches intended for v5.2
>
> * Bump the 20000-series FW API version supported;
> * Work on the new debugging infra continues;
> * One clean-up to prevent a bogus warning with clang;
> * A small cleanup in the PCI ID list;
> * Work on new hardware continues;
> * RTT confidence indication support for FTM;
> * An improvement in HE rate-scaling;
>
> ----------------------------------------------------------------
Pulled, thanks Luca.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Mauro Carvalho Chehab @ 2019-04-25 15:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexander Viro, linux-fsdevel, y2038, linux-kernel,
Jason Gunthorpe, Daniel Vetter, Greg Kroah-Hartman, David Sterba,
Darren Hart, Jonathan Cameron, Bjorn Andersson, devel, qat-linux,
linux-crypto, linux-media, dri-devel, linaro-mm-sig, amd-gfx,
linux-input, linux-iio, linux-rdma, linux-nvdimm, linux-nvme,
linux-pci, platform-driver-x86, linux-remoteproc, sparclinux,
linux-scsi, linux-usb, linux-btrfs, ceph-devel, linux-wireless,
netdev, Sean Young
In-Reply-To: <20190416202701.127745-1-arnd@arndb.de>
Em Tue, 16 Apr 2019 22:25:33 +0200
Arnd Bergmann <arnd@arndb.de> escreveu:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Acked-by: Jason Gunthorpe <jgg@mellanox.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: David Sterba <dsterba@suse.com>
> Acked-by: Darren Hart (VMware) <dvhart@infradead.org>
> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/android/binder.c | 2 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +---
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
> drivers/hid/hidraw.c | 4 +---
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 ++--
> drivers/media/rc/lirc_dev.c | 4 +---
If I understand your patch description well, using compat_ptr_ioctl
only works if the driver is not for s390, right?
In thesis, nothing prevents to use LIRC API on s390 - as this isn't
a driver but, instead, RC core feature to expose raw remote controller
codes to userspace.
Yet, lirc_dev will only work if the system has a remote controller driver.
Well, we don't have any for s390. Despite we don't have such driver,
I can't possible see why someone would use a remote controller for a
mainframe :-p
Anyway, if someone ever come with such driver/usecase, reverting this
change (or adding an #ifdef to check if arch is 390) should be
pretty straight forward.
So:
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> drivers/mfd/cros_ec_dev.c | 4 +---
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/nvdimm/bus.c | 4 ++--
> drivers/nvme/host/core.c | 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 ++--
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +---
> drivers/scsi/3w-xxxx.c | 4 +---
> drivers/scsi/cxlflash/main.c | 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/pmcraid.c | 4 +---
> drivers/staging/android/ion/ion.c | 4 +---
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +---
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c | 2 +-
> fs/ceph/dir.c | 2 +-
> fs/ceph/file.c | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c | 2 +-
> net/rfkill/core.c | 2 +-
> 36 files changed, 39 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 4b9c7ca492e6..48109ade7234 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5998,7 +5998,7 @@ const struct file_operations binder_fops = {
> .owner = THIS_MODULE,
> .poll = binder_poll,
> .unlocked_ioctl = binder_ioctl,
> - .compat_ioctl = binder_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .mmap = binder_mmap,
> .open = binder_open,
> .flush = binder_flush,
> diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> index abc7a7f64d64..ef0e482ee04f 100644
> --- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> +++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> @@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int cmd, unsigned long arg);
> static const struct file_operations adf_ctl_ops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = adf_ctl_ioctl,
> - .compat_ioctl = adf_ctl_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> struct adf_ctl_drv_info {
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 7c858020d14b..0cb336fe6324 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -325,9 +325,7 @@ static const struct file_operations dma_buf_fops = {
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> .unlocked_ioctl = dma_buf_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = dma_buf_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> /*
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index 32dcf7b4c935..411de6a8a0ad 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -419,5 +419,5 @@ const struct file_operations sw_sync_debugfs_fops = {
> .open = sw_sync_debugfs_open,
> .release = sw_sync_debugfs_release,
> .unlocked_ioctl = sw_sync_ioctl,
> - .compat_ioctl = sw_sync_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 4f6305ca52c8..0949f91eb85f 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -488,5 +488,5 @@ static const struct file_operations sync_file_fops = {
> .release = sync_file_release,
> .poll = sync_file_poll,
> .unlocked_ioctl = sync_file_ioctl,
> - .compat_ioctl = sync_file_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 083bd8114db1..5d6ac7885aa7 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -49,7 +49,7 @@ static const char kfd_dev_name[] = "kfd";
> static const struct file_operations kfd_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = kfd_ioctl,
> - .compat_ioctl = kfd_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .open = kfd_open,
> .mmap = kfd_mmap,
> };
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index 9fc51eff1079..e7284d38b66d 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -476,9 +476,7 @@ static const struct file_operations hidraw_ops = {
> .release = hidraw_release,
> .unlocked_ioctl = hidraw_ioctl,
> .fasync = hidraw_fasync,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = hidraw_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4700fd5d8c90..eed1bea257b4 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1635,7 +1635,7 @@ static const struct file_operations iio_buffer_fileops = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static int iio_check_unique_scan_index(struct iio_dev *indio_dev)
> diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c
> index 70b7d80431a9..ac4321d7c800 100644
> --- a/drivers/infiniband/core/uverbs_main.c
> +++ b/drivers/infiniband/core/uverbs_main.c
> @@ -1120,7 +1120,7 @@ static const struct file_operations uverbs_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static const struct file_operations uverbs_mmap_fops = {
> @@ -1131,7 +1131,7 @@ static const struct file_operations uverbs_mmap_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static struct ib_client uverbs_client = {
> diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
> index f862f1b7f996..9ccc7e9cbc8e 100644
> --- a/drivers/media/rc/lirc_dev.c
> +++ b/drivers/media/rc/lirc_dev.c
> @@ -730,9 +730,7 @@ static const struct file_operations lirc_fops = {
> .owner = THIS_MODULE,
> .write = ir_lirc_transmit_ir,
> .unlocked_ioctl = ir_lirc_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = ir_lirc_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .read = ir_lirc_read,
> .poll = ir_lirc_poll,
> .open = ir_lirc_open,
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index d275deaecb12..4a602a40d75c 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -251,9 +251,7 @@ static const struct file_operations fops = {
> .release = ec_device_release,
> .read = ec_device_read,
> .unlocked_ioctl = ec_device_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = ec_device_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static void cros_ec_class_release(struct device *dev)
> diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c
> index 997f92543dd4..5bb406dabe85 100644
> --- a/drivers/misc/vmw_vmci/vmci_host.c
> +++ b/drivers/misc/vmw_vmci/vmci_host.c
> @@ -969,7 +969,7 @@ static const struct file_operations vmuser_fops = {
> .release = vmci_host_close,
> .poll = vmci_host_poll,
> .unlocked_ioctl = vmci_host_unlocked_ioctl,
> - .compat_ioctl = vmci_host_unlocked_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static struct miscdevice vmci_host_miscdev = {
> diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
> index 7bbff0af29b2..065ebd584482 100644
> --- a/drivers/nvdimm/bus.c
> +++ b/drivers/nvdimm/bus.c
> @@ -1167,7 +1167,7 @@ static const struct file_operations nvdimm_bus_fops = {
> .owner = THIS_MODULE,
> .open = nd_open,
> .unlocked_ioctl = nd_ioctl,
> - .compat_ioctl = nd_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> @@ -1175,7 +1175,7 @@ static const struct file_operations nvdimm_fops = {
> .owner = THIS_MODULE,
> .open = nd_open,
> .unlocked_ioctl = nvdimm_ioctl,
> - .compat_ioctl = nvdimm_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 2c43e12b70af..560929bee5ce 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2739,7 +2739,7 @@ static const struct file_operations nvme_dev_fops = {
> .owner = THIS_MODULE,
> .open = nvme_dev_open,
> .unlocked_ioctl = nvme_dev_ioctl,
> - .compat_ioctl = nvme_dev_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static ssize_t nvme_sysfs_reset(struct device *dev,
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index e22766c79fe9..3a54b4b616e2 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -1006,7 +1006,7 @@ static const struct file_operations switchtec_fops = {
> .read = switchtec_dev_read,
> .poll = switchtec_dev_poll,
> .unlocked_ioctl = switchtec_dev_ioctl,
> - .compat_ioctl = switchtec_dev_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static void link_event_work(struct work_struct *work)
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 7b26b6ccf1a0..dded9cef42f4 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -889,7 +889,7 @@ static const struct file_operations wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static int wmi_dev_probe(struct device *dev)
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index eea5ebbb5119..507bfe163883 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -290,7 +290,7 @@ static const struct file_operations rpmsg_eptdev_fops = {
> .write_iter = rpmsg_eptdev_write_iter,
> .poll = rpmsg_eptdev_poll,
> .unlocked_ioctl = rpmsg_eptdev_ioctl,
> - .compat_ioctl = rpmsg_eptdev_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static ssize_t name_show(struct device *dev, struct device_attribute *attr,
> @@ -451,7 +451,7 @@ static const struct file_operations rpmsg_ctrldev_fops = {
> .open = rpmsg_ctrldev_open,
> .release = rpmsg_ctrldev_release,
> .unlocked_ioctl = rpmsg_ctrldev_ioctl,
> - .compat_ioctl = rpmsg_ctrldev_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static void rpmsg_ctrldev_release_device(struct device *dev)
> diff --git a/drivers/sbus/char/display7seg.c b/drivers/sbus/char/display7seg.c
> index a36e4cf1841d..c9f60656f54d 100644
> --- a/drivers/sbus/char/display7seg.c
> +++ b/drivers/sbus/char/display7seg.c
> @@ -155,7 +155,7 @@ static long d7s_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> static const struct file_operations d7s_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = d7s_ioctl,
> - .compat_ioctl = d7s_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .open = d7s_open,
> .release = d7s_release,
> .llseek = noop_llseek,
> diff --git a/drivers/sbus/char/envctrl.c b/drivers/sbus/char/envctrl.c
> index 1a6e7224017c..dd2dfa85fc68 100644
> --- a/drivers/sbus/char/envctrl.c
> +++ b/drivers/sbus/char/envctrl.c
> @@ -714,9 +714,7 @@ static const struct file_operations envctrl_fops = {
> .owner = THIS_MODULE,
> .read = envctrl_read,
> .unlocked_ioctl = envctrl_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = envctrl_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .open = envctrl_open,
> .release = envctrl_release,
> .llseek = noop_llseek,
> diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
> index 2b1e0d503020..fb6444d0409c 100644
> --- a/drivers/scsi/3w-xxxx.c
> +++ b/drivers/scsi/3w-xxxx.c
> @@ -1049,9 +1049,7 @@ static int tw_chrdev_open(struct inode *inode, struct file *file)
> static const struct file_operations tw_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = tw_chrdev_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = tw_chrdev_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .open = tw_chrdev_open,
> .release = NULL,
> .llseek = noop_llseek,
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index 7096810fd222..e13d5de1d76e 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -3589,7 +3589,7 @@ static const struct file_operations cxlflash_chr_fops = {
> .owner = THIS_MODULE,
> .open = cxlflash_chr_open,
> .unlocked_ioctl = cxlflash_chr_ioctl,
> - .compat_ioctl = cxlflash_chr_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> /**
> diff --git a/drivers/scsi/esas2r/esas2r_main.c b/drivers/scsi/esas2r/esas2r_main.c
> index fdbda5c05aa0..80c5a235d193 100644
> --- a/drivers/scsi/esas2r/esas2r_main.c
> +++ b/drivers/scsi/esas2r/esas2r_main.c
> @@ -613,7 +613,7 @@ static int __init esas2r_init(void)
>
> /* Handle ioctl calls to "/proc/scsi/esas2r/ATTOnode" */
> static const struct file_operations esas2r_proc_fops = {
> - .compat_ioctl = esas2r_proc_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .unlocked_ioctl = esas2r_proc_ioctl,
> };
>
> diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
> index e338d7a4f571..c0a1a1218c56 100644
> --- a/drivers/scsi/pmcraid.c
> +++ b/drivers/scsi/pmcraid.c
> @@ -3988,9 +3988,7 @@ static const struct file_operations pmcraid_fops = {
> .open = pmcraid_chr_open,
> .fasync = pmcraid_chr_fasync,
> .unlocked_ioctl = pmcraid_chr_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = pmcraid_chr_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index 92c2914239e3..1663c163edca 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -567,9 +567,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> static const struct file_operations ion_fops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = ion_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = ion_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static int debug_shrink_set(void *data, u64 val)
> diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme/devices/vme_user.c
> index 6a33aaa1a49f..fd0ea4dbcb91 100644
> --- a/drivers/staging/vme/devices/vme_user.c
> +++ b/drivers/staging/vme/devices/vme_user.c
> @@ -494,7 +494,7 @@ static const struct file_operations vme_user_fops = {
> .write = vme_user_write,
> .llseek = vme_user_llseek,
> .unlocked_ioctl = vme_user_unlocked_ioctl,
> - .compat_ioctl = vme_user_unlocked_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .mmap = vme_user_mmap,
> };
>
> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> index 17c64fccbb10..eb97acf09868 100644
> --- a/drivers/tee/tee_core.c
> +++ b/drivers/tee/tee_core.c
> @@ -684,7 +684,7 @@ static const struct file_operations tee_fops = {
> .open = tee_open,
> .release = tee_release,
> .unlocked_ioctl = tee_ioctl,
> - .compat_ioctl = tee_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static void tee_release_device(struct device *dev)
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> index 9e9caff905d5..d48c032580d0 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -724,7 +724,7 @@ static const struct file_operations wdm_fops = {
> .release = wdm_release,
> .poll = wdm_poll,
> .unlocked_ioctl = wdm_ioctl,
> - .compat_ioctl = wdm_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 4942122b2346..bbd0308b13f5 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -2220,9 +2220,7 @@ static const struct file_operations fops = {
> .release = usbtmc_release,
> .flush = usbtmc_flush,
> .unlocked_ioctl = usbtmc_ioctl,
> -#ifdef CONFIG_COMPAT
> - .compat_ioctl = usbtmc_ioctl,
> -#endif
> + .compat_ioctl = compat_ptr_ioctl,
> .fasync = usbtmc_fasync,
> .poll = usbtmc_poll,
> .llseek = default_llseek,
> diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
> index 8ba726e600e9..fbf02bf60f62 100644
> --- a/drivers/virt/fsl_hypervisor.c
> +++ b/drivers/virt/fsl_hypervisor.c
> @@ -703,7 +703,7 @@ static const struct file_operations fsl_hv_fops = {
> .poll = fsl_hv_poll,
> .read = fsl_hv_read,
> .unlocked_ioctl = fsl_hv_ioctl,
> - .compat_ioctl = fsl_hv_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> static struct miscdevice fsl_hv_misc_dev = {
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 120e4340792a..162ea4b6b417 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -2307,7 +2307,7 @@ static const struct super_operations btrfs_super_ops = {
> static const struct file_operations btrfs_ctl_fops = {
> .open = btrfs_control_open,
> .unlocked_ioctl = btrfs_control_ioctl,
> - .compat_ioctl = btrfs_control_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> };
> diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> index 7c060cb22aa3..a493b957713f 100644
> --- a/fs/ceph/dir.c
> +++ b/fs/ceph/dir.c
> @@ -1785,7 +1785,7 @@ const struct file_operations ceph_dir_fops = {
> .open = ceph_open,
> .release = ceph_release,
> .unlocked_ioctl = ceph_ioctl,
> - .compat_ioctl = ceph_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .fsync = ceph_fsync,
> .lock = ceph_lock,
> .flock = ceph_flock,
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 9f53c3d99304..9b5fe7eee3c1 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -2112,7 +2112,7 @@ const struct file_operations ceph_file_fops = {
> .splice_read = generic_file_splice_read,
> .splice_write = iter_file_splice_write,
> .unlocked_ioctl = ceph_ioctl,
> - .compat_ioctl = ceph_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .fallocate = ceph_fallocate,
> .copy_file_range = ceph_copy_file_range,
> };
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 9971a35cf1ef..dcdb26068b71 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -2354,7 +2354,7 @@ const struct file_operations fuse_dev_operations = {
> .release = fuse_dev_release,
> .fasync = fuse_dev_fasync,
> .unlocked_ioctl = fuse_dev_ioctl,
> - .compat_ioctl = fuse_dev_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
> EXPORT_SYMBOL_GPL(fuse_dev_operations);
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index a90bb19dcfa2..a55aa029a308 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -523,7 +523,7 @@ static const struct file_operations fanotify_fops = {
> .fasync = NULL,
> .release = fanotify_release,
> .unlocked_ioctl = fanotify_ioctl,
> - .compat_ioctl = fanotify_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 89800fc7dc9d..f93dcf8c996f 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -1901,7 +1901,7 @@ static const struct file_operations userfaultfd_fops = {
> .poll = userfaultfd_poll,
> .read = userfaultfd_read,
> .unlocked_ioctl = userfaultfd_ioctl,
> - .compat_ioctl = userfaultfd_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index abca57040f37..3b2f6ea44397 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -1323,7 +1323,7 @@ static const struct file_operations rfkill_fops = {
> .release = rfkill_fop_release,
> #ifdef CONFIG_RFKILL_INPUT
> .unlocked_ioctl = rfkill_fop_ioctl,
> - .compat_ioctl = rfkill_fop_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> #endif
> .llseek = no_llseek,
> };
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 wireless-drivers-next] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Gustavo A. R. Silva @ 2019-04-25 14:27 UTC (permalink / raw)
To: Kalle Valo
Cc: Ping-Ke Shih, David S. Miller, Larry Finger, linux-wireless,
netdev, linux-kernel, Kees Cook
In-Reply-To: <87zhoewhll.fsf@kamboji.qca.qualcomm.com>
On 4/25/19 4:37 AM, Kalle Valo wrote:
> "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes:
>
>> Hi all,
>>
>> Friendly ping:
>>
>> Who can take this?
>
> It's in my queue.
>
Awesome. :)
Thank you
--
Gustavo
^ permalink raw reply
* [PATCH] mt76: fix endianness sparse warnings
From: Ryder Lee @ 2019-04-25 14:42 UTC (permalink / raw)
To: Lorenzo Bianconi, Felix Fietkau
Cc: Roy Luo, Sean Wang, linux-wireless, linux-mediatek, linux-kernel,
Ryder Lee
Fix many warnings with incorrect endian assumptions.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 12 ++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
index 2f2961ee0a92..af5769d05e6f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
@@ -627,7 +627,7 @@ mt7603_mac_fill_rx(struct mt7603_dev *dev, struct sk_buff *skb)
status->aggr = unicast &&
!ieee80211_is_qos_nullfunc(hdr->frame_control);
status->tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
- status->seqno = IEEE80211_SEQ_TO_SN(hdr->seq_ctrl);
+ status->seqno = IEEE80211_SEQ_TO_SN(__le16_to_cpu(hdr->seq_ctrl));
return 0;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 1bf3e7b5f6a7..4b934b0f5a39 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -235,7 +235,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
status->aggr = unicast &&
!ieee80211_is_qos_nullfunc(hdr->frame_control);
status->tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
- status->seqno = IEEE80211_SEQ_TO_SN(hdr->seq_ctrl);
+ status->seqno = IEEE80211_SEQ_TO_SN(__le16_to_cpu(hdr->seq_ctrl));
return 0;
}
@@ -337,7 +337,7 @@ int mt7615_mac_write_txwi(struct mt7615_dev *dev, __le32 *txwi,
struct ieee80211_vif *vif = info->control.vif;
int tx_count = 8;
u8 fc_type, fc_stype, p_fmt, q_idx, omac_idx = 0;
- u16 fc = le16_to_cpu(hdr->frame_control);
+ __le16 fc = hdr->frame_control;
u16 seqno = 0;
u32 val;
@@ -353,8 +353,8 @@ int mt7615_mac_write_txwi(struct mt7615_dev *dev, __le32 *txwi,
tx_count = msta->rate_count;
}
- fc_type = (fc & IEEE80211_FCTL_FTYPE) >> 2;
- fc_stype = (fc & IEEE80211_FCTL_STYPE) >> 4;
+ fc_type = (le16_to_cpu(fc) & IEEE80211_FCTL_FTYPE) >> 2;
+ fc_stype = (le16_to_cpu(fc) & IEEE80211_FCTL_STYPE) >> 4;
if (ieee80211_is_data(fc)) {
q_idx = skb_get_queue_mapping(skb);
@@ -468,7 +468,7 @@ void mt7615_txp_skb_unmap(struct mt76_dev *dev,
txp = (struct mt7615_txp *)(txwi + MT_TXD_SIZE);
for (i = 1; i < txp->nbuf; i++)
dma_unmap_single(dev->dev, le32_to_cpu(txp->buf[i]),
- le32_to_cpu(txp->len[i]), DMA_TO_DEVICE);
+ le16_to_cpu(txp->len[i]), DMA_TO_DEVICE);
}
int mt7615_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
@@ -506,7 +506,7 @@ int mt7615_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
txp = (struct mt7615_txp *)(txwi + MT_TXD_SIZE);
for (i = 0; i < nbuf; i++) {
txp->buf[i] = cpu_to_le32(tx_info->buf[i + 1].addr);
- txp->len[i] = cpu_to_le32(tx_info->buf[i + 1].len);
+ txp->len[i] = cpu_to_le16(tx_info->buf[i + 1].len);
}
txp->nbuf = nbuf;
--
2.18.0
^ permalink raw reply related
* RE: [PATCH v8 13/15] x86/split_lock: Enable split lock detection by default
From: Thomas Gleixner @ 2019-04-25 13:04 UTC (permalink / raw)
To: David Laight
Cc: 'Fenghua Yu', Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <551673e41ac649689243cbe060364b0d@AcuMS.aculab.com>
On Thu, 25 Apr 2019, David Laight wrote:
> From: Thomas Gleixne]
> > Sent: 25 April 2019 11:59
> > On Thu, 25 Apr 2019, David Laight wrote:
> >
> > > From: Fenghua Yu
> > > > Sent: 24 April 2019 20:33
> > > > A split locked access locks bus and degrades overall memory access
> > > > performance. When split lock detection feature is enumerated, enable
> > > > the feature by default by writing 1 to bit 29 in MSR TEST_CTL to find
> > > > any split lock issue.
> > >
> > > You can't enable this by default until ALL the known potentially
> > > misaligned locked memory operations have been fixed.
> >
> > Errm? The result will be a WARN_ON() printed and no further damage.
>
> ISTR something about sending SIGSEGV to userspace.
Nope. If the #AC originates from kernel then a warning is printed and the
detection is disabled.
Userspace is a different story. We cannot audit all user space upfront,
right?
> > It's not making anything worse than it is now. In fact we just should add a
> >
> > WARN_ON_ONCE(!aligned_to_long(p)) to all the xxx_bit() operations.
> >
> > so we catch them even when they do not trigger that #AC thingy.
>
> That will explode the kernel code size.
So what? We have enough debug options which make the kernel big. One more
does not really matter.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 0/3] mt76: suspend/stop/removal fixes
From: Felix Fietkau @ 2019-04-25 12:37 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Lorenzo Bianconi
In-Reply-To: <20190423103709.7272-1-sgruszka@redhat.com>
On 2019-04-23 12:37, Stanislaw Gruszka wrote:
> Fixes for some coroner cases during suspend/stop/removal intended to
> -next since problems are not reproducible in practice and changes
> relay on -next patches.
Patch 2 and 3 don't apply anymore. Please rebase and resend.
Thanks,
- Felix
^ permalink raw reply
* Re: [PATCH v8 13/15] x86/split_lock: Enable split lock detection by default
From: Peter Zijlstra @ 2019-04-25 11:41 UTC (permalink / raw)
To: David Laight
Cc: 'Thomas Gleixner', 'Fenghua Yu', Ingo Molnar,
Borislav Petkov, H Peter Anvin, Paolo Bonzini, Dave Hansen,
Ashok Raj, Ravi V Shankar, Xiaoyao Li, Christopherson Sean J,
Kalle Valo, Michael Chan, linux-kernel, x86, kvm@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <551673e41ac649689243cbe060364b0d@AcuMS.aculab.com>
On Thu, Apr 25, 2019 at 11:13:23AM +0000, David Laight wrote:
> I'm not at all sure that 'compare and exchange' operations
> are atomic on all cpus if the data is misaligned and crosses
> a page boundary and either (or both) pages need faulting in
> (or hit a TLB miss).
Most sane architectures already trap if you attempt that.
^ permalink raw reply
* Re: [PATCH] brcmfmac: allocate msgbuf pktid from 1 to pktids array size
From: Arend Van Spriel @ 2019-04-25 11:22 UTC (permalink / raw)
To: Wright Feng, franky.lin@broadcom.com, hante.meuleman@broadcom.com,
kvalo@codeaurora.org, Chi-Hsien Lin
Cc: linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <1556179487-147593-1-git-send-email-wright.feng@cypress.com>
On 4/25/2019 10:04 AM, Wright Feng wrote:
> Some PCIE firmwares drop txstatus if pktid is 0 and make packet held in
> host side and not be released. If that packet type is 802.1x, the
> pend_8021x_cnt value will be always greater than 0 and show "Timed out
> waiting for no pending 802.1x packets" error message when sending key to
> dongle.
>
> To be compatible with all firmwares, host should allocate msgbuf pktid
> from 1 instead of from 0.
looking at it we are wasting entry 0 with this patch. Could we avoid that?
Regards,
Arend
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> index d3780ea..b2fab3c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
> @@ -348,7 +348,7 @@ brcmf_msgbuf_alloc_pktid(struct device *dev,
> do {
> (*idx)++;
> if (*idx == pktids->array_size)
> - *idx = 0;
> + *idx = 1;
> if (array[*idx].allocated.counter == 0)
> if (atomic_cmpxchg(&array[*idx].allocated, 0, 1) == 0)
> break;
>
^ permalink raw reply
* RE: [PATCH v8 13/15] x86/split_lock: Enable split lock detection by default
From: David Laight @ 2019-04-25 11:13 UTC (permalink / raw)
To: 'Thomas Gleixner'
Cc: 'Fenghua Yu', Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <alpine.DEB.2.21.1904251255590.1960@nanos.tec.linutronix.de>
From: Thomas Gleixne]
> Sent: 25 April 2019 11:59
> On Thu, 25 Apr 2019, David Laight wrote:
>
> > From: Fenghua Yu
> > > Sent: 24 April 2019 20:33
> > > A split locked access locks bus and degrades overall memory access
> > > performance. When split lock detection feature is enumerated, enable
> > > the feature by default by writing 1 to bit 29 in MSR TEST_CTL to find
> > > any split lock issue.
> >
> > You can't enable this by default until ALL the known potentially
> > misaligned locked memory operations have been fixed.
>
> Errm? The result will be a WARN_ON() printed and no further damage.
ISTR something about sending SIGSEGV to userspace.
> It's not making anything worse than it is now. In fact we just should add a
>
> WARN_ON_ONCE(!aligned_to_long(p)) to all the xxx_bit() operations.
>
> so we catch them even when they do not trigger that #AC thingy.
That will explode the kernel code size.
In any case some of the items I found in a quick scan were bss/data
so the alignment will vary from build to build.
I also found some casts on the xxx_bit() functions in generic code.
I didn't look to see how badly wrong they go on BE systems.
While the x86 xxx_bit() functions could easily be changed to do
32bit accesses, the 'misaligned' operations will affect all
architectures - and may have different effects on others.
I'm not at all sure that 'compare and exchange' operations
are atomic on all cpus if the data is misaligned and crosses
a page boundary and either (or both) pages need faulting in
(or hit a TLB miss).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] mwifiex: Make resume actually do something useful again on SDIO cards
From: Kalle Valo @ 2019-04-25 11:05 UTC (permalink / raw)
To: Douglas Anderson
Cc: linux-rockchip, briannorris, mka, ryandcase, heiko,
Douglas Anderson, David S. Miller, Ganapathi Bhat, linux-wireless,
Amitkumar Karwar, linux-kernel, Nishant Sarmukadam, netdev,
Xinming Hu
In-Reply-To: <20190404040106.40519-1-dianders@chromium.org>
Douglas Anderson <dianders@chromium.org> wrote:
> The commit fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent
> adapter status variables") had a fairly straightforward bug in it. It
> contained this bit of diff:
>
> - if (!adapter->is_suspended) {
> + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) {
>
> As you can see the patch missed the "!" when converting to the atomic
> bitops. This meant that the resume hasn't done anything at all since
> that commit landed and suspend/resume for mwifiex SDIO cards has been
> totally broken.
>
> After fixing this mwifiex suspend/resume appears to work again, at
> least with the simple testing I've done.
>
> Fixes: fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent adapter status variables")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers.git, thanks.
b82d6c1f8f82 mwifiex: Make resume actually do something useful again on SDIO cards
--
https://patchwork.kernel.org/patch/10884883/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RE: [PATCH v8 13/15] x86/split_lock: Enable split lock detection by default
From: Thomas Gleixner @ 2019-04-25 10:58 UTC (permalink / raw)
To: David Laight
Cc: 'Fenghua Yu', Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <762682ba43a0468897ff5ddbf6633d58@AcuMS.aculab.com>
On Thu, 25 Apr 2019, David Laight wrote:
> From: Fenghua Yu
> > Sent: 24 April 2019 20:33
> > A split locked access locks bus and degrades overall memory access
> > performance. When split lock detection feature is enumerated, enable
> > the feature by default by writing 1 to bit 29 in MSR TEST_CTL to find
> > any split lock issue.
>
> You can't enable this by default until ALL the known potentially
> misaligned locked memory operations have been fixed.
Errm? The result will be a WARN_ON() printed and no further damage. It's
not making anything worse than it is now. In fact we just should add a
WARN_ON_ONCE(!aligned_to_long(p)) to all the xxx_bit() operations.
so we catch them even when they do not trigger that #AC thingy.
Thanks,
tglx
^ permalink raw reply
* RE: [PATCH v8 13/15] x86/split_lock: Enable split lock detection by default
From: David Laight @ 2019-04-25 10:52 UTC (permalink / raw)
To: 'Fenghua Yu', 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, Kalle Valo, Michael Chan
Cc: linux-kernel, x86, kvm@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1556134382-58814-14-git-send-email-fenghua.yu@intel.com>
From: Fenghua Yu
> Sent: 24 April 2019 20:33
> A split locked access locks bus and degrades overall memory access
> performance. When split lock detection feature is enumerated, enable
> the feature by default by writing 1 to bit 29 in MSR TEST_CTL to find
> any split lock issue.
You can't enable this by default until ALL the known potentially
misaligned locked memory operations have been fixed.
AFAICT you've only fixed the ones that have actually faulted.
You've not even fixed the other ones in the same source files
as ones you've 'fixed'.
You need to do a code audit of all the in-tree kernel code
that uses locked operations - especially the 'bit' ones
since a lot of code casts the bitmap address - so it probably
isn't long aligned.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH v3 0/4] Add support for MediaTek MT7615 wireless chipsets
From: Felix Fietkau @ 2019-04-25 10:07 UTC (permalink / raw)
To: Ryder Lee, Lorenzo Bianconi
Cc: Roy Luo, Sean Wang, Nelson Chang, YF Luo, Kai Lin, Rorscha Yang,
Kyle Lee, Miller Shen, Haipin Liang, KL Huang, YH chen,
linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <cover.1554102584.git.ryder.lee@mediatek.com>
On 2019-04-01 09:16, Ryder Lee wrote:
> This adds support for MediaTek MT7615E 4x4 802.11ac PCIe-based chipsets.
>
> The series is based on the Lorenzo's patches:
> https://patchwork.kernel.org/project/linux-wireless/list/?series=95969
>
> In the legacy tx arch, we move and store the whole skb content to the
> on-device memory when we send packets via high speed interface. (e.g. PCIe)
>
> However, MT7615 and the following generation use a new tx arch called
> “cut-through”, which only passes the physical address to the hardware,
> and the packet engine will fetch the packets before transmission.
>
> It saves on-chip memory for high throughput devices, and the token mechanism
> is used to manage the release of skb under this arch.
>
> And there might be other (existing or future) chips that use the same driver
> (e.g. mt7622/mt7663...), this is a starting point to unify MTK wireless chipsets.
>
> Detailed hardware information for this chip could be found on
> https://wikidevi.com/wiki/MediaTek_MT7615
>
> Ryder Lee (4):
> mt76: add mac80211 driver for MT7615 PCIe-based chipsets
> mt76: add unlikely() for dma_mapping_error() check
> mt76: use macro for sn and seq_ctrl conversion
> MAINTAINERS : update entry for mt76 wireless driver
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH v2 0/4] add missing bits for mt7615 support
From: Felix Fietkau @ 2019-04-25 10:06 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: ryder.lee, roychl666, lorenzo.bianconi, linux-wireless
In-Reply-To: <cover.1554194917.git.lorenzo@kernel.org>
On 2019-04-02 11:47, Lorenzo Bianconi wrote:
> This is a preliminary series to add support for mt7615.
> Dynamically allocate txwi descriptor.
> Add missing bit in dma error data path.
> This series is based on https://patchwork.kernel.org/patch/10856027/
>
> Changes since v1:
> - remove flags from mt76_txwi_cache
>
> Lorenzo Bianconi (4):
> mt76: set txwi_size according to the driver value
> mt76: add skb pointer to mt76_tx_info
> mt76: dma: introduce skb field in mt76_txwi_cache
> mt76: dma: add skb check for dummy pointer
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH v2] mt76: usb: reduce locking in mt76u_tx_tasklet
From: Felix Fietkau @ 2019-04-25 9:59 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, lorenzo.bianconi, sgruszka
In-Reply-To: <7e6146236dac0d616519e2a6e4b32fac9a1cae2f.1553541103.git.lorenzo@kernel.org>
On 2019-03-25 20:18, Lorenzo Bianconi wrote:
> Similar to pci counterpart, reduce locking in mt76u_tx_tasklet since
> q->head is managed just in mt76u_tx_tasklet and q->queued is updated
> holding q->lock
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Applied, thanks.
- Felix
^ 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