The it66121_ctx structure has a gpio_reset field, and it66121_hw_reset()
calls gpiod_set_value() on it. However, the GPIO descriptor is never
acquired via devm_gpiod_get(), leaving gpio_reset as NULL throughout
the driver lifetime.
gpiod_set_value() silently returns when passed a NULL descriptor, so
the hardware reset sequence in it66121_hw_reset() is a no-op. This
leaves the chip in an undefined state at probe time, which can prevent
it from responding on the I2C bus.
The DT binding marks reset-gpios as a required property, so all
compliant device trees provide this GPIO. Add the missing
devm_gpiod_get() call after enabling power supplies and before the
hardware reset, so the chip is properly reset with power applied.
Fixes: 988156dc2f ("drm: bridge: add it66121 driver")
Cc: stable@vger.kernel.org
Signed-off-by: Julien Chauveau <chauveau.julien@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260324193011.16583-1-chauveau.julien@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
However, pfn_valid() only checks for availability of the memory map for
a PFN but it does not ensure that the PFN is actually backed by RAM. On
ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that
share a section with RAM will falsely trigger the WARN_ON_ONCE and cause
dma_map_resource() to return DMA_MAPPING_ERROR.
This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because
the SPI FIFO register (0xfe204004) falls in the same sparsemem section
as the end of RAM (0xf8000000-0xfbffffff), both in section 31
(0xf8000000-0xffffffff).
Move the sanity check from dma_map_resource() into debug_dma_map_phys()
and replace the unreliable pfn_valid() with pfn_valid() &&
!PageReserved(), which correctly identifies actual usable RAM without
false positives for MMIO regions that happen to have struct pages.
Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check
applies equally to both APIs. Any non-reserved page represents kernel
memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost
certainly wrong and risks breaking coherency on non-coherent platforms.
ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have
PageReserved set, so they will not trigger a false positive.
The check no longer blocks the mapping and uses err_printk() to
integrate with dma-debug filtering.
Fixes: f7326196a7 ("dma-mapping: export new dma_*map_phys() interface")
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260513072209.1486986-1-jianpeng.chang.cn@windriver.com
- tegra:
- drop runtime PM reference when exiting on mutex_lock failure
- preserve transfer errors when releasing the mutex
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQScDfrjQa34uOld1VLaeAVmJtMtbgUCagbyLwAKCRDaeAVmJtMt
bu7nAQCvlINIxjjP8xHbD1IEzI/DMZP2fEdvqUgEqNjRQwYCaQD+OOD3D63q/c93
t4pvPCAdueFWfK1+MWOYsXPKVkHglQE=
=IYx9
-----END PGP SIGNATURE-----
Merge tag 'i2c-host-fixes-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current
i2c-host-fixes for v7.1-rc4
- tegra:
- drop runtime PM reference when exiting on mutex_lock failure
- preserve transfer errors when releasing the mutex
The HP Z66 G6 14 inch laptop uses the ALC236 codec with subsystem ID
0x103c:8df7. Without a quirk entry, the PCI SSID falls back to the
generic 0x103c:0000 fixup, which does not configure the mute/micmute
LED GPIOs correctly.
Add the SND_PCI_QUIRK entry for this model using
ALC236_FIXUP_HP_GPIO_LED, matching the surrounding HP EliteBook G12
entries (0x8dec-0x8dfe) which share the same ALC236 codec and GPIO LED
layout.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Link: https://patch.msgid.link/20260518031542.2899188-1-houminxi@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The kvm_riscv_vcpu_mmio_return() function handles MMIO read results
by writing the data back to the guest register. For signed load
instructions (LB, LH, LW on RV64), the value needs sign-extension
from a smaller integer to unsigned long.
The current code uses:
(ulong)data << shift >> shift
but (ulong) makes the right shift a logical shift (zero-extend)
rather than an arithmetic shift (sign-extend), causing incorrect
results when the MMIO device returns a negative value. For example,
LB reading 0x80 would return 128 instead of -128.
Fix this by casting to (long) after the left shift so that the
subsequent right shift is arithmetic and correctly propagates
the sign bit:
(long)((ulong)data << shift) >> shift
Additionally, remove the unnecessary shift assignment for LBU
(unsigned byte load) since it does not need sign extension.
This makes LBU consistent with LHU and LWU which already keep
shift = 0.
Fixes: b91f0e4cb8 ("RISC-V: KVM: Factor-out instruction emulation into separate sources")
Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com>
Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
Assisted-by: OpenClaw:DeepSeek-V3.2
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260514081752.472987-1-xujiakai2025@iscas.ac.cn
Signed-off-by: Anup Patel <anup@brainfault.org>
The SBI v0.1 SEND_IPI handler iterates over the hart mask and calls
kvm_get_vcpu_by_id() to find the target vcpu for each set bit. When a
guest provides a hart mask containing bits for non-existent vcpu_ids,
kvm_get_vcpu_by_id() returns NULL, which is then unconditionally
dereferenced by kvm_riscv_vcpu_set_interrupt(), causing a kernel crash.
Fix this by adding a NULL check before dereferencing the return value.
If the target vcpu is not found, skip it and continue processing the
remaining valid harts.
Fixes: a046c2d857 ("RISC-V: KVM: Reorganize SBI code by moving SBI v0.1 to its own file")
Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com>
Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
Assisted-by: OpenClaw:DeepSeek-V3.2
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260517124414.420919-1-xujiakai2025@iscas.ac.cn
Signed-off-by: Anup Patel <anup@brainfault.org>
kvm_riscv_vcpu_pmu_event_info() returned -ENOMEM from the
SBI extension handler, which caused kvm_riscv_vcpu_sbi_ecall()
to abort KVM_RUN and surface the error to userspace instead of
completing the ECALL with a negative SBI error in a0.
Use SBI_ERR_FAILURE and the normal retdata path, matching other PMU
handlers and kvm_sbi_ext_pmu_handler comment.
Fixes: e309fd113b ("RISC-V: KVM: Implement get event info function")
Cc: stable@vger.kernel.org
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260514173642.41448-2-osama.abdelkader@gmail.com
Signed-off-by: Anup Patel <anup@brainfault.org>
kvm_riscv_vcpu_pmu_snapshot_set_shmem() returned -ENOMEM from the
SBI extension handler, which caused kvm_riscv_vcpu_sbi_ecall() to
abort KVM_RUN and surface the error to userspace instead of
ompleting the ECALL with a negative SBI error in a0.
Use SBI_ERR_FAILURE and the normal retdata path, matching other PMU
handlers and kvm_sbi_ext_pmu_handler comment.
Fixes: c2f41ddbcd ("RISC-V: KVM: Implement SBI PMU Snapshot feature")
Cc: stable@vger.kernel.org
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260514173642.41448-1-osama.abdelkader@gmail.com
Signed-off-by: Anup Patel <anup@brainfault.org>
kvm_riscv_vcpu_record_steal_time() assumes that the steal-time shared
memory GPA (vcpu->arch.sta.shmem) is always backed by a valid guest
memory slot. However, this assumption is not guaranteed by the KVM
userspace ABI.
A malicious or buggy userspace can set the STA shared memory GPA via
KVM_SET_ONE_REG without establishing a corresponding memory region via
KVM_SET_USER_MEMORY_REGION. In such cases, the GPA cannot be translated
to a valid HVA and kvm_vcpu_gfn_to_hva() returns an error address.
The current implementation incorrectly treats this as a kernel warning
using WARN_ON(), which may escalate to a kernel panic when panic_on_warn
is enabled.
This is not a kernel bug condition but a normal invalid configuration
from userspace, and should be handled gracefully.
Fix it by removing WARN_ON() and treating invalid HVA as a normal
failure case, resetting the STA shared memory state.
Fixes: e9f12b5fff ("RISC-V: KVM: Implement SBI STA extension")
Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com>
Assisted-by: OpenClaw:DeepSeek-V3.2
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260415075216.2757427-1-xujiakai2025@iscas.ac.cn
Signed-off-by: Anup Patel <anup@brainfault.org>
At transition to the iov_iter for PCM data transfer, we blindly
applied the iov_iter setup also for silencing (i.e. data = NULL), and
it leads to a calculation of bogus iov_iter. Fortunately this didn't
cause troubles on most of architectures but it goes wrong on RISC-V
now, causing a NULL dereference.
Handle the NULL data case to treat the silencing in interleaved_copy()
for addressing the bug above. noninterleaved_copy() has already the
NULL data handling, so it doesn't need changes.
Reported-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
Closes: https://lore.kernel.org/20260515051516.3103036-1-xujiakai24@mails.ucas.ac.cn
Fixes: cf393babb3 ("ALSA: pcm: Add copy ops with iov_iter")
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260517165121.31399-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HP Pavilion Plus 14-eh0xxx with subsystem ID 103c:8a36 needs the
ALC245 COEF bit mute LED quirk for the mute LED to follow the audio mute
state.
Add the missing quirk entry.
Signed-off-by: Aryan Kushwaha <aryankushwaha3101@gmail.com>
Link: https://patch.msgid.link/20260516144436.35022-1-aryankushwaha3101@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
scx_root_disable() enters SCX_DISABLING before it grabs scx_enable_mutex to
clear __scx_switched_all and scx_switching_all. task_should_scx() short-circuits on DISABLING,
so forks in that window land on fair while next_active_class() still skips
fair - the new tasks stall.
This can deadlock the disable path itself: scx_alloc_and_add_sched() runs
under scx_enable_mutex and creates a helper kthread; if that new kthread is
one of the stalled fair tasks, the mutex holder waits forever and
scx_root_disable() can never make progress. Only sub-sched support exposes
this, since sub-sched enables are the only path where
scx_alloc_and_add_sched() can race the root's disable.
Move the DISABLING check after @scx_switching_all. @scx_switching_all
serves as a proxy for __scx_switched_all, so while it's set, forks keep
going to scx. Once cleared, DISABLING applies normally.
v2: Reword in-source comment and description. (Andrea)
Fixes: 337ec00b1d ("sched_ext: Implement cgroup sub-sched enabling and disabling")
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
- Add more functions to the remote allowed list
randconfig found more functions that are allowed for the remote code for
s390 and arm. Add them to the allowed list.
- Fix remote_test error path
If one of the simple ring buffers fails to load, the code is supposed to
rollback its initialized buffers. Instead of rolling back the buffers for
the failed load, it uses the global variable and rolls back all the
successfully loaded buffers.
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCagm9FRQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qn0xAP0WSYmbUAGYnrq1o5L4EEM61ManFBfp
ta7dmx1Q5SYw6AEAtqbiH42VJZviAmajguyuL0cs9i9exFl+j4SaneejNwg=
=CLqK
-----END PGP SIGNATURE-----
Merge tag 'trace-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Add more functions to the remote allowed list
randconfig found more functions that are allowed for the remote code
for s390 and arm. Add them to the allowed list.
- Fix remote_test error path
If one of the simple ring buffers fails to load, the code is supposed
to rollback its initialized buffers. Instead of rolling back the
buffers for the failed load, it uses the global variable and rolls
back all the successfully loaded buffers.
* tag 'trace-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing: Fix desc in error path for the trace remote test module
ring-buffer remote: Avoid unexpected symbol warnings (arm, s390)
When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),
get_ext_report() allocates a buffer to retrieve a certificate blob from the
host, keeping track of its size in report_req->certs_len.
However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating
an invalid buffer size, as well as the expected length of such buffer.
get_ext_report() subsequently updates report_req->certs_len with the
host-controlled value, and cleans up the buffer by computing a page order
from such value. This is incorrect, as the host-provided length may not
match the page order of the original allocation, potentially resulting
in corruption in the page allocator.
Fix this by using alloc_pages_exact() instead, and reusing @npages to
compute the size passed to free_pages_exact(). For consistency, also
use @npages to compute the size when allocating the pages, even though
this last change has no functional effect.
Fixes: 3e385c0d6c ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex")
Signed-off-by: Carlos López <clopez@suse.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Michael Roth <michael.roth@amd.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Kumar Kartikeya Dwivedi says:
====================
Fix bpf_throw() vs global subprogs interaction
There is a bug where bpf_throw()'s reachability across global subprogs
is missed by the verifier, leading to successful verification when any
kernel resource or lock is held across global subprog call boundary.
Fix this by effect summarization like other related side effects and
propagate exception reachability into callees.
Changelog:
----------
v1 -> v2
v1: https://lore.kernel.org/bpf/20260516022426.2109698-1-memxor@gmail.com
* Reorder might_throw bit to avoid bpf-next conflicts. (Alexei)
====================
Link: https://patch.msgid.link/20260517075530.3461166-1-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Add a verifier failure case where the caller holds a reference across a
global subprog call that may throw. The program must be rejected because
the exceptional path would skip the caller's reference release.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260517075530.3461166-3-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Global subprogs are verified independently and are not descended into
when their callers are symbolically executed. This means a caller can
hold references or locks across a global subprog call that may throw,
while the verifier only checks the non-exceptional return path at the
call site.
Record whether a subprog might throw in the CFG summary pass, alongside
the existing might_sleep and packet-data-changing summaries, and
propagate that effect through reachable callees.
When a global subprog is marked as possibly throwing, push the normal
continuation and validate the exceptional path immediately at the call
site, avoiding a synthetic exception state and associated special case
in the pruning checks.
Fixes: f18b03faba ("bpf: Implement BPF exceptions")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20260517075530.3461166-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
- Fix use-after-free in irq_work_single() on PREEMPT_RT
(Jiayuan Chen)
- Don't call add_interrupt_randomness() for NMIs
in handle_percpu_devid_irq() (Mark Rutland)
- Remove unused function in the ath79-cpu irqchip driver
causing LKP CI build warnings (Rosen Penev)
- Fix IRQ allocation/teardown leakage regressions in the GICv5
irqchip driver (Sascha Bischoff)
- Fix an IRQ trigger type regression in the Meson S4 SoC irqchip
driver (Xianwei Zhao)
- Fix CPU offlining regression in the RiscV IMSIC irqchip driver
(Yong-Xuan Wang)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmoJXe4RHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1gyYBAAsylW1/wK/bu0QYhoqHTafWEnBvmgZOLL
pu6577JeLnKaE0jR5DAZRbANnQitE+zlKO2rgYRxpYRm3rUb0OAnQx3OKjdykkSv
1Lu0BQaIlfpVdDJMS+fq6GNHyHwWXMMT9kNwAr7Xc05E+GTMRbl5neFFjKH2vmw4
RDjaD3HykhnbtzFt26Nx3Qx80JBkqhV7hGuuPVwQP3QTRyi2y51inKPgwxZKrwfs
TaajXymHgsei+bCxbj75zWSs8xtkjSvgZetLSJIcjCCBw58IieIdF6i5MDIsqiGt
4v1c/u4+Q1Ip/OD41/dmHlsLMKsg0cNVa9WfatX53iWQIJY0sL8ayCGBLPCTDSe3
I615b6Im15thEozAlQ/BoSz5tFCtCHlrhx0sKqNRcFhVTa0Tlx0YNrb7SCmjHPw+
FSRM0lwlPM4xUPE4VPobV1Bqw5vR7kExeTK2Am2FMINOLwW1hUxilftJz45tMBbP
m+27d77Td3l6HGNO8E9rd4q20QR1t3cb+gOhx286UJEb1s13jSPzv/47vyRXCwb8
7IxD+IBazjeO2xM4PCZDfj4kszx28icaBeRrLVFkaV0TNvJ1F/acNgiOEfprYBIu
ISvLQy3Qel9SYpm99uUiBiv9gN0TNKvZJn3oR7sYigNQ+dOWZF5P7A7Kd+BqYmaS
Hop0rS2yFuA=
=rLcN
-----END PGP SIGNATURE-----
Merge tag 'irq-urgent-2026-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull IRQ fixes from Ingo Molnar:
- Fix use-after-free in irq_work_single() on PREEMPT_RT (Jiayuan Chen)
- Don't call add_interrupt_randomness() for NMIs in
handle_percpu_devid_irq() (Mark Rutland)
- Remove unused function in the ath79-cpu irqchip driver causing LKP
CI build warnings (Rosen Penev)
- Fix IRQ allocation/teardown leakage regressions in the GICv5 irqchip
driver (Sascha Bischoff)
- Fix an IRQ trigger type regression in the Meson S4 SoC irqchip driver
(Xianwei Zhao)
- Fix CPU offlining regression in the RiscV IMSIC irqchip driver
(Yong-Xuan Wang)
* tag 'irq-urgent-2026-05-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
irqchip/riscv-imsic: Clear interrupt move state during CPU offlining
irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type()
irqchip/ath79-cpu: Remove unused function
genirq/chip: Don't call add_interrupt_randomness() for NMIs
irqchip/gic-v5: Allocate ITS parent LPIs as a range
irqchip/gic-v5: Support range allocation for LPIs
irqchip/gic-v5: Move LPI allocation into the LPI domain
- Disable satp register probing when no5lvl is specified on the kernel
command line
- Fix a CFI-related issue with the misaligned access speed measurement
code
- Reduce the CFI shadow stack size limit from 4GB to 2GB (following
ARM64 GCS)
- Prevent the kernel from requesting delegation of misaligned access
faults unless a new Kconfig option,
CONFIG_RISCV_SBI_FWFT_DELEGATE_MISALIGNED, is enabled. This will
depend on CONFIG_NONPORTABLE until the deficiencies of the kernel
misaligned access fixup code are fixed
- Fix some potential uninitialized memory accesses in error paths in
compat_riscv_gpr_set() and compat_restore_sigcontext()
- Fix a bug in the RISC-V MIPS vendor errata patching code where a
logical-and was used in place of a bitwise-and
- Drop some unnecessary code in riscv_fill_hwcap_from_isa_string()
- Use macros for isa2hwcap indices in riscv_fill_hwcap(), rather than
open-coding them
- Fix some documentation typos (one affecting "make htmldocs")
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAmoI9x4ACgkQx4+xDQu9
Kks8xhAApjbsnXnN7lKkLR9h65zMH6698QmbfeP8DPiwjoiVrhEPEnLwJavr7XcF
riLPAR0gpc2WkExLHL5xa4H9pUfihDm2KRmoTdJi7bQQbYEGXeJ1cXWDMRW5OcxE
aN4kVMnRpiYlh46IO6uyWToZCV0OJs2EqQvzP0qGdRqQRxfObkd+zeSDTCsmV6SR
d4SUc10T3Ov2e04ClgPMRivrvrL7E8hSswAoSExVHwNj6izud2+1Ck0j2s5K//8d
QWuKgNVlIhcQF0xIbiGjKx8Ihb2C3BcO+3eca4iBjygkBofEbrLHi5lvFlHbq0y4
UiawmiKMZ61h/Hk+HNRxD/6OVRSj28P1LOgQQ0bLz58tVT+nay46PWf+GAt9iR9z
SxgCuRgaEgmooBh6/pD6T6EQvnLYF0v4ZBfX6KRhzxyru+zf+onubBNXdkyyuSrA
b0DrkSaaRwZrgUFH8fyQZ9BSi7DEd12lw3W7ZfNfz9dnfEflzSv0CxQQ2069OBkE
MyZBKVVOtRKQwHKQdzmtvjOnjXqMgjldbPCj21wV17ARgzg4zmL+FZshHfhP6MbN
BjeyGcpFrqVExDQtWQxSmytq4Oo6jhNiA0u20C7bA0q8xrL/cxyJxDFHdZIAal5K
XlOj+FJI/oREe9YgleQ0d8YMtPA8JfjRYxaBWlyol7eyMxIj8w4=
=yOtI
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"Relatively low-impact fixes. Probably the most notable one is that we
no longer ask the monitor-mode firmware to delegate misaligned access
handling to the kernel by default, since the kernel code needs
significant improvement to match the functionality of the firmware.
This change avoids functional problems at some cost in performance,
but shouldn't affect any system with misaligned access handling in
hardware.
- Disable satp register probing when no5lvl is specified on the
kernel command line
- Fix a CFI-related issue with the misaligned access speed
measurement code
- Reduce the CFI shadow stack size limit from 4GB to 2GB (following
ARM64 GCS)
- Prevent the kernel from requesting delegation of misaligned access
faults unless a new Kconfig option, RISCV_SBI_FWFT_DELEGATE_MISALIGNED,
is enabled. This will depend on CONFIG_NONPORTABLE until the
deficiencies of the kernel misaligned access fixup code are fixed
- Fix some potential uninitialized memory accesses in error paths in
compat_riscv_gpr_set() and compat_restore_sigcontext()
- Fix a bug in the RISC-V MIPS vendor errata patching code where a
logical-and was used in place of a bitwise-and
- Drop some unnecessary code in riscv_fill_hwcap_from_isa_string()
- Use macros for isa2hwcap indices in riscv_fill_hwcap(), rather than
open-coding them
- Fix some documentation typos (one affecting 'make htmldocs')"
* tag 'riscv-for-linus-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: misaligned: Make enabling delegation depend on NONPORTABLE
riscv: Docs: fix unmatched quote warning
riscv: cfi: reduce shadow stack size limit from 4GB to 2GB
riscv: cpufeature: Use pre-defined ISA ext macros to index isa2hwcap
riscv: mm: Fixup no5lvl failure when vaddr is invalid
riscv: Fix register corruption from uninitialized cregs on error
riscv: errata: Fix bitwise vs logical AND in MIPS errata patching
Documentation: riscv: cmodx: fix typos
riscv: cpufeature: Drop this_hwcap clear in T-Head vector workaround
riscv: Define __riscv_copy_{,vec_}{words,bytes}_unaligned() using SYM_TYPED_FUNC_START
Fix the typo "clocks-names" to "clock-names" in the allOf/if conditional
blocks.
Fixes: 9be5c47908 ("dt-bindings: display/msm: expand to support MST")
Fixes: 7403e87c13 ("dt-bindings: display: msm: Fix reg ranges and clocks on Glymur")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/721682/
Message-ID: <20260428100338.3179722-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The PANEL_BOOT_MESSAGE dependency uses a quoted-string comparison
against the PANEL_CHANGE_MESSAGE bool symbol:
depends on PANEL_CHANGE_MESSAGE="y"
This is the only such pattern under drivers/auxdisplay/ (grep shows
no other Kconfig file in the tree uses depends on FOO="y" with
quotes for a plain bool symbol). The quoted form is parsed by
Kconfig but is not idiomatic; the common form for the same intent
is the unquoted tristate-style dependency:
depends on PANEL_CHANGE_MESSAGE
which evaluates true when PANEL_CHANGE_MESSAGE is y or m. Since
PANEL_CHANGE_MESSAGE is declared as bool (not tristate), there is
no behaviour change in practice: y is the only enabled value
either form can match.
Drop the quoted comparison so the dependency matches the prevailing
kernel Kconfig style and so it is obvious to readers that the
comparison works.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/CAHp75VfsA_LsbEKjxoeMdbhPbWj7OHZ7=0SYNA3c=ZLj_M94Bw@mail.gmail.com
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
linedisp_display() unconditionally reads msg[count - 1] before
checking whether count is zero, so a write of zero bytes to the
message sysfs attribute hits msg[-1]:
write(fd, "", 0);
-> message_store(..., buf, count=0)
-> linedisp_display(linedisp, buf, count=0)
-> msg[count - 1] == '\n' ; OOB read
The kernfs write buffer for that store is a 1-byte allocation
(kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),
so msg[-1] is a 1-byte read before the slab object. On a
KASAN-enabled kernel this trips an out-of-bounds report and
panics; on stock kernels it silently reads adjacent slab data
and, if that byte happens to be '\n', the following count--
wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().
linedisp_display() is reached from the message_store() sysfs
callback (drivers/auxdisplay/line-display.c message attribute,
mode 0644) and from the in-tree initial-message setup with
count == -1, so the OOB path is only userspace-triggerable via
zero-byte writes; vfs_write() does not short-circuit on
count == 0 and kernfs_fop_write_iter() dispatches the store
callback regardless.
Guard the trailing-newline trim with a count check. The
existing if (!count) block then takes the clear-display path
unchanged.
Affects every auxdisplay driver that registers via
linedisp_register() / linedisp_attach(): ht16k33, max6959,
img-ascii-lcd, seg-led-gpio.
Fixes: 7e76aece6f ("auxdisplay: Extract character line display core support")
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
After 4 missed beacons since last Rx, the firmware will send an NDP to the
AP. If the NDP is ACK'ed, it'll reset the missed_beacons_since_last_rx
counter.
Disconnecting after 4 beacons doesn't give enough time to the firmware
to send the NDP.
Wait until we get 6 missed beacons since last Rx before disconnecting.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20260515151352.c4ed0d849f98.Iefa2e8be9edfc74683997eea60bb53c2002f31f0@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Clearly, from a user perspective, it must be valid to configure
WoWLAN (which can include network detection) and then suspend
while not connected to a network, or even without an interface
at all (WoWLAN config is handled on a per-wiphy basis). Since
mac80211 doesn't distinguish these cases and simply calls the
driver to suspend whenever WoWLAN is configured, the driver has
to cleanly handle the case where it's called for WoWLAN but no
(BSS) interface exists.
Remove the WARN_ON(), move the print so it doesn't get done in
this case, and keep returning 1 to disconnect everything.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151352.0c55d1135409.I54f8be0e2aa28cfb1cb1dcf3b2d2d8fe75b4397b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
CNVI_PMU_STEP_FLOW is a PRPH register, not a UMAC PRPH register.
Use iwl_read_prph() instead of iwl_read_umac_prph() to read it
correctly.
Signed-off-by: Moriya Itzchaki <moriya.itzchaki@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151352.3a69fa2dbda7.I8d96635a9c06a835b05a10b6d66c8a9299676246@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
On old devices such as 7265D, rates are still encoded in version 1
format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but
rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.)
While introducing v3 rates, I changed the driver from internally
handling v1 rates and converting to v2, to internally handling v3
and converting to v1 or v2 according to the firmware. I accordingly
changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer
have different values for different APIs. This was correct.
However, I later reverted this part of the change, because it was
reported that I had broken beacon rates, causing a FW assert/crash.
This caused TX_CMD rates to be set incorrectly, potentially causing
a warning when reported back from the device as having been used.
Fix this (hopefully correctly now) by handling beacon rates in the
TX_CMD that's embedded in the beacon template command separately.
Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate
index, not PLCP value, fixing the real TX_CMD.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151351.7407e293dff7.I4ea1a17f8fe99c933d3f3e30d077cf4246125c3e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the
function so we have it after we freed the link.
But the link pointer can be NULL, and is not checked when the fw_id is
stored.
Fix it by simply freeing the link at the end of the function.
fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515151351.371f40fc6711.I6a82cfe9655564e9c5731af91c36493b26b1208e@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel
BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart
to true. However, iwl_mld_tx_from_txq() does not check this flag before
dequeuing frames from mac80211 and pushing them to the transport layer.
Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame,
which then gets freed immediately. Under high-throughput conditions
(e.g., Tailscale UDP traffic or active SSH sessions), this creates a
tight dequeue-send-fail-free loop that wastes CPU cycles and generates
rapid skb allocation churn, leading to memory pressure from slab
fragmentation.
The RX path already has this guard (iwl_mld_rx_mpdu checks
in_hw_restart at rx.c:1906), and so does the TXQ allocation worker
(iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to
iwl_mld_tx_from_txq() to stop all TX during firmware restart.
Frames left in mac80211's TXQs are naturally drained after restart
completes, when queue reallocation triggers iwl_mld_tx_from_txq()
via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes
wake_tx_queue.
Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on
kernel 6.19.5 where the firmware crashes approximately every 10-15
minutes under Tailscale traffic.
Fixes: d1e879ec60 ("wifi: iwlwifi: add iwlmld sub-driver")
Cc: stable@vger.kernel.org
Signed-off-by: Sheroz Juraev <goodmartiandev@gmail.com>
Link: https://patch.msgid.link/20260315081221.2678478-1-goodmartiandev@gmail.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When the TLC notification disables AMSDU for a TID, the MLD driver sets
max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in
iwl_mld_tx_tso_segment() checks for zero but not for this sentinel,
allowing it to reach the num_subframes calculation:
num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad)
= (1 + 2) / (1534 + 2) = 0
This zero propagates to iwl_tx_tso_segment() which sets:
gso_size = num_subframes * mss = 0
Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny
segments from a single GSO skb. This floods the TX ring with ~1024
micro-frames (the rest are purged), creating a massive burst of TX
completion events that can lead to memory corruption and a subsequent
use-after-free in TCP's retransmit queue (refcount underflow in
tcp_shifted_skb, NULL deref in tcp_rack_detect_loss).
The MVM driver is immune because it checks mvmsta->amsdu_enabled before
reaching the num_subframes calculation. The MLD driver has no equivalent
bitmap check and relies solely on max_tid_amsdu_len, which does not
catch the sentinel value.
Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the
existing check and falling back to non-AMSDU TSO segmentation. Also add
a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth
to catch any future code paths that produce zero through a different
mechanism.
Suggested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Fixes: d1e879ec60 ("wifi: iwlwifi: add iwlmld sub-driver")
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
Link: https://patch.msgid.link/20260405054145.1064152-3-cole@unwrap.rs
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The kernel-doc comment for batadv_skb_is_frag() contained two errors:
* the function description referred to "gain a unicast packet" instead
of "contains unicast fragment".
* the Return section omitted "merged" from "newly skb", leaving the
description grammatically incorrect and inconsistent with the
function description.
Fixes: bc62216dc8 ("batman-adv: frag: disallow unicast fragment in fragment")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
During initialisation in remote_test_load(), if one of the
simple_ring_buffer fails to initialise, the error path attempts to
rollback initialised buffers. However, the rollback incorrectly uses the
global pointer to the trace descriptor, which is only set upon
successful load completion. Fix the error path by using the local
pointer to the descriptor.
Link: https://patch.msgid.link/20260515201616.337469-1-vdonnefort@google.com
Fixes: ea908a2b79 ("tracing: Add a trace remote module for testing")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
base-commit: 5d6919055d
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
IORING_OP_WAITID stores its result fields in struct io_waitid::info and
later copies them to userspace siginfo. The prep path initializes the
request arguments, but it does not initialize info itself.
If the wait operation completes without reporting a child event, the common
wait code can return without writing wo_info. In that case io_waitid_finish()
still copies iw->info to userspace, exposing stale bytes from the reused
io_kiocb command storage.
Clear the result storage during prep so the io_uring path matches the
regular waitid syscall, which uses a zero-initialized struct waitid_info.
Fixes: f31ecf671d ("io_uring: add IORING_OP_WAITID support")
Cc: stable@vger.kernel.org # 6.7+
Signed-off-by: Heechan Kang <gganji11@naver.com>
Link: https://patch.msgid.link/20260516184709.852814-1-gganji11@naver.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The GMAC node incorrectly listed four clocks, including a separate tx_clk
and a TSU GCK clock sourced from ID 67. According to the SAM9X7 clocking
scheme, the GMAC uses only three clocks: HCLK, PCLK, and the TSU GCK
derived from the GMAC peripheral clock (ID 24).
Remove the unused tx_clk, update the clock-names accordingly, and correct
the assigned clock to use GCK 24 instead of GCK 67. This aligns the device
tree with the actual hardware clock topology and prevents misconfiguration
of the GMAC clock tree.
[root@SAM9X75 ~]$ cat /sys/kernel/debug/clk/clk_summary | grep gmac
gmac_gclk 1 1 1 266666666 0 0 50000 Y f802c000.ethernet tsu_clk
f802c000.ethernet tsu_clk
gmac_clk 2 2 0 266666666 0 0 50000 Y f802c000.ethernet hclk
f802c000.ethernet pclk
Fixes: 41af45af8b ("ARM: dts: at91: sam9x7: add device tree for SoC")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Link: https://lore.kernel.org/r/20260309075329.1528-5-mihai.sain@microchip.com
[claudiu.beznea: massaged the patch description]
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Sashiko reports:
lm90_alert() executes in the smbus alert context and calls
lm90_update_confreg() to disable the hardware alert line, without
acquiring hwmon_lock.
Concurrently, sysfs write operations (such as lm90_write_convrate) hold
the hwmon_lock, temporarily modify data->config, and then restore it.
If an alert interrupt occurs concurrently with a sysfs write, the sysfs
path will overwrite the alert handler's modifications to data->config
and the hardware register.
This unintentionally re-enables the hardware alert line while the alarm is
still active, causing an interrupt storm.
Add the missing lock to lm90_alert() to solve the problem.
Fixes: 7a1d220ccb ("hwmon: (lm90) Introduce function to update configuration register")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Sashiko reports:
In lm90_probe(), the devm action to cancel the alert_work and report_work
(lm90_restore_conf) is registered in lm90_init_client() before
devm_hwmon_device_register_with_info() is called.
Because devm executes cleanup actions in reverse order during module
unbind or probe failure, the hwmon device is unregistered and freed first.
If lm90_alert_work() or lm90_report_alarms() runs in the window between
the hwmon device being freed and the delayed works being cancelled,
lm90_update_alarms() will dereference the freed data->hwmon_dev here.
Fix the problem by canceling the workers separately after registering
the hwmon device and before registering the interrupt handler. This ensures
that the workers are canceled after interrupts are disabled and before
the hwmon device is released. Add "shutdown" flag to indicate that device
shutdown is in progress to prevent workers from being re-armed.
Fixes: f6d0775119 ("hwmon: (lm90) Rework alarm/status handling")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Mirror of Mark Brown's ASoC: hdac_hdmi rate-limit patch (commit
[lkml.kernel.org/lkml/2025/6/13/1380]) for the generic snd_parse_eld()
helper used by ASoC hdmi-codec.
When a HDMI sink is disconnected (e.g. a board with two HDMI outputs and
only one cable), userspace audio servers like PipeWire keep probing the
disconnected card and trigger:
HDMI: Unknown ELD version 0
at every probe — easily 30+ messages per burst on rk3588. The same
applies to malformed ELD (MNL out of range). Both conditions are
expected when no sink is attached; rate-limit the dev_info() so the
kernel ring buffer does not fill up.
Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
Link: https://patch.msgid.link/20260516141244.21801-1-pavone.lawyer@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The snapshotting code internally aligns data segment to 16 bytes. This
works fine for DPU code (where most of the regions are aligned), but
fails for snapshotting of the DSI data (because DSI data region is
shifted by 4 bytes). Fix the code by removing length alignment and by
accurately printing last registers in the region. While reworking the
code also fix the 16x memory overallocation in
msm_disp_state_dump_regs().
Fixes: 98659487b8 ("drm/msm: add support to take dpu snapshot")
Reported-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/725449/
Message-ID: <20260516-msm-fix-dsi-dump-2-v2-1-9e49fb2d240e@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Heiko reported that BIOS on some recent machines doesn't set up PCI
SSID properly but leave with zero (e.g. on HP Dragonfly Folio 13.5
inch G3 with SSID 103c:8a05/8a06), which confuses the quirk table
matching and results in the non-functional state.
Fix it by skipping the PCI SSID matching when either vendor or device
ID is zero and falling back to the codec SSID that is supposed to be
more stable for those cases.
Reported-by: Heiko Schmid <heiko@future-machines.org>
Tested-by: Heiko Schmid <heiko@future-machines.org>
Closes: https://lore.kernel.org/20260514133110.12302-1-heiko@future-machines.org
Link: https://patch.msgid.link/20260515105700.276420-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HP 250 15.6 inch G10 Notebook PC uses the same ALC236 codec
as the HP 255 15.6 inch G10 (103c:8b2f) and requires the same
fixup to enable the internal speaker EAPD and microphone routing.
Signed-off-by: Sergio Boglione <sboglione@gmail.com>
Link: https://patch.msgid.link/20260516131651.143109-1-sboglione@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These devices were incorrectly using the ALC287_FIXUP_TAS2781_I2C quirk
leading to errors:
[ 18.765990] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found
[ 18.768153] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found
[ 18.768476] Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found
[ 18.768899] Serial bus multi instantiate pseudo device driver TXNW2781:00: Instantiated 3 I2C devices.
Use the ALC287_FIXUP_TXNW2781_I2C quirk instead to fix this and restore
speaker audio on affected devices.
Fixes: 1e9c708dc3 ("ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects")
Link: https://lore.kernel.org/59fd4aa4-76b9-4984-8db9-a60e55ec6e80@losource.net/
Closes: https://lore.kernel.org/CACB9z7kjs8rhLstEc8fV29BCTb5dd881JwGozoKdO5cwCb=YwQ@mail.gmail.com
Signed-off-by: Eric Naim <dnaim@cachyos.org>
Link: https://patch.msgid.link/20260516111532.111463-1-dnaim@cachyos.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
