aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-11arm64: dts: qcom: sm8250 hdk wsa speakersm8250-audioJonathan Marek
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: audioJonathan Marek
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11WIP/HACK: ASoC: qcom: add sm8250 sound card driverJonathan Marek
Mostly copied from sdm845 Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11WIP/HACK: ASoC: qcom: qdsp6: add q6afe-clk driverJonathan Marek
This just enables all the sm8250 audio clocks. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11ASoC: qcom: qdsp6: add support for WSA_CDC_DMA_RX_0 outputJonathan Marek
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11HACK: don't set dpcm_capture for CPU daiJonathan Marek
2020-06-11HACK: ADSP dma_set_mask_and_coherentJonathan Marek
downstream sets DMA range to 0x10000000-0x20000000 for ADSP, this works because addresses are allocated from the top (so it starts just below 0x20000000) Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11HACK: call of_register_apr_devices in separate threadJonathan Marek
Otherwise apr_callback will never be called when trying to probe ADSP drivers which want to talk to the DSP (clock driver). Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11HACK: soundwire hacksJonathan Marek
* Make sure it probes after LPI pinctrl (pinctrl node is set in dts so why doesn't it happen??) * Only enable DAC channels (need this to make it work with 2x WSA config) Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11HACK: pinctrl-lpiJonathan Marek
2020-06-11HACK: wsa-macroJonathan Marek
2020-06-11FROM DOWNSTREAM: wsa-macro and pinctrl-lpiJonathan Marek
2020-06-11soundwire: qcom: enable CPU interrupts for mmio devicesJonathan Marek
This allows the CPU to receive interrupts. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11soundwire: qcom: avoid dependency on CONFIG_SLIMBUSJonathan Marek
The driver may be used without slimbus, so don't depend on slimbus. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11soundwire: qcom: add v1.5.1 compatibleJonathan Marek
Add a compatible string for HW version v1.5.1 on sm8250 SoCs. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11soundwire: qcom: add support for mmio soundwire devicesJonathan Marek
Adds support for qcom soundwire devices with memory mapped IO registers. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11soundwire: qcom: fix abh/ahb typoJonathan Marek
The function name qcom_swrm_abh_reg_read should say ahb, fix that. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11revert text offset changeJonathan Marek
2020-06-11arm64: dts: qcom: add sm8250 hdk dtsJonathan Marek
Add initial HDK865 dts, based on sm8250-mtp, with a few changes. Notably, regulator configs are changed a bit. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: add sm8150 hdk dtsJonathan Marek
Add initial HDK855 dts, based on sm8150-mtp, with a few changes. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: Add USB and PHY device nodesJonathan Marek
Add device nodes for the USB3 controller, QMP SS PHY and SNPS HS PHY. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8150: Add secondary USB and PHY nodesJonathan Marek
Add dts nodes for the secondary USB controller and related PHY nodes. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: add apps_smmu nodeJonathan Marek
Add the apps_smmu node for sm8250. For UFS, now that the kernel initializes the iommu, the stream mappings set by the bootloader are cleared. Adding the iommus property is required so that new mappings are created for UFS. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8150: add apps_smmu nodeJonathan Marek
Add the apps_smmu node for sm8150. For UFS, now that the kernel initializes the iommu, the stream mappings set by the bootloader are cleared. Adding the iommus property is required so that new mappings are created for UFS. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
2020-06-11iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatiblesJonathan Marek
Use the qcom implementation for IOMMU hardware on sm8150 and sm8250 SoCs. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11dt-bindings: arm-smmu: Add sm8150 and sm8250 compatible stringsJonathan Marek
Add compatible strings for sm8150 and sm8250 iommus to documentation. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11phy: qcom-qmp: Add QMP V4 USB3 PHY support for sm8250Jonathan Marek
Add both the DP and UNI PHY for primary/secondary usb controllers. The tables are very similar to sm8150 (serdes_tbl is identical), but there are some differences. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11phy: qcom-qmp: Add QMP V4 USB3 UNIPHYJonathan Marek
Add support for the USB3 PHY used by the secondary usb controller on sm8150 Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11phy: qcom-qmp: Allow different values for second laneJonathan Marek
The primary USB PHY on sm8250 sets some values differently for the second lane. This makes it possible to represent that. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: change ufs node name to ufshcJonathan Marek
The ufs-qcom driver checks that the name matches the androidboot.bootdevice parameter provided by the bootloader, which uses the name ufshc. Without this change UFS fails to probe. I think this is broken behavior from the ufs-qcom driver, but using the name ufshc is consistent with dts for sdm845/sm8150/etc. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: sort nodes by physical addressJonathan Marek
Other dts have nodes sorted by physical address, be consistent with that. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: rename spmi node to spmi_busJonathan Marek
The pm8150 dtsi files refer to it as spmi_bus, so change it. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: use dt-bindings defines for clocksJonathan Marek
Use the dt-bindings defines for qupv3_id_1 node's clocks. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: enable pm8150 rtcJonathan Marek
I don't see any reason for it to be disabled by default. Signed-off-by: Jonathan Marek <jonathan@marek.ca>
2020-06-11arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon"Jonathan Marek
2020-06-11hwspinlock: qcom: Allow mmio usage in addition to sysconBjorn Andersson
In all modern Qualcomm platforms the mutex region of the TCSR is forked off into its own block, all with a offset of 0 and stride of 4096. So add support for directly memory mapping this register space, to avoid the need to represent this block using a syscon. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Baolin Wang <baolin.wang7@gmail.com> Reviewed-by: Vinod Koul <vkoul@kernel.org>
2020-06-11dt-bindings: hwlock: qcom: Allow device on mmio busBjorn Andersson
In all modern Qualcomm platforms the mutex region of the TCSR is forked off into its own block, all with a offset of 0 and stride of 4096. Update the binding to allow the hardware block to be described directly on the mmio bus, in addition to allowing the existing syscon based definition. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org>
2020-06-11dt-bindings: hwlock: qcom: Migrate binding to YAMLBjorn Andersson
Migrate the Qualcomm TCSR mutex binding to YAML to allow validation. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org>
2020-06-11arm64: dts: qcom: sm8250: Add TLMM pinctrl nodeBjorn Andersson
Add the TLMM pinctrl node for SM8250 and reserve pins 28-31 and 40-43 on the MTP as firmware does not allow Linux to touch these pins. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-11arm64: dts: qcom: sm8250: Add cpufreq hw nodeBjorn Andersson
Add cpufreq HW device node to scale 4-Silver/3-Gold/1-Gold+ cores on SM8250 SoCs. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-06-11arm64: dts: qcom: sm8150: Add USB and PHY device nodesJack Pham
Add device nodes for the USB3 controller, QMP SS PHY and SNPS HS PHY. Signed-off-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Tested-by: Vinod Koul <vinod.koul@linaro.org>
2020-06-11Merge tag 'locking-kcsan-2020-06-11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull the Kernel Concurrency Sanitizer from Thomas Gleixner: "The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which relies on compile-time instrumentation, and uses a watchpoint-based sampling approach to detect races. The feature was under development for quite some time and has already found legitimate bugs. Unfortunately it comes with a limitation, which was only understood late in the development cycle: It requires an up to date CLANG-11 compiler CLANG-11 is not yet released (scheduled for June), but it's the only compiler today which handles the kernel requirements and especially the annotations of functions to exclude them from KCSAN instrumentation correctly. These annotations really need to work so that low level entry code and especially int3 text poke handling can be completely isolated. A detailed discussion of the requirements and compiler issues can be found here: https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=XAfqvZHFLrVEkv_uM4aDUWE_kh3Rvbw@mail.gmail.com/ We came to the conclusion that trying to work around compiler limitations and bugs again would end up in a major trainwreck, so requiring a working compiler seemed to be the best choice. For Continous Integration purposes the compiler restriction is manageable and that's where most xxSAN reports come from. For a change this limitation might make GCC people actually look at their bugs. Some issues with CSAN in GCC are 7 years old and one has been 'fixed' 3 years ago with a half baken solution which 'solved' the reported issue but not the underlying problem. The KCSAN developers also ponder to use a GCC plugin to become independent, but that's not something which will show up in a few days. Blocking KCSAN until wide spread compiler support is available is not a really good alternative because the continuous growth of lockless optimizations in the kernel demands proper tooling support" * tag 'locking-kcsan-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (76 commits) compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining compiler.h: Move function attributes to compiler_types.h compiler.h: Avoid nested statement expression in data_race() compiler.h: Remove data_race() and unnecessary checks from {READ,WRITE}_ONCE() kcsan: Update Documentation to change supported compilers kcsan: Remove 'noinline' from __no_kcsan_or_inline kcsan: Pass option tsan-instrument-read-before-write to Clang kcsan: Support distinguishing volatile accesses kcsan: Restrict supported compilers kcsan: Avoid inserting __tsan_func_entry/exit if possible ubsan, kcsan: Don't combine sanitizer with kcov on clang objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn() kcsan: Add __kcsan_{enable,disable}_current() variants checkpatch: Warn about data_race() without comment kcsan: Use GFP_ATOMIC under spin lock Improve KCSAN documentation a bit kcsan: Make reporting aware of KCSAN tests kcsan: Fix function matching in report kcsan: Change data_race() to no longer require marking racing accesses kcsan: Move kcsan_{disable,enable}_current() to kcsan-checks.h ...
2020-06-11Merge tag 'locking-urgent-2020-06-11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull atomics rework from Thomas Gleixner: "Peter Zijlstras rework of atomics and fallbacks. This solves two problems: 1) Compilers uninline small atomic_* static inline functions which can expose them to instrumentation. 2) The instrumentation of atomic primitives was done at the architecture level while composites or fallbacks were provided at the generic level. As a result there are no uninstrumented variants of the fallbacks. Both issues were in the way of fully isolating fragile entry code pathes and especially the text poke int3 handler which is prone to an endless recursion problem when anything in that code path is about to be instrumented. This was always a problem, but got elevated due to the new batch mode updates of tracing. The solution is to mark the functions __always_inline and to flip the fallback and instrumentation so the non-instrumented variants are at the architecture level and the instrumentation is done in generic code. The latter introduces another fallback variant which will go away once all architectures have been moved over to arch_atomic_*" * tag 'locking-urgent-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/atomics: Flip fallbacks and instrumentation asm-generic/atomic: Use __always_inline for fallback wrappers
2020-06-11Merge branch 'akpm' (patches from Andrew)Linus Torvalds
Pull updates from Andrew Morton: "A few fixes and stragglers. Subsystems affected by this patch series: mm/memory-failure, ocfs2, lib/lzo, misc" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: amdgpu: a NULL ->mm does not mean a thread is a kthread lib/lzo: fix ambiguous encoding bug in lzo-rle ocfs2: fix build failure when TCP/IP is disabled mm/memory-failure: send SIGBUS(BUS_MCEERR_AR) only to current thread mm/memory-failure: prioritize prctl(PR_MCE_KILL) over vm.memory_failure_early_kill
2020-06-11amdgpu: a NULL ->mm does not mean a thread is a kthreadChristoph Hellwig
Use the proper API instead. Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD") Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: http://lkml.kernel.org/r/20200404094101.672954-1-hch@lst.de Link: http://lkml.kernel.org/r/20200404094101.672954-2-hch@lst.de Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-11lib/lzo: fix ambiguous encoding bug in lzo-rleDave Rodgman
In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Signed-off-by: Dave Rodgman <dave.rodgman@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Dave Rodgman <dave.rodgman@arm.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Chao Yu <yuchao0@huawei.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-11ocfs2: fix build failure when TCP/IP is disabledTom Seewald
After commit 12abc5ee7873 ("tcp: add tcp_sock_set_nodelay") and commit c488aeadcbd0 ("tcp: add tcp_sock_set_user_timeout"), building the kernel with OCFS2_FS=y but without INET=y causes it to fail with: ld: fs/ocfs2/cluster/tcp.o: in function `o2net_accept_many': tcp.c:(.text+0x21b1): undefined reference to `tcp_sock_set_nodelay' ld: tcp.c:(.text+0x21c1): undefined reference to `tcp_sock_set_user_timeout' ld: fs/ocfs2/cluster/tcp.o: in function `o2net_start_connect': tcp.c:(.text+0x2633): undefined reference to `tcp_sock_set_nodelay' ld: tcp.c:(.text+0x2643): undefined reference to `tcp_sock_set_user_timeout' This is due to tcp_sock_set_nodelay() and tcp_sock_set_user_timeout() being declared in linux/tcp.h and defined in net/ipv4/tcp.c, which depend on TCP/IP being enabled. To fix this, make OCFS2_FS depend on INET=y which already requires NET=y. Fixes: 12abc5ee7873 ("tcp: add tcp_sock_set_nodelay") Fixes: c488aeadcbd0 ("tcp: add tcp_sock_set_user_timeout") Signed-off-by: Tom Seewald <tseewald@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Acked-by: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: David S. Miller <davem@davemloft.net> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Link: http://lkml.kernel.org/r/20200606190827.23954-1-tseewald@gmail.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-11mm/memory-failure: send SIGBUS(BUS_MCEERR_AR) only to current threadNaoya Horiguchi
Action Required memory error should happen only when a processor is about to access to a corrupted memory, so it's synchronous and only affects current process/thread. Recently commit 872e9a205c84 ("mm, memory_failure: don't send BUS_MCEERR_AO for action required error") fixed the issue that Action Required memory could unnecessarily send SIGBUS to the processes which share the error memory. But we still have another issue that we could send SIGBUS to a wrong thread. This is because collect_procs() and task_early_kill() fails to add the current process to "to-kill" list. So this patch is suggesting to fix it. With this fix, SIGBUS(BUS_MCEERR_AR) is never sent to non-current process/thread. Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Link: http://lkml.kernel.org/r/1591321039-22141-3-git-send-email-naoya.horiguchi@nec.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-11mm/memory-failure: prioritize prctl(PR_MCE_KILL) over ↵Naoya Horiguchi
vm.memory_failure_early_kill Patch series "hwpoison: fixes signaling on memory error" This is a small patchset to solve issues in memory error handler to send SIGBUS to proper process/thread as expected in configuration. Please see descriptions in individual patches for more details. This patch (of 2): Early-kill policy is controlled from two types of settings, one is per-process setting prctl(PR_MCE_KILL) and the other is system-wide setting vm.memory_failure_early_kill. Users expect per-process setting to override system-wide setting as many other settings do, but early-kill setting doesn't work as such. For example, if a system configures vm.memory_failure_early_kill to 1 (enabled), a process receives SIGBUS even if it's configured to explicitly disable PF_MCE_KILL by prctl(). That's not desirable for applications with their own policies. This patch is suggesting to change the priority of these two types of settings, by checking sysctl_memory_failure_early_kill only when a given process has the default kill policy. Note that this patch is solving a thread choice issue too. Originally, collect_procs() always chooses the main thread when vm.memory_failure_early_kill is 1, even if the process has a dedicated thread for memory error handling. SIGBUS should be sent to the dedicated thread if early-kill is enabled via vm.memory_failure_early_kill as we are doing for PR_MCE_KILL_EARLY processes. Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Link: http://lkml.kernel.org/r/1591321039-22141-1-git-send-email-naoya.horiguchi@nec.com Link: http://lkml.kernel.org/r/1591321039-22141-2-git-send-email-naoya.horiguchi@nec.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-06-11Merge tag 'io_uring-5.8-2020-06-11' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull io_uring fixes from Jens Axboe: "A few late stragglers in here. In particular: - Validate full range for provided buffers (Bijan) - Fix bad use of kfree() in buffer registration failure (Denis) - Don't allow close of ring itself, it's not fully safe. Making it fully safe would require making the system call more expensive, which isn't worth it. - Buffer selection fix - Regression fix for O_NONBLOCK retry - Make IORING_OP_ACCEPT honor O_NONBLOCK (Jiufei) - Restrict opcode handling for SQ/IOPOLL (Pavel) - io-wq work handling cleanups and improvements (Pavel, Xiaoguang) - IOPOLL race fix (Xiaoguang)" * tag 'io_uring-5.8-2020-06-11' of git://git.kernel.dk/linux-block: io_uring: fix io_kiocb.flags modification race in IOPOLL mode io_uring: check file O_NONBLOCK state for accept io_uring: avoid unnecessary io_wq_work copy for fast poll feature io_uring: avoid whole io_wq_work copy for requests completed inline io_uring: allow O_NONBLOCK async retry io_wq: add per-wq work handler instead of per work io_uring: don't arm a timeout through work.func io_uring: remove custom ->func handlers io_uring: don't derive close state from ->func io_uring: use kvfree() in io_sqe_buffer_register() io_uring: validate the full range of provided buffers for access io_uring: re-set iov base/len for buffer select retry io_uring: move send/recv IOPOLL check into prep io_uring: deduplicate io_openat{,2}_prep() io_uring: do build_open_how() only once io_uring: fix {SQ,IO}POLL with unsupported opcodes io_uring: disallow close of ring itself