summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-04-07arm64: dts: imx: Fix imx8*-var-som touchscreen property sizesRob Herring
The common touchscreen properties are all 32-bit, not 16-bit. These properties must not be too important as they are all ignored in case of an error reading them. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/Yk3moe6Hz8ELM0iS@robh.at.kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07arm: dts: imx: Fix boolean properties with valuesRob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter. It may have been intended that 0 values are false, but there is no change in behavior with this patch. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/Yk3mR5yae3gCkKhp@robh.at.kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07arm64: dts: tegra: Fix boolean properties with valuesRob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter. It may have been intended that 0 values are false, but there is no change in behavior with this patch. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/Yk3nShkFzNJaI3/Z@robh.at.kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07arm: dts: at91: Fix boolean properties with valuesRob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter. It may have been intended that 0 values are false, but there is no change in behavior with this patch. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/Yk3leykDEKGBN8rk@robh.at.kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07arm: configs: imote2: Drop defconfig as board support dropped.Jonathan Cameron
Missed the defconfig when removing the board files causing failures in builds using this defconfig. Fixes: 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards") Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220405135252.10283-1-Jonathan.Cameron@huawei.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07Merge tag 'memory-controller-drv-fixes-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/fixes Memory controller drivers - fixes for v5.18 Issues in v5.18: 1. Freescale/NXP: fix populating children of Integrated Flash Controller DT nodes. Issues existing before: 1. Renesas: fix platform-device leak in probe's error path. 2. Atmel: fix of_node reference leak in probe's error path. 3. Synopsys: correct the bindings for snps,ddrc-3.80a (interrupts are required). * tag 'memory-controller-drv-fixes-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: memory: fsl_ifc: populate child nodes of buses and mfd devices dt-bindings: memory: snps,ddrc-3.80a compatible also need interrupts memory: atmel-ebi: Fix missing of_node_put in atmel_ebi_probe memory: renesas-rpc-if: fix platform-device leak in error path Link: https://lore.kernel.org/r/20220407081448.113208-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07Merge tag 'samsung-fixes-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/fixes Samsung fixes for v5.18 Update Krzysztof Kozlowski's email address in multiple maintainer entries. The old one @canonical.com bounces already. * tag 'samsung-fixes-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: MAINTAINERS: update Krzysztof Kozlowski's email to Linaro dt-bindings: update Krzysztof Kozlowski's email Link: https://lore.kernel.org/r/20220407080545.112290-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07Merge tag 'vexpress-fixes-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes ARM Vexpress fixes for 5.18 Couple of fixes to address negative array index access and kernel-doc build warnings. * tag 'vexpress-fixes-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: ARM: vexpress/spc: Fix all the kernel-doc build warnings ARM: vexpress/spc: Fix kernel-doc build warning for ve_spc_cpu_in_wfi ARM: vexpress/spc: Avoid negative array index when !SMP Link: https://lore.kernel.org/r/20220407110828.1436206-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07Merge tag 'scmi-fixes-5.18' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI firmware interface fixes for v5.18 Few fixes to address assorted set of issues: - Erroneous clearing of Tx channel which only platform firmware must do - Invalid point access pass as parameter to sort() in clock support - Sparse build warnings in OPTEE transport driver - Use of deprecated zero-length arrays * tag 'scmi-fixes-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix sparse warnings in OPTEE transport driver firmware: arm_scmi: Replace zero-length array with flexible-array member firmware: arm_scmi: Fix sorting of retrieved clock rates firmware: arm_scmi: Remove clear channel call on the TX channel Link: https://lore.kernel.org/r/20220407110818.1436181-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07ep93xx: clock: Don't use plain integer as NULL pointerAlexander Sverdlin
Fix sparse warning: arch/arm/mach-ep93xx/clock.c:210:35: sparse: sparse: Using plain integer as NULL pointer Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/TLFJ6D7WGMDJSQ6XK7UZE4XR2PLRZJSV/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07ep93xx: clock: Fix UAF in ep93xx_clk_register_gate()Alexander Sverdlin
arch/arm/mach-ep93xx/clock.c:154:2: warning: Use of memory after it is freed [clang-analyzer-unix.Malloc] arch/arm/mach-ep93xx/clock.c:151:2: note: Taking true branch if (IS_ERR(clk)) ^ arch/arm/mach-ep93xx/clock.c:152:3: note: Memory is released kfree(psc); ^~~~~~~~~~ arch/arm/mach-ep93xx/clock.c:154:2: note: Use of memory after it is freed return &psc->hw; ^ ~~~~~~~~ Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Cc: stable@vger.kernel.org Link: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/B5YCO2NJEXINCYE26Y255LCVMO55BGWW/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-07mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is completeWolfram Sang
When HS400 tuning is complete and HS400 is going to be activated, we have to keep the current number of TAPs and should not overwrite them with a hardcoded value. This was probably a copy&paste mistake when upporting HS400 support from the BSP. Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-04-07s390/kexec: silence -Warray-bounds warningHeiko Carstens
Just use absolute_pointer() like e.g. in commit 545c272232ca ("alpha: Silence -Warray-bounds warnings") to get rid of this warning: arch/s390/kernel/machine_kexec.c:59:9: warning: ‘memcpy’ offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds] Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-04-07ARM: vexpress/spc: Fix all the kernel-doc build warningsSudeep Holla
There are more kernel-doc build warnings as below than the ones reported by kernel test robot recently for this file. | arch/arm/mach-vexpress/spc.c:125: warning: missing initial short description on line: | * ve_spc_global_wakeup_irq() | arch/arm/mach-vexpress/spc.c:131: warning: contents before sections | arch/arm/mach-vexpress/spc.c:148: warning: missing initial short description on line: | * ve_spc_cpu_wakeup_irq() | arch/arm/mach-vexpress/spc.c:154: warning: contents before sections | arch/arm/mach-vexpress/spc.c:203: warning: missing initial short description on line: | * ve_spc_powerdown() | arch/arm/mach-vexpress/spc.c:209: warning: contents before sections | arch/arm/mach-vexpress/spc.c:231: warning: missing initial short description on line: | * ve_spc_cpu_in_wfi() | 7 warnings Fix all these warnings. Link: https://lore.kernel.org/r/20220404130207.1162445-2-sudeep.holla@arm.com Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-04-07ARM: vexpress/spc: Fix kernel-doc build warning for ve_spc_cpu_in_wfiSudeep Holla
Kbuild bot reported the following kernel-doc build warning: | arch/arm/mach-versatile/spc.c:231: warning: This comment starts with | '/**', but isn't a kernel-doc comment. | Refer Documentation/doc-guide/kernel-doc.rst | * ve_spc_cpu_in_wfi(u32 cpu, u32 cluster) Fix the issue by dropping the parameters specified in the kernel doc. Link: https://lore.kernel.org/linux-doc/202204031026.4ogKxt89-lkp@intel.com Link: https://lore.kernel.org/r/20220404130207.1162445-1-sudeep.holla@arm.com Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-04-07x86/extable: Prefer local labels in .set directivesNick Desaulniers
Bernardo reported an error that Nathan bisected down to (x86_64) defconfig+LTO_CLANG_FULL+X86_PMEM_LEGACY. LTO vmlinux.o ld.lld: error: <instantiation>:1:13: redefinition of 'found' .set found, 0 ^ <inline asm>:29:1: while in macro instantiation extable_type_reg reg=%eax, type=(17 | ((0) << 16)) ^ This appears to be another LTO specific issue similar to what was folded into commit 4b5305decc84 ("x86/extable: Extend extable functionality"), where the `.set found, 0` in DEFINE_EXTABLE_TYPE_REG in arch/x86/include/asm/asm.h conflicts with the symbol for the static function `found` in arch/x86/kernel/pmem.c. Assembler .set directive declare symbols with global visibility, so the assembler may not rename such symbols in the event of a conflict. LTO could rename static functions if there was a conflict in C sources, but it cannot see into symbols defined in inline asm. The symbols are also retained in the symbol table, regardless of LTO. Give the symbols .L prefixes making them locally visible, so that they may be renamed for LTO to avoid conflicts, and to drop them from the symbol table regardless of LTO. Fixes: 4b5305decc84 ("x86/extable: Extend extable functionality") Reported-by: Bernardo Meurer Costa <beme@google.com> Debugged-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220329202148.2379697-1-ndesaulniers@google.com
2022-04-07x86,bpf: Avoid IBT objtool warningPeter Zijlstra
Clang can inline emit_indirect_jump() and then folds constants, which results in: | vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x6a4: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40 | vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x67d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40 | vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x386: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20 | vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x35d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20 Suppress the optimization such that it must emit a code reference to the __x86_indirect_thunk_array[] base. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Alexei Starovoitov <ast@kernel.org> Link: https://lkml.kernel.org/r/20220405075531.GB30877@worktop.programming.kicks-ass.net
2022-04-07ALSA: hda: intel-dsp-config: update AlderLake PCI IDsPierre-Louis Bossart
Add missing AlderLake-PS and RaptorLake-S PCI IDs (already in HDaudio and SOF drivers), add comments and regroup by skew. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220406190418.245044-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-04-07sound/oss/dmasound: fix build when drivers are mixed =y/=mRandy Dunlap
When CONFIG_DMASOUND_ATARI=m and CONFIG_DMASOUND_Q40=y (or vice versa), dmasound_core.o can be built without dmasound_deinit() being defined, causing a build error: ERROR: modpost: "dmasound_deinit" [sound/oss/dmasound/dmasound_atari.ko] undefined! Modify dmasound_core.c and dmasound.h so that dmasound_deinit() is always available. The mixed modes (=y/=m) also mean that several variables and structs have to be declared in all cases. Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202204032138.EFT9qGEd-lkp@intel.com Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20220405234118.24830-1-rdunlap@infradead.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-04-07ALSA: hda/realtek: Add quirk for Clevo PD50PNTTim Crawford
Fixes speaker output and headset detection on Clevo PD50PNT. Signed-off-by: Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220405182029.27431-1-tcrawford@system76.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-04-07selftests: KVM: Free the GIC FD when cleaning up in arch_timerOliver Upton
In order to correctly destroy a VM, all references to the VM must be freed. The arch_timer selftest creates a VGIC for the guest, which itself holds a reference to the VM. Close the GIC FD when cleaning up a VM. Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220406235615.1447180-4-oupton@google.com
2022-04-07selftests: KVM: Don't leak GIC FD across dirty log test iterationsOliver Upton
dirty_log_perf_test instantiates a VGICv3 for the guest (if supported by hardware) to reduce the overhead of guest exits. However, the test does not actually close the GIC fd when cleaning up the VM between test iterations, meaning that the VM is never actually destroyed in the kernel. While this is generally a bad idea, the bug was detected from the kernel spewing about duplicate debugfs entries as subsequent VMs happen to reuse the same FD even though the debugfs directory is still present. Abstract away the notion of setup/cleanup of the GIC FD from the test by creating arch-specific helpers for test setup/cleanup. Close the GIC FD on VM cleanup and do nothing for the other architectures. Fixes: c340f7899af6 ("KVM: selftests: Add vgic initialization for dirty log perf test for ARM") Reviewed-by: Jing Zhang <jingzhangos@google.com> Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220406235615.1447180-3-oupton@google.com
2022-04-07KVM: Don't create VM debugfs files outside of the VM directoryOliver Upton
Unfortunately, there is no guarantee that KVM was able to instantiate a debugfs directory for a particular VM. To that end, KVM shouldn't even attempt to create new debugfs files in this case. If the specified parent dentry is NULL, debugfs_create_file() will instantiate files at the root of debugfs. For arm64, it is possible to create the vgic-state file outside of a VM directory, the file is not cleaned up when a VM is destroyed. Nonetheless, the corresponding struct kvm is freed when the VM is destroyed. Nip the problem in the bud for all possible errant debugfs file creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, debugfs_create_file() will fail instead of creating the file in the root directory. Cc: stable@kernel.org Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions") Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220406235615.1447180-2-oupton@google.com
2022-04-07KVM: selftests: get-reg-list: Add KVM_REG_ARM_FW_REG(3)Andrew Jones
When testing a kernel with commit a5905d6af492 ("KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated") get-reg-list output vregs: Number blessed registers: 234 vregs: Number registers: 238 vregs: There are 1 new registers. Consider adding them to the blessed reg list with the following lines: KVM_REG_ARM_FW_REG(3), vregs: PASS ... That output inspired two changes: 1) add the new register to the blessed list and 2) explain why "Number registers" is actually four larger than "Number blessed registers" (on the system used for testing), even though only one register is being stated as new. The reason is that some registers are host dependent and they get filtered out when comparing with the blessed list. The system used for the test apparently had three filtered registers. Signed-off-by: Andrew Jones <drjones@redhat.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220316125129.392128-1-drjones@redhat.com
2022-04-06drivers: net: slip: fix NPD bug in sl_tx_timeout()Duoming Zhou
When a slip driver is detaching, the slip_close() will act to cleanup necessary resources and sl->tty is set to NULL in slip_close(). Meanwhile, the packet we transmit is blocked, sl_tx_timeout() will be called. Although slip_close() and sl_tx_timeout() use sl->lock to synchronize, we don`t judge whether sl->tty equals to NULL in sl_tx_timeout() and the null pointer dereference bug will happen. (Thread 1) | (Thread 2) | slip_close() | spin_lock_bh(&sl->lock) | ... ... | sl->tty = NULL //(1) sl_tx_timeout() | spin_unlock_bh(&sl->lock) spin_lock(&sl->lock); | ... | ... tty_chars_in_buffer(sl->tty)| if (tty->ops->..) //(2) | ... | synchronize_rcu() We set NULL to sl->tty in position (1) and dereference sl->tty in position (2). This patch adds check in sl_tx_timeout(). If sl->tty equals to NULL, sl_tx_timeout() will goto out. Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20220405132206.55291-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-06Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski
Alexei Starovoitov says: ==================== pull-request: bpf 2022-04-06 We've added 8 non-merge commits during the last 8 day(s) which contain a total of 9 files changed, 139 insertions(+), 36 deletions(-). The main changes are: 1) rethook related fixes, from Jiri and Masami. 2) Fix the case when tracing bpf prog is attached to struct_ops, from Martin. 3) Support dual-stack sockets in bpf_tcp_check_syncookie, from Maxim. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Adjust bpf_tcp_check_syncookie selftest to test dual-stack sockets bpf: Support dual-stack sockets in bpf_tcp_check_syncookie bpf: selftests: Test fentry tracing a struct_ops program bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT rethook: Fix to use WRITE_ONCE() for rethook:: Handler selftests/bpf: Fix warning comparing pointer to 0 bpf: Fix sparse warnings in kprobe_multi_resolve_syms bpftool: Explicit errno handling in skeletons ==================== Link: https://lore.kernel.org/r/20220407031245.73026-1-alexei.starovoitov@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-06scsi: megaraid_sas: Target with invalid LUN ID is deleted during scanChandrakanth patil
The megaraid_sas driver supports single LUN for RAID devices. That is LUN 0. All other LUNs are unsupported. When a device scan on a logical target with invalid LUN number is invoked through sysfs, that target ends up getting removed. Add LUN ID validation in the slave destroy function to avoid the target deletion. Link: https://lore.kernel.org/r/20220324094711.48833-1-chandrakanth.patil@broadcom.com Signed-off-by: Chandrakanth patil <chandrakanth.patil@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: ufs: ufshpb: Fix a NULL check on list iteratorXiaomeng Tong
The list iterator is always non-NULL so the check 'if (!rgn)' is always false and the dev_err() is never called. Move the check outside the loop and determine if 'victim_rgn' is NULL, to fix this bug. Link: https://lore.kernel.org/r/20220320150733.21824-1-xiam0nd.tong@gmail.com Fixes: 4b5f49079c52 ("scsi: ufs: ufshpb: L2P map management for HPB read") Reviewed-by: Daejun Park <daejun7.park@samsung.com> Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: sd: Clean up gendisk if device_add_disk() failedWenchao Hao
We forgot to call blk_cleanup_disk() when device_add_disk() failed. This would cause a memory leak of gendisk and sched_tags allocated in elevator_init_mq() Reference:https://syzkaller.appspot.com/x/log.txt?x=13b41dcb700000 Reported-and-tested-by: syzbot+f08c77040fa163a75a46@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20220401011018.1026553-1-haowenchao@huawei.com Signed-off-by: Wenchao Hao <haowenchao@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: message: fusion: Remove redundant variable dmpColin Ian King
Variable dmp is being assigned a value that is never read, the variable is redundant and can be removed. Cleans up clang scan build warning: drivers/message/fusion/mptbase.c:6667:39: warning: Although the value stored to 'dmp' is used in the enclosing expression, the value is never actually read from 'dmp' [deadcode.DeadStores] Link: https://lore.kernel.org/r/20220318003927.81471-1-colin.i.king@gmail.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: mvsas: Add PCI ID of RocketRaid 2640Alexey Galakhov
The HighPoint RocketRaid 2640 is a low-cost SAS controller based on Marvell chip. The chip in question was already supported by the kernel, just the PCI ID of this particular board was missing. Link: https://lore.kernel.org/r/20220309212535.402987-1-agalakhov@gmail.com Signed-off-by: Alexey Galakhov <agalakhov@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: sd: sd_read_cpr() requires VPD pagesMartin K. Petersen
As such it should be called inside the scsi_device_supports_vpd() conditional. Link: https://lore.kernel.org/r/20220302053559.32147-13-martin.petersen@oracle.com Fixes: e815d36548f0 ("scsi: sd: add concurrent positioning ranges support") Cc: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: mpt3sas: Fail reset operation if config request timed outSreekanth Reddy
As part of controller reset operation the driver issues a config request command. If this command gets times out, then fail the controller reset operation instead of retrying it. Link: https://lore.kernel.org/r/20220405120637.20528-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: sym53c500_cs: Stop using struct scsi_pointerFinn Thain
This driver doesn't use SCp.ptr to save a SCSI command data pointer which means "scsi pointer" is a complete misnomer here. Only a few members of struct scsi_pointer are needed so move those to private command data. Link: https://lore.kernel.org/r/accf71e293ba3aed6d18c8baeb405de8dfe7c935.1649235939.git.fthain@linux-m68k.org Cc: Bart Van Assche <bvanassche@acm.org> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: ufs: ufs-pci: Add support for Intel MTLAdrian Hunter
Add PCI ID and callbacks to support Intel Meteor Lake (MTL). Link: https://lore.kernel.org/r/20220404055038.2208051-1-adrian.hunter@intel.com Cc: stable@vger.kernel.org # v5.15+ Reviewed-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: mpt3sas: Fix mpt3sas_check_same_4gb_region() kdoc commentDamien Le Moal
The start_addres argument of mpt3sas_check_same_4gb_region() was misnamed in the function kdoc comment, resulting in the following warning when compiling with W=1. drivers/scsi/mpt3sas/mpt3sas_base.c:5728: warning: Function parameter or member 'start_address' not described in 'mpt3sas_check_same_4gb_region' drivers/scsi/mpt3sas/mpt3sas_base.c:5728: warning: Excess function parameter 'reply_pool_start_address' description in 'mpt3sas_check_same_4gb_region' Fix the argument name in the function kdoc comment to avoid it. While at it, remove a useless blank line between the kdoc and function code. Link: https://lore.kernel.org/r/20220404050041.594774-1-damien.lemoal@opensource.wdc.com Acked-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06scsi: scsi_debug: Fix sdebug_blk_mq_poll() in_use_bm bitmap useDamien Le Moal
The in_use_bm bitmap of struct sdebug_queue should be accessed under protection of the qc_lock spinlock. Make sure that this lock is taken before calling find_first_bit() at the beginning of the function sdebug_blk_mq_poll(). Link: https://lore.kernel.org/r/20220404045547.579887-1-damien.lemoal@opensource.wdc.com Fixes: 3fd07aecb750 ("scsi: scsi_debug: Fix qc_lock use in sdebug_blk_mq_poll()") Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-06Merge branch '5.18/scsi-queue' into 5.18/scsi-fixesMartin K. Petersen
Pull the remaining commits from 5.18/scsi-queue into fixes. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-04-07dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatoryMarek Vasut
Make the width-mm/height-mm panel properties mandatory to correctly report the panel dimensions to the OS. Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI compatible SPI panels") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dmitry Osipenko <digetx@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Acked-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220404192105.12547-1-marex@denx.de
2022-04-07Merge tag 'amd-drm-fixes-5.18-2022-04-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.18-2022-04-06: amdgpu: - VCN 3.0 fixes - DCN 3.1.5 fix - Misc display fixes - GC 10.3 golden register fix - Suspend fix - SMU 10 fix amdkfd: - Event fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220406170441.5779-1-alexander.deucher@amd.com
2022-04-07Merge tag 'imx-drm-fixes-2022-04-06' of git://git.pengutronix.de/pza/linux ↵Dave Airlie
into drm-fixes drm/imx: error handling and debug output fixes Catch an EDID allocation failure in imx-ldb, fix a leaked drm display mode on DT parsing error in parallel-display, properly remove the dw_hdmi bridge in case the component_add fails in dw_hdmi-imx, and fix the IPU clock frequency debug printout in ipu-di. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220406155101.1271845-1-p.zabel@pengutronix.de
2022-04-07Merge tag 'drm-misc-fixes-2022-03-24' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes * drm/panel/ili9341: Fix optional regulator handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YjwkvPp6UnePy4Q8@linux-uq9g.fritz.box
2022-04-07Merge tag 'amd-drm-next-5.18-2022-03-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-next-5.18-2022-03-25: amdgpu: - GFX 10.3.7 fixes - noretry updates - VCN fixes - TMDS fix - zstate fix for freesync video - DCN 3.1.5 fix - Display stack size fix - Audio fix - DCN 3.1 pstate fix - TMZ VCN fix - APU passthrough fix - Misc other fixes amdkfd: - Error handling fix - xgmi p2p fix - HWS VMIDs fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220325183602.5718-1-alexander.deucher@amd.com
2022-04-07random: check for signals every PAGE_SIZE chunk of /dev/[u]randomJason A. Donenfeld
In 1448769c9cdb ("random: check for signal_pending() outside of need_resched() check"), Jann pointed out that we previously were only checking the TIF_NOTIFY_SIGNAL and TIF_SIGPENDING flags if the process had TIF_NEED_RESCHED set, which meant in practice, super long reads to /dev/[u]random would delay signal handling by a long time. I tried this using the below program, and indeed I wasn't able to interrupt a /dev/urandom read until after several megabytes had been read. The bug he fixed has always been there, and so code that reads from /dev/urandom without checking the return value of read() has mostly worked for a long time, for most sizes, not just for <= 256. Maybe it makes sense to keep that code working. The reason it was so small prior, ignoring the fact that it didn't work anyway, was likely because /dev/random used to block, and that could happen for pretty large lengths of time while entropy was gathered. But now, it's just a chacha20 call, which is extremely fast and is just operating on pure data, without having to wait for some external event. In that sense, /dev/[u]random is a lot more like /dev/zero. Taking a page out of /dev/zero's read_zero() function, it always returns at least one chunk, and then checks for signals after each chunk. Chunk sizes there are of length PAGE_SIZE. Let's just copy the same thing for /dev/[u]random, and check for signals and cond_resched() for every PAGE_SIZE amount of data. This makes the behavior more consistent with expectations, and should mitigate the impact of Jann's fix for the age-old signal check bug. ---- test program ---- #include <unistd.h> #include <signal.h> #include <stdio.h> #include <sys/random.h> static unsigned char x[~0U]; static void handle(int) { } int main(int argc, char *argv[]) { pid_t pid = getpid(), child; signal(SIGUSR1, handle); if (!(child = fork())) { for (;;) kill(pid, SIGUSR1); } pause(); printf("interrupted after reading %zd bytes\n", getrandom(x, sizeof(x), 0)); kill(child, SIGTERM); return 0; } Cc: Jann Horn <jannh@google.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-04-07Revert "powerpc: Set max_mapnr correctly"Kefeng Wang
This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9. If CONFIG_HIGHMEM is enabled, no highmem will be added with max_mapnr set to max_low_pfn, see mem_init(): for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { ... free_highmem_page(); } Now that virt_addr_valid() has been fixed in the previous commit, we can revert the change to max_mapnr. Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reported-by: Erhard F. <erhard_f@mailbox.org> [mpe: Update change log to reflect series reordering] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220406145802.538416-2-mpe@ellerman.id.au
2022-04-07powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bitKefeng Wang
mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000. Because of the way __pa() works we have: __pa(0x8000000000000000) == 0, and therefore virt_to_pfn(0x8000000000000000) == 0, and therefore virt_addr_valid(0x8000000000000000) == true Which is wrong, virt_addr_valid() should be false for vmalloc space. In fact all vmalloc addresses that alias with a valid PFN will return true from virt_addr_valid(). That can cause bugs with hardened usercopy as described below by Kefeng Wang: When running ethtool eth0 on 64-bit Book3E, a BUG occurred: usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)! kernel BUG at mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (unreliable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 The code shows below, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true on 64-bit Book3E, which leads to the panic. As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in the virt_addr_valid() for 64-bit, also add upper limit check to make sure the virt is below high_memory. Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start of lowmem, high_memory is the upper low virtual address, the check is suitable for 32-bit, this will fix the issue mentioned in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly") too. On 32-bit there is a similar problem with high memory, that was fixed in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that commit breaks highmem and needs to be reverted. We can't easily fix __pa(), we have code that relies on its current behaviour. So for now add extra checks to virt_addr_valid(). For 64-bit Book3S the extra checks are not necessary, the combination of virt_to_pfn() and pfn_valid() should yield the correct result, but they are harmless. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Add additional change log detail] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220406145802.538416-1-mpe@ellerman.id.au
2022-04-06dt-bindings: gpu: mali-bifrost: Document RZ/V2L SoCLad Prabhakar
The Renesas RZ/V2L SoC (a.k.a R9A07G054) has a Bifrost Mali-G31 GPU, add a compatible string for it. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220308211543.3081-1-prabhakar.mahadev-lad.rj@bp.renesas.com
2022-04-06fbdev: Fix unregistering of framebuffers without deviceThomas Zimmermann
OF framebuffers do not have an underlying device in the Linux device hierarchy. Do a regular unregister call instead of hot unplugging such a non-existing device. Fixes a NULL dereference. An example error message on ppc64le is shown below. BUG: Kernel NULL pointer dereference on read at 0x00000060 Faulting instruction address: 0xc00000000080dfa4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365) MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000 GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0 NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"). Most firmware framebuffers have an underlying platform device, which can be hot-unplugged before loading the native graphics driver. OF framebuffers do not (yet) have that device. Fix the code by unregistering the framebuffer as before without a hot unplug. Tested with 5.17 on qemu ppc64le emulation. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: Zack Rusin <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org # v5.11+ Cc: Helge Deller <deller@gmx.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1] Link: https://patchwork.freedesktop.org/patch/msgid/20220404194402.29974-1-tzimmermann@suse.de
2022-04-06drbd: set QUEUE_FLAG_STABLE_WRITESChristoph Böhmwalder
We want our pages not to change while they are being written. Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-04-06drbd: fix an invalid memory access caused by incorrect use of list iteratorXiaomeng Tong
The bug is here: idr_remove(&connection->peer_devices, vnr); If the previous for_each_connection() don't exit early (no goto hit inside the loop), the iterator 'connection' after the loop will be a bogus pointer to an invalid structure object containing the HEAD (&resource->connections). As a result, the use of 'connection' above will lead to a invalid memory access (including a possible invalid free as idr_remove could call free_layer). The original intention should have been to remove all peer_devices, but the following lines have already done the work. So just remove this line and the unneeded label, to fix this bug. Cc: stable@vger.kernel.org Fixes: c06ece6ba6f1b ("drbd: Turn connection->volumes into connection->peer_devices") Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Reviewed-by: Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit (git 2.34.1) at 2025-09-13 04:02:20 +0000