dt-bindings: i2c: realtek,rtl9301-i2c: extend for clocks and RTL9607C support
Add the "realtek,rtl9607-i2c" compatible for i2c controller on the
RTL9607C SoC series.
Add a clocks property to the properties to describe the i2c reference
clock and make it available for all the compatibles. This i2c reference
clock is assumed to be coming from switchcore region via Lexra bus as
the other SoC peripherals.
According to the info available about the existing devices, they also
have the i2c master controller clocks.
RTL9607C requires the "realtek,scl" and "clocks" to be specified
and so handle it under separate if check for "realtek,rtl9607-i2c".
i2c: rtl9300: introduce a property for 8 bit width reg address
In RTL9607C i2c controller, in order to indicate that the width of
memory address is 8 bits, 0 is written to MEM_ADDR_WIDTH field as
opposed to 1 for RTL9300 and RTL9310.
Introduce a new property to a driver data to indicate what value
need to written to MEM_ADDR_WIDTH field for this case.
i2c: rtl9300: introduce F_BUSY to the reg_fields struct
In RTL9607C i2c controller the busy check operation is done on the
separate bit of the command register as opposed to self clearing
command trigger bit on the rtl9300 and rtl9310 i2c controllers.
Introduce a new F_BUSY field to the reg_fields struct for that
and change the regmap read poll function to use F_BUSY
instead of I2C_TRIG.
i2c: rtl9300: introduce max length property to driver data
In RTL9607C i2c controller, theoretical maximum the data length
can be is 4 bytes as opposed to 16 bytes on rtl9300 and rtl9310.
Introduce a new property to the driver data struct for that.
Adjust if statement in prepare_xfer function to follow that new
property instead of the hardcoded value.
Merge tag 'renesas-arm-soc-for-v7.1-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/arm
Renesas ARM SoC updates for v7.1
- Use the of_phandle_args_equal() helper.
* tag 'renesas-arm-soc-for-v7.1-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
ARM: shmobile: rcar-gen2: Use of_phandle_args_equal() helper
Merge tag 'imx-soc-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/drivers
i.MX SoC update for 7.1:
- Updates MAINTAINERS file to include i.MX team coverage for ARM NXP platforms
- Sets default values for OPACR (Off-Platform Peripheral Access Control
Register) in the i.MX AIPSTZ bus driver
* tag 'imx-soc-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
MAINTAINERS: Add i.MX team to all arm NXP platforms
bus: imx-aipstz: set default value for opacr registers
Jan Kantert [Fri, 27 Feb 2026 11:11:34 +0000 (12:11 +0100)]
i2c: rtl9300: add support for 50 kHz and 2.5 MHz bus speeds
Some SFP modules on certain switches (for example the ONTi ONT-S508CL-8S and
XikeStor SKS8300-8X) exhibit unreliable I2C communication at the currently
supported speeds. Add support for 50 kHz and 2.5 MHz I2C bus modes on the
RTL9300 to improve compatibility with these devices.
Merge tag 'renesas-drivers-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers
Renesas driver updates for v7.1 (take two)
- Mark remaining rz_sysc_init_data structures __initconst.
* tag 'renesas-drivers-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: r9a09g056-sys: Mark rzv2n_sys_init_data as __initconst
soc: renesas: r9a09g047-sys: Mark rzg3e_sys_init_data as __initconst
soc: renesas: r9a09g057-sys: Mark rzv2h_sys_init_data as __initconst
Julian Ruess [Wed, 25 Mar 2026 13:31:24 +0000 (14:31 +0100)]
vfio/ism: Implement vfio_pci driver for ISM devices
Add a vfio_pci variant driver for the s390-specific Internal Shared
Memory (ISM) devices used for inter-VM communication.
This enables the development of vfio-pci-based user space drivers for
ISM devices.
On s390, kernel primitives such as ioread() and iowrite() are switched
over from function-handle-based PCI load/stores instructions to PCI
memory-I/O (MIO) loads/stores when these are available and not
explicitly disabled. Since these instructions cannot be used with ISM
devices, ensure that classic function-handle-based PCI instructions are
used instead.
The driver is still required even when MIO instructions are disabled, as
the ISM device relies on the PCI store block (PCISTB) instruction to
perform write operations.
Stores are not fragmented, therefore one ioctl corresponds to exactly
one PCISTB instruction. User space must ensure to not write more than
4096 bytes at once to an ISM BAR which is the maximum payload of the
PCISTB instruction.
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Julian Ruess <julianr@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260325-vfio_pci_ism-v8-2-ddc504cde914@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Let's modify the awk script to add the values for each line and print
the total. The variable 'i' has a number of input lines that have valid
output and variable 'c' has the sum of actual counter values. That way
it should work on any platforms.
Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Ian Rogers [Tue, 31 Mar 2026 18:05:20 +0000 (11:05 -0700)]
perf tests: Write test files to tmpdir
Writing to the test output files in the current working directory can
fail in various contexts such as continual test. Other tests write to
a mktemp-ed file, make the "perf script task-analyszer tests" follow
this convention too. Currently this isn't possible for the perf.data
file due to a lack of perf script support, add a variable for when
this support is available.
Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Ian Rogers [Tue, 31 Mar 2026 18:29:48 +0000 (11:29 -0700)]
libperf cpumap: Make index and nr types unsigned
The index into the cpumap array and the number of entries within the
array can never be negative, so let's make them unsigned. This is
prompted by reports that gcc 13 with -O6 is giving a
alloc-size-larger-than errors. The change makes the cpumap changes and
then updates the declaration of index variables throughout perf and
libperf to be unsigned. The two things are hard to separate as
compiler warnings about mixing signed and unsigned types breaks the
build.
Reported-by: Chingbin Li <liqb365@163.com> Closes: https://lore.kernel.org/lkml/20260212025127.841090-1-liqb365@163.com/ Tested-by: Chingbin Li <liqb365@163.com> Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Merge tag 'stm32-bus-firewall-for-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/drivers
STM32 Firewall bus for v7.1, round 1
Highlights:
----------
Stm32 SoCs embed debug peripherals such as Coresight. These peripherals
can monitor the activity of the cores. Because of that, they can be
used only if some features in the debug configuration are enabled.
Else, errors or firewall exceptions can be observed. Similarly to
the ETZPC(on stm32mp1x platforms) or the RIFSC(on stm32mp2x platforms),
debug-related peripherals access can be assessed at bus level to
prevent these issues from happening.
The debug configuration can only be accessed by the secure world.
That means that a service must be implemented in the secure world for
the kernel to check the firewall configuration. On OpenSTLinux, it is
done through a Debug access PTA in OP-TEE [1].
To represent the debug peripherals present on a dedicated debug bus,
create a debug bus node in the device tree and the associated driver
that will interact with this PTA.
Plus some fixes.
* tag 'stm32-bus-firewall-for-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32:
pinctrl: stm32: add firewall checks before probing the HDP driver
drivers: bus: add the stm32 debug bus driver
bus: stm32_firewall: add stm32_firewall_get_grant_all_access() API
bus: stm32_firewall: allow check on different firewall controllers
dt-bindings: bus: document the stm32 debug bus
dt-bindings: pinctrl: document access-controllers property for stm32 HDP
dt-bindings: document access-controllers property for coresight peripherals
bus: rifsc: fix RIF configuration check for peripherals
bus: rifsc: Replace snprintf("%s") with strscpy
bus: stm32_firewall: Simplify with scoped for each OF child loop
bus: firewall: move stm32_firewall header file in include folder
Merge tag 'scmi-updates-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v7.1
This batch mainly improves SCMI robustness on systems where the SCP does
not generate completion interrupts, and includes two small follow-up
cleanups in the SCMI core.
The main functional change adds support for the new DT property
'arm,no-completion-irq'. When present for mailbox/shared-memory based
SCMI implementations, the driver forces SCMI operations into polling
mode so affected platforms can continue to operate even with broken
firmware interrupt behavior.
In addition, it
- replaces open-coded size rounding in the base protocol path with
round_up() for clarity, with no functional change
- updates the SCMI quirk snippet macro implementation so quirk handlers
can use break and continue directly when invoked inside loop contexts
* tag 'scmi-updates-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Support loop control in quirk code snippets
firmware: arm_scmi: Use round_up() for base protocol list size calculation
firmware: arm_scmi: Implement arm,no-completion-irq property
dt-bindings: firmware: arm,scmi: Document arm,no-completion-irq property
Merge tag 'memory-controller-drv-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v7.1
1. TegraMC:
- Few fixes for older issues - missing clock on Tegra264,
missing enabling of DLL for Tegra30 and Tegra124.
- Simplify the code in a few places.
- Rework handling interrupts on different variants and add support for
error logging on Tegra 264.
2. Drop Baikal SoC bt1-l2-ctl driver, because SoC support is being
removed tree-wide.
* tag 'memory-controller-drv-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: tegra: Add MC error logging support for Tegra264
memory: tegra: Prepare for supporting multiple intmask registers
memory: tegra: Group SoC specific fields
memory: tegra: Add support for multiple IRQs
memory: tegra: Group register and fields
memory: tegra: Group error handling related registers
memory: tegra-mc: Use %pe format
memory: tegra-mc: Simplify printing PTR_ERR with dev_err_probe
memory: tegra-mc: Drop tegra_mc_setup_latency_allowance() return value
memory: renesas-rpc-if: Simplify printing PTR_ERR with dev_err_probe
memory: brcmstb_memc: Expand LPDDR4 check to cover for LPDDR5
dt-bindings: cache: bt1-l2-ctl: Remove unused bindings
memory: bt1-l2-ctl: Remove not-going-to-be-supported code for Baikal SoC
memory: tegra30-emc: Fix dll_change check
memory: tegra124-emc: Fix dll_change check
memory: tegra: Add support for DBB clock on Tegra264
Merge tag 'samsung-drivers-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers
Samsung SoC drivers for v7.1
Few cleanups in ACPM firmware drivers, used on Google GS101 and newer
Samsung Exynos SoCs. Notable change is removing 'const' in
'struct acpm_handle' pointers, because even though the code does not
modify pointed data, it immediately drops the const via cast. Also code
is not logically readable when a reference getters/putters (e.g.
acpm_handle_put()) take a pointer to const, because the meaning of "get"
and "put" implies changing the memory, even if that changeable field is
outside of pointed data.
* tag 'samsung-drivers-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
firmware: exynos-acpm: Drop fake 'const' on handle pointer
dt-bindings: firmware: google,gs101-acpm-ipc: add S2MPG11 secondary PMIC
firmware: exynos-acpm: Count acpm_xfer buffers with __counted_by_ptr
firmware: exynos-acpm: Count number of commands in acpm_xfer
firmware: exynos-acpm: Use unsigned int for acpm_pmic_linux_errmap index
Julian Ruess [Wed, 25 Mar 2026 13:31:23 +0000 (14:31 +0100)]
vfio/pci: Rename vfio_config_do_rw() to vfio_pci_config_rw_single() and export it
A follow-up patch adds a new variant driver for s390 ISM devices. Since
this device uses a 256 TiB BAR 0 that is never mapped, the variant
driver needs its own ISM_VFIO_PCI_OFFSET_MASK. To minimally mirror the
functionality of vfio_pci_config_rw() with such a custom mask, export
vfio_config_do_rw(). To better distinguish the now exported function
from vfio_pci_config_rw(), rename it to vfio_pci_config_rw_single()
emphasizing that it does a single config space read or write.
Merge tag 'qcom-arm64-fixes-for-7.0-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
More Qualcomm Arm64 DeviceTree fixes for v7.0
The shuffling of reset and wake GPIO properties across various Hamoa
devices left things in an incomplete state, fix this.
Add the missing "ranges" property to the QCM2290 MDSS DeviceTree binding
example, to fix the validation warning that was introduced by the
previous fix.
Merge tag 'renesas-fixes-for-v7.0-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes
Renesas fixes for v7.0 (take two)
- Fix TFA BL31 memory corruption on Sparrow Hawk.
* tag 'renesas-fixes-for-v7.0-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM
Merge tag 'qcom-arm32-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
Qualcomm Arm32 DeviceTree updates for v7.1
Qualcomm APQ8084 is incomplete and hasn't seen functional contributions
since 2016, so drop the platform (for now?). Also drop a number of
unused IPQ-related dtsi files.
Lastly clean up the RPM bus clocks in MSM8974 interconnect nodes.
* tag 'qcom-arm32-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: dts: qcom: msm8974: Drop RPM bus clocks
ARM: dts: qcom: drop apq8084 support
ARM: dts: qcom: Drop unused .dtsi
Merge tag 'thead-dt-for-v7.1-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt
T-HEAD Devicetrees for 7.1, part 2
Additional updates to T-Head device trees for v7.1:
- Enable the display pipeline for the TH1520-based BeagleV Ahead board
by adding the HDMI connector node, connecting it to the HDMI
controller, and activating the DPU and HDMI nodes.
- Add coefficients to the TH1520 PVT node as the values in the TH1520
manual differ from the defaults in the driver.
* tag 'thead-dt-for-v7.1-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux:
riscv: dts: thead: beaglev-ahead: enable HDMI output
riscv: dts: thead: th1520: add coefficients to the PVT node
ftrace: Use kallsyms binary search for single-symbol lookup
When ftrace_lookup_symbols() is called with a single symbol (cnt == 1),
use kallsyms_lookup_name() for O(log N) binary search instead of the
full linear scan via kallsyms_on_each_symbol().
ftrace_lookup_symbols() was designed for batch resolution of many
symbols in a single pass. For large cnt this is efficient: a single
O(N) walk over all symbols with O(log cnt) binary search into the
sorted input array. But for cnt == 1 it still decompresses all ~200K
kernel symbols only to match one.
kallsyms_lookup_name() uses the sorted kallsyms index and needs only
~17 decompressions for a single lookup.
This is the common path for kprobe.session with exact function names,
where libbpf sends one symbol per BPF_LINK_CREATE syscall.
If binary lookup fails (duplicate symbol names where the first match
is not ftrace-instrumented), the function falls through to the existing
linear scan path.
Before (cnt=1, 50 kprobe.session programs):
Attach: 858 ms (kallsyms_expand_symbol 25% of CPU)
hkbinbin [Tue, 31 Mar 2026 05:39:16 +0000 (05:39 +0000)]
Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync
hci_le_big_create_sync() uses DEFINE_FLEX to allocate a
struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17)
BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31)
entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller
hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31,
the memcpy that copies conn->bis into cp->bis writes up to 14 bytes
past the stack buffer, corrupting adjacent stack memory.
This is trivially reproducible: binding an ISO socket with
bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will
eventually trigger hci_le_big_create_sync() from the HCI command
sync worker, causing a KASAN-detectable stack-out-of-bounds write:
BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0
Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71
Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to
HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that
conn->bis can actually carry.
Fixes: 42ecf1947135 ("Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending") Cc: stable@vger.kernel.org Signed-off-by: hkbinbin <hkbinbinbin@gmail.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Oleh Konko [Tue, 31 Mar 2026 11:52:13 +0000 (11:52 +0000)]
Bluetooth: SMP: derive legacy responder STK authentication from MITM state
The legacy responder path in smp_random() currently labels the stored
STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.
That reflects what the local service requested, not what the pairing
flow actually achieved.
For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear
and the resulting STK should remain unauthenticated even if the local
side requested HIGH security. Use the established MITM state when
storing the responder STK so the key metadata matches the pairing result.
This also keeps the legacy path aligned with the Secure Connections code,
which already treats JUST_WORKS/JUST_CFM as unauthenticated.
Fixes: fff3490f4781 ("Bluetooth: Fix setting correct authentication information for SMP STK") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko <security@1seal.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Oleh Konko [Tue, 31 Mar 2026 11:52:12 +0000 (11:52 +0000)]
Bluetooth: SMP: force responder MITM requirements before building the pairing response
smp_cmd_pairing_req() currently builds the pairing response from the
initiator auth_req before enforcing the local BT_SECURITY_HIGH
requirement. If the initiator omits SMP_AUTH_MITM, the response can
also omit it even though the local side still requires MITM.
tk_request() then sees an auth value without SMP_AUTH_MITM and may
select JUST_CFM, making method selection inconsistent with the pairing
policy the responder already enforces.
When the local side requires HIGH security, first verify that MITM can
be achieved from the IO capabilities and then force SMP_AUTH_MITM in the
response in both rsp.auth_req and auth. This keeps the responder auth bits
and later method selection aligned.
Fixes: 2b64d153a0cc ("Bluetooth: Add MITM mechanism to LE-SMP") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by: Oleh Konko <security@1seal.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
mesh_send() currently bounds MGMT_OP_MESH_SEND by total command
length, but it never verifies that the bytes supplied for the
flexible adv_data[] array actually match the embedded adv_data_len
field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a
truncated command can still pass the existing 20..50 byte range
check and later drive the async mesh send path past the end of the
queued command buffer.
Keep rejecting zero-length and oversized advertising payloads, but
validate adv_data_len explicitly and require the command length to
exactly match the flexible array size before queueing the request.
Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh") Reported-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Pauli Virtanen [Sun, 29 Mar 2026 13:43:02 +0000 (16:43 +0300)]
Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt
hci_conn lookup and field access must be covered by hdev lock in
hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed
concurrently.
Extend the hci_dev_lock critical section to cover all conn usage.
Fixes: 95118dd4edfec ("Bluetooth: hci_event: Use of a function table to handle LE subevents") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Pauli Virtanen [Sun, 29 Mar 2026 13:43:01 +0000 (16:43 +0300)]
Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync
hci_conn lookup and field access must be covered by hdev lock in
set_cig_params_sync, otherwise it's possible it is freed concurrently.
Take hdev lock to prevent hci_conn from being deleted or modified
concurrently. Just RCU lock is not suitable here, as we also want to
avoid "tearing" in the configuration.
Fixes: a091289218202 ("Bluetooth: hci_conn: Fix hci_le_set_cig_params") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Keenan Dong [Sat, 28 Mar 2026 08:46:47 +0000 (16:46 +0800)]
Bluetooth: MGMT: validate LTK enc_size on load
Load Long Term Keys stores the user-provided enc_size and later uses
it to size fixed-size stack operations when replying to LE LTK
requests. An enc_size larger than the 16-byte key buffer can therefore
overflow the reply stack buffer.
Reject oversized enc_size values while validating the management LTK
record so invalid keys never reach the stored key state.
Fixes: 346af67b8d11 ("Bluetooth: Add MGMT handlers for dealing with SMP LTK's") Reported-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Commit 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during
initialization") fixed a race for hci commands sent during initialization.
However, there is still a race that happens if an hci event from one of
these commands is received before HCI_UART_REGISTERED has been set at
the end of hci_uart_register_dev(). The event will be ignored which
causes the command to fail with a timeout in the log:
"Bluetooth: hci0: command 0x1003 tx timeout"
This is because the hci event receive path (hci_uart_tty_receive ->
h4_recv) requires HCI_UART_REGISTERED to be set in h4_recv(), while the
hci command transmit path (hci_uart_send_frame -> h4_enqueue) only
requires HCI_UART_PROTO_INIT to be set in hci_uart_send_frame().
The check for HCI_UART_REGISTERED was originally added in commit c2578202919a ("Bluetooth: Fix H4 crash from incoming UART packets")
to fix a crash caused by hu->hdev being null dereferenced. That can no
longer happen: once HCI_UART_PROTO_INIT is set in hci_uart_register_dev()
all pointers (hu, hu->priv and hu->hdev) are valid, and
hci_uart_tty_receive() already calls h4_recv() on HCI_UART_PROTO_INIT
or HCI_UART_PROTO_READY.
Remove the check for HCI_UART_REGISTERED in h4_recv() to fix the race
condition.
Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_sync: Fix UAF in le_read_features_complete
This fixes the following backtrace caused by hci_conn being freed
before le_read_features_complete but after
hci_le_read_remote_features_sync so hci_conn_del -> hci_cmd_sync_dequeue
is not able to prevent it:
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
BUG: KASAN: slab-use-after-free in atomic_dec_and_test include/linux/atomic/atomic-instrumented.h:1383 [inline]
BUG: KASAN: slab-use-after-free in hci_conn_drop include/net/bluetooth/hci_core.h:1688 [inline]
BUG: KASAN: slab-use-after-free in le_read_features_complete+0x5b/0x340 net/bluetooth/hci_sync.c:7344
Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52
The buggy address belongs to the object at ffff8880796b0000
which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 16 bytes inside of
freed 8192-byte region [ffff8880796b0000, ffff8880796b2000)
Memory state around the buggy address: ffff8880796aff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880796aff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8880796b0000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^ ffff8880796b0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880796b0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Fixes: a106e50be74b ("Bluetooth: HCI: Add support for LL Extended Feature Set") Reported-by: syzbot+87badbb9094e008e0685@syzkaller.appspotmail.com Tested-by: syzbot+87badbb9094e008e0685@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=87badbb9094e008e0685 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Pauli Virtanen <pav@iki.fi>
Pauli Virtanen [Wed, 25 Mar 2026 19:07:43 +0000 (21:07 +0200)]
Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists
hci_cmd_sync_queue_once() needs to indicate whether a queue item was
added, so caller can know if callbacks are called, so it can avoid
leaking resources.
Change the function to return -EEXIST if queue item already exists.
Modify all callsites to handle that.
Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Oleh Konko [Thu, 26 Mar 2026 17:31:24 +0000 (17:31 +0000)]
Bluetooth: hci_event: move wake reason storage into validated event handlers
hci_store_wake_reason() is called from hci_event_packet() immediately
after stripping the HCI event header but before hci_event_func()
enforces the per-event minimum payload length from hci_ev_table.
This means a short HCI event frame can reach bacpy() before any bounds
check runs.
Rather than duplicating skb parsing and per-event length checks inside
hci_store_wake_reason(), move wake-address storage into the individual
event handlers after their existing event-length validation has
succeeded. Convert hci_store_wake_reason() into a small helper that only
stores an already-validated bdaddr while the caller holds hci_dev_lock().
Use the same helper after hci_event_func() with a NULL address to
preserve the existing unexpected-wake fallback semantics when no
validated event handler records a wake address.
Annotate the helper with __must_hold(&hdev->lock) and add
lockdep_assert_held(&hdev->lock) so future call paths keep the lock
contract explicit.
Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(),
hci_sync_conn_complete_evt(), le_conn_complete_evt(),
hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),
hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and
hci_le_past_received_evt().
Fixes: 2f20216c1d6f ("Bluetooth: Emit controller suspend and resume events") Cc: stable@vger.kernel.org Signed-off-by: Oleh Konko <security@1seal.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cen Zhang [Thu, 26 Mar 2026 15:16:45 +0000 (23:16 +0800)]
Bluetooth: SCO: fix race conditions in sco_sock_connect()
sco_sock_connect() checks sk_state and sk_type without holding
the socket lock. Two concurrent connect() syscalls on the same
socket can both pass the check and enter sco_connect(), leading
to use-after-free.
The buggy scenario involves three participants and was confirmed
with additional logging instrumentation:
Thread A (connect): HCI disconnect: Thread B (connect):
Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to
BT_CONNECT. Subsequent cleanup triggers double sock_put() and
use-after-free. Meanwhile conn1 is leaked as it was orphaned
when sco_conn_del() cleared the association.
Fix this by:
- Moving lock_sock() before the sk_state/sk_type checks in
sco_sock_connect() to serialize concurrent connect attempts
- Fixing the sk_type != SOCK_SEQPACKET check to actually
return the error instead of just assigning it
- Adding a state re-check in sco_connect() after lock_sock()
to catch state changes during the window between the locks
- Adding sco_pi(sk)->conn check in sco_chan_add() to prevent
double-attach of a socket to multiple connections
- Adding hci_conn_drop() on sco_chan_add failure to prevent
HCI connection leaks
Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Pauli Virtanen [Wed, 25 Mar 2026 19:07:46 +0000 (21:07 +0200)]
Bluetooth: hci_sync: call destroy in hci_cmd_sync_run if immediate
hci_cmd_sync_run() may run the work immediately if called from existing
sync work (otherwise it queues a new sync work). In this case it fails
to call the destroy() function.
On immediate run, make it behave same way as if item was queued
successfully: call destroy, and return 0.
The only callsite is hci_abort_conn() via hci_cmd_sync_run_once(), and
this changes its return value. However, its return value is not used
except as the return value for hci_disconnect(), and nothing uses the
return value of hci_disconnect(). Hence there should be no behavior
change anywhere.
Fixes: c898f6d7b093b ("Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add a kernel module that benchmarks queue_work() throughput on an
unbound workqueue to measure pool->lock contention under different
affinity scope configurations (cache vs cache_shard).
The module spawns N kthreads (default: num_online_cpus()), each bound
to a different CPU. All threads start simultaneously and queue work
items, measuring the latency of each queue_work() call. Results are
reported as p50/p90/p95 latencies for each affinity scope.
The affinity scope is switched between runs via the workqueue's sysfs
affinity_scope attribute (WQ_SYSFS), avoiding the need for any new
exported symbols.
The module runs as __init-only, returning -EAGAIN to auto-unload,
and can be re-run via insmod.
tools/workqueue: add CACHE_SHARD support to wq_dump.py
The WQ_AFFN_CACHE_SHARD affinity scope was added to the kernel but
wq_dump.py was not updated to enumerate it. Add the missing constant
lookup and include it in the affinity scopes iteration so that drgn
output shows the CACHE_SHARD pod topology alongside the other scopes.
workqueue: set WQ_AFFN_CACHE_SHARD as the default affinity scope
Set WQ_AFFN_CACHE_SHARD as the default affinity scope for unbound
workqueues. On systems where many CPUs share one LLC, the previous
default (WQ_AFFN_CACHE) collapses all CPUs to a single worker pool,
causing heavy spinlock contention on pool->lock.
WQ_AFFN_CACHE_SHARD subdivides each LLC into smaller groups, providing
a better balance between locality and contention. Users can revert to
the previous behavior with workqueue.default_affinity_scope=cache.
On systems with 8 or fewer cores per LLC, CACHE_SHARD produces a single
shard covering the entire LLC, making it functionally identical to the
previous CACHE default. The sharding only activates when an LLC has more
than 8 cores.
On systems where many CPUs share one LLC, unbound workqueues using
WQ_AFFN_CACHE collapse to a single worker pool, causing heavy spinlock
contention on pool->lock. For example, Chuck Lever measured 39% of
cycles lost to native_queued_spin_lock_slowpath on a 12-core shared-L3
NFS-over-RDMA system.
The existing affinity hierarchy (cpu, smt, cache, numa, system) offers
no intermediate option between per-LLC and per-SMT-core granularity.
Add WQ_AFFN_CACHE_SHARD, which subdivides each LLC into groups of at
most wq_cache_shard_size cores (default 8, tunable via boot parameter).
Shards are always split on core (SMT group) boundaries so that
Hyper-Threading siblings are never placed in different pods. Cores are
distributed across shards as evenly as possible -- for example, 36 cores
in a single LLC with max shard size 8 produces 5 shards of 8+7+7+7+7
cores.
The implementation follows the same comparator pattern as other affinity
scopes: precompute_cache_shard_ids() pre-fills the cpu_shard_id[] array
from the already-initialized WQ_AFFN_CACHE and WQ_AFFN_SMT topology,
and cpus_share_cache_shard() is passed to init_pod_type().
Benchmark on NVIDIA Grace (72 CPUs, single LLC, 50k items/thread), show
cache_shard delivers ~5x the throughput and ~6.5x lower p50 latency
compared to cache scope on this 72-core single-LLC system.
Matthew Brost [Wed, 1 Apr 2026 01:07:39 +0000 (18:07 -0700)]
workqueue: Add pool_workqueue to pending_pwqs list when unplugging multiple inactive works
In unplug_oldest_pwq(), the first inactive work item on the
pool_workqueue is activated correctly. However, if multiple inactive
works exist on the same pool_workqueue, subsequent works fail to
activate because wq_node_nr_active.pending_pwqs is empty — the list
insertion is skipped when the pool_workqueue is plugged.
Fix this by checking for additional inactive works in
unplug_oldest_pwq() and updating wq_node_nr_active.pending_pwqs
accordingly.
Fixes: 4c065dbce1e8 ("workqueue: Enable unbound cpumask update on ordered workqueues") Cc: stable@vger.kernel.org Cc: Carlos Santa <carlos.santa@intel.com> Cc: Ryan Neph <ryanneph@google.com> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Waiman Long <longman@redhat.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Waiman Long <longman@redhat.com>
Eric Biggers [Wed, 1 Apr 2026 00:33:31 +0000 (17:33 -0700)]
lib/crypto: arm64: Assume a little-endian kernel
Since support for big-endian arm64 kernels was removed, the CPU_LE()
macro now unconditionally emits the code it is passed, and the CPU_BE()
macro now unconditionally discards the code it is passed.
Simplify the assembly code in lib/crypto/arm64/ accordingly.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode
NEON at context switch"), kernel-mode NEON sections have been
preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further
restrict the preemption modes"), voluntary preemption is no longer
supported on arm64 either. Therefore, there's no longer any need to
limit the length of kernel-mode NEON sections on arm64.
MIPS: mm: Rewrite TLB uniquification for the hidden bit feature
Before the introduction of the EHINV feature, which lets software mark
TLB entries invalid, certain older implementations of the MIPS ISA were
equipped with an analogous bit, as a vendor extension, which however is
hidden from software and only ever set at reset, and then any software
write clears it, making the intended TLB entry valid.
This feature makes it unsafe to read a TLB entry with TLBR, modify the
page mask, and write the entry back with TLBWI, because this operation
will implicitly clear the hidden bit and this may create a duplicate
entry, as with the presence of the hidden bit there is no guarantee all
the entries across the TLB are unique each.
Usually the firmware has already uniquified TLB entries before handing
control over, in which case we only need to guarantee at bootstrap no
clash will happen with the VPN2 values chosen in local_flush_tlb_all().
However with systems such as Mikrotik RB532 we get handed the TLB as at
reset, with the hidden bit set across the entries and possibly duplicate
entries present. This then causes a machine check exception when page
sizes are reset in r4k_tlb_uniquify() and prevents the system from
booting.
Rewrite the algorithm used in r4k_tlb_uniquify() then such as to avoid
the reuse of ASID/VPN values across the TLB. Get rid of global entries
first as they may be blocking the entire address space, e.g. 16 256MiB
pages will exhaust the whole address space of a 32-bit CPU and a single
big page can exhaust the 32-bit compatibility space on a 64-bit CPU.
Details of the algorithm chosen are given across the code itself.
Fixes: 9f048fa48740 ("MIPS: mm: Prevent a TLB shutdown on initial uniquification") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
MIPS: mm: Suppress TLB uniquification on EHINV hardware
Hardware that supports the EHINV feature, mandatory for R6 ISA and FTLB
implementation, lets software mark TLB entries invalid, which eliminates
the need to ensure no duplicate matching entries are ever created. This
feature is already used by local_flush_tlb_all(), via the UNIQUE_ENTRYHI
macro, making the preceding call to r4k_tlb_uniquify() superfluous.
The next change will also modify uniquification code such that it'll
become incompatible with the FTLB and MMID features, as well as MIPSr6
CPUs that do not implement 4KiB pages.
Therefore prevent r4k_tlb_uniquify() from being used on EHINV hardware,
as denoted by `cpu_has_tlbinv'.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
With a 32-bit kernel running on 64-bit MIPS hardware the hardcoded value
of `cpu_vmbits' only records the size of compatibility useg and does not
reflect the size of native xuseg or the complete range of values allowed
in the VPN2 field of TLB entries.
An upcoming change will need the actual VPN2 value range permitted even
in 32-bit kernel configurations, so always include the `vmbits' member
in `struct cpuinfo_mips' and probe for SEGBITS when running on 64-bit
hardware and resorting to the currently hardcoded value of 31 on 32-bit
processors. No functional change for users of `cpu_vmbits'.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
MIPS: Fix the GCC version check for `__multi3' workaround
It was only GCC 10 that fixed a MIPS64r6 code generation issue with a
`__multi3' libcall inefficiently produced to perform 64-bit widening
multiplication while suitable machine instructions exist to do such a
calculation. The fix went in with GCC commit 48b2123f6336 ("re PR
target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)").
Adjust our code accordingly, removing build failures such as:
mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64':
div64.c:(.text+0x84): undefined reference to `__multi3'
with the GCC versions affected.
Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/ Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v4.15+ Reviewed-by: David Laight <david.laight.linux@gmail.com. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
The cause of the problem is R4k cache handlers are also used by Broadcom
SiByte SB1 cores, however with a different cache error exception handler
and therefore not using CPU_R4K_CACHE_TLB:
Rong Zhang [Sun, 15 Mar 2026 17:28:22 +0000 (01:28 +0800)]
MIPS: Loongson64: env: Check UARTs passed by LEFI cautiously
Some firmware does not set nr_uarts properly and passes empty items.
Iterate at most min(system->nr_uarts, MAX_UARTS) items to prevent
out-of-bounds access, and ignore UARTs with addr 0 silently.
Meanwhile, our DT only works with UPIO_MEM but theoretically firmware
may pass other IO types, so explicitly check against that.
Tested on Loongson-LS3A4000-7A1000-NUC-SE.
Fixes: 3989ed418483 ("MIPS: Loongson64: env: Fixup serial clock-frequency when using LEFI") Cc: stable@vger.kernel.org Reviewed-by: Yao Zi <me@ziyao.cc> Signed-off-by: Rong Zhang <rongrong@oss.cipunited.com> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Since commit 3a3f61ce5e0b ("exec: Make sure task->comm is always
NUL-terminated"), __set_task_comm() is unlocked and no longer uses
strscpy_pad() - update the stale comment accordingly.
Yazen Ghannam [Sat, 7 Mar 2026 14:10:24 +0000 (08:10 -0600)]
x86/CPU/AMD: Print AGESA string from DMI additional information entry
Type 40 entries (Additional Information) are summarized in section 7.41 as
part of the SMBIOS specification. Generally, these entries aren't interesting
to save.
However on some AMD Zen systems, the AGESA version is stored here. This is
useful to save to the kernel message logs for debugging. It can be used to
cross-reference issues.
Implement an iterator for the Additional Information entries. Use this to find
and print the AGESA string. Do so in AMD code, since the use case is
AMD-specific.
dmi_decode() has hardcoded values with comments for each DMI entry type. The
same information is already in dmi.h though, so drop the comments and use the
definitions instead.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Link: https://patch.msgid.link/20260307141024.819807-3-superm1@kernel.org
Shengjiu Wang [Wed, 1 Apr 2026 09:42:26 +0000 (17:42 +0800)]
ASoC: fsl_easrc: Change the type for iec958 channel status controls
Use the type SNDRV_CTL_ELEM_TYPE_IEC958 for iec958 channel status
controls, the original type will cause mixer-test to iterate all 32bit
values, which costs a lot of time. And using IEC958 type can reduce the
control numbers.
Also enable pm runtime before updating registers to make the regmap cache
data align with the value in hardware.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:23 +0000 (17:42 +0800)]
ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put()
ALSA controls should return 1 if the value in the control changed but the
control put operation fsl_xcvr_mode_put() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Add a suitable check in the function before updating the mode variable.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:22 +0000 (17:42 +0800)]
ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put()
ALSA controls should return 1 if the value in the control changed but the
control put operation fsl_xcvr_arc_mode_put() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Add a suitable check in the function before updating the arc_mode
variable.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:21 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Fix event generation in micfil_quality_set()
ALSA controls should return 1 if the value in the control changed but the
control put operation micfil_quality_set() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Add a suitable check in the function before updating the quality variable.
Also enable pm runtime before calling the function micfil_set_quality()
to make the regmap cache data align with the value in hardware.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:20 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Fix event generation in micfil_put_dc_remover_state()
ALSA controls should return 1 if the value in the control changed but the
control put operation micfil_put_dc_remover_state() only returns 0 or a
negative error code, causing ALSA to not generate any change events.
return the value of snd_soc_component_update_bits() directly, as it has
the capability of return check status of changed or not.
Also enable pm runtime before calling the function
snd_soc_component_update_bits() to make the regmap cache data align with
the value in hardware.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:19 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Fix event generation in micfil_range_set()
ALSA controls should return 1 if the value in the control changed but the
control put operation micfil_range_set() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Use snd_soc_component_update_bits() function to replace the
regmap_update_bits(), for snd_soc_component_update_bits() has the
capability of return check status.
Also enable pm runtime before calling the function
snd_soc_component_update_bits() to make the regmap cache data align with
the value in hardware.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:18 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Fix event generation in hwvad_put_init_mode()
ALSA controls should return 1 if the value in the control changed but the
control put operation hwvad_put_init_mode() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Add a suitable check in the function before updating the vad_init_mode
variable.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:17 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Fix event generation in hwvad_put_enable()
ALSA controls should return 1 if the value in the control changed but the
control put operation hwvad_put_enable() only returns 0 or a negative
error code, causing ALSA to not generate any change events.
Add a suitable check in the function before updating the vad_enabled
variable.
Shengjiu Wang [Wed, 1 Apr 2026 09:42:16 +0000 (17:42 +0800)]
ASoC: fsl_micfil: Add access property for "VAD Detected"
Add access property SNDRV_CTL_ELEM_ACCESS_READ for control "VAD
Detected", which doesn't support put operation, otherwise there will be
issue with mixer-test.
Johan Hovold [Fri, 27 Mar 2026 10:43:05 +0000 (11:43 +0100)]
spi: ch341: fix devres lifetime
USB drivers bind to USB interfaces and any device managed resources
should have their lifetime tied to the interface rather than parent USB
device. This avoids issues like memory leaks when drivers are unbound
without their devices being physically disconnected (e.g. on probe
deferral or configuration changes).
Fix the controller and driver data lifetime so that they are released
on driver unbind.
Note that this also makes sure that the SPI controller is placed
correctly under the USB interface in the device tree.
Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: stable@vger.kernel.org # 6.11 Cc: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260327104305.1309915-3-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Johan Hovold [Fri, 27 Mar 2026 10:43:04 +0000 (11:43 +0100)]
spi: ch341: fix memory leaks on probe failures
Make sure to deregister the controller, disable pins, and kill and free
the RX URB on probe failures to mirror disconnect and avoid memory
leaks and use-after-free.
Also add an explicit URB kill on disconnect for symmetry (even if that
is not strictly required as USB core would have stopped it in the
current setup).
Fixes: 8846739f52af ("spi: add ch341a usb2spi driver") Cc: stable@vger.kernel.org # 6.11 Cc: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260327104305.1309915-2-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Merge tag 'renesas-dts-for-v7.1-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v7.1 (take two)
- Add DT overlay support for the MayQueen PixPaper display on the
Yuridenki-Shokai Kakip board,
- Add Ethernet PHY interrupt support for the RZ/T2H and RZ/N2H EVK
boards,
- Add SPI and PCIe support for the RZ/G3E SoC and the RZ/G3E SMARC EVK
board,
- Add DT overlay support for the WaveShare 13.3" 1920x1080 DSI
Capacitive Touch Display and the Olimex MIPI-HDMI adapter on the
Retronix Sparrow Hawk board,
- Drop several superfluous C22 Ethernet PHY compatible strings,
- Remove WDT nodes meant for other CPU cores on the RZ/V2N SoC,
- Remove unavailable LVDS panel support for the Beacon ReneSoM base
board,
- Add initial support for the RZ/G3L (R9A08G046) SoC, and the RZ/G3L
SMARC SoM and EVK boards,
- Add Versa3 clock generator support for the RZ/V2H EVK development
board,
- Miscellaneous fixes and improvements.
Kevin Brodsky [Wed, 18 Mar 2026 09:25:43 +0000 (09:25 +0000)]
arm64: mm: Use generic enum pgtable_level
enum pgtable_type was introduced for arm64 by commit c64f46ee1377
("arm64: mm: use enum to identify pgtable level instead of
*_SHIFT"). In the meantime, the generic enum pgtable_level got
introduced by commit b22cc9a9c7ff ("mm/rmap: convert "enum
rmap_level" to "enum pgtable_level"").
Let's switch to the generic enum pgtable_level. The only difference
is that it also includes PGD level; __pgd_pgtable_alloc() isn't
expected to create PGD tables so we add a VM_WARN_ON() for that
case.
Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arm64/mm: Reject memory removal that splits a kernel leaf mapping
Linear and vmemmap mappings that get torn down during a memory hot remove
operation might contain leaf level entries on any page table level. If the
requested memory range's linear or vmemmap mappings falls within such leaf
entries, new mappings need to be created for the remaining memory mapped on
the leaf entry earlier, following standard break before make aka BBM rules.
But kernel cannot tolerate BBM and hence remapping to fine grained leaves
would not be possible on systems without BBML2_NOABORT.
Currently memory hot remove operation does not perform such restructuring,
and so removing memory ranges that could split a kernel leaf level mapping
need to be rejected.
While memory_hotplug.c does appear to permit hot removing arbitrary ranges
of memory, the higher layers that drive memory_hotplug (e.g. ACPI, virtio,
...) all appear to treat memory as fixed size devices. So it is impossible
to hot unplug a different amount than was previously hot plugged, and hence
we should never see a rejection in practice, but adding the check makes us
robust against a future change.
Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Suggested-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
During a memory hot remove operation, both linear and vmemmap mappings for
the memory range being removed, get unmapped via unmap_hotplug_range() but
mapped pages get freed only for vmemmap mapping. This is just a sequential
operation where each table entry gets cleared, followed by a leaf specific
TLB flush, and then followed by memory free operation when applicable.
This approach was simple and uniform both for vmemmap and linear mappings.
But linear mapping might contain CONT marked block memory where it becomes
necessary to first clear out all entire in the range before a TLB flush.
This is as per the architecture requirement. Hence batch all TLB flushes
during the table tear down walk and finally do it in unmap_hotplug_range().
Prior to this fix, it was hypothetically possible for a speculative access
to a higher address in the contiguous block to fill the TLB with shattered
entries for the entire contiguous range after a lower address had already
been cleared and invalidated. Due to the table entries being shattered, the
subsequent TLB invalidation for the higher address would not then clear the
TLB entries for the lower address, meaning stale TLB entries could persist.
Besides it also helps in improving the performance via TLBI range operation
along with reduced synchronization instructions. The time spent executing
unmap_hotplug_range() improved 97% measured over a 2GB memory hot removal
in KVM guest.
This scheme is not applicable during vmemmap mapping tear down where memory
needs to be freed and hence a TLB flush is required after clearing out page
table entry.
Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Closes: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/ Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Li Ming [Wed, 1 Apr 2026 12:49:51 +0000 (20:49 +0800)]
cxl/region: Add a region sysfs interface for region lock status
There are 3 scenarios that leads to a locked region:
1. A region is created on a root decoder with Fixed Device Confiuration
attribute.
2. CXL_HDM_DECODER0_CTRL_LOCK.
Both 1 & 1 are well described in:
commit 2230c4bdc412 ("cxl: Add handling of locked CXL decoder")
3) Platform that has region creation with PRMT address translation always
locks the region, regardless of the FIXED attribute or decoder ctrl bit.
Region locked means region destroy operations are not permitted. CXL
region driver returns -EPERM for region destroy operations.
Although the locked status of the corresponding root decoder implies the
region is also locked, exposing the region lock status directly to
userspace improves usability for users who may not be aware of this
relationship.
[ dj: Amended commit log with additional locking scenarios. ]
Signed-off-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260401124951.1290041-1-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Merge tag 'stm32-dt-for-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/dt
STM32 DT for v7.1, round 1
Highlights:
----------
- MPU:
- STM32MP13:
- Introduce and enable debug bus on DK board.
- Enable Coresight on DK board.
- Add DT overlays for DH board.
- Add Wakeup capabilities on I2C nodes.
- STMP32MP15:
- ST:
- Enable DCMI DMA chaining to improve performances.
- Introduce and enable debug bus on EV and DK board.
- Enable Coresight on EV and DK board.
- DH:
- Add DT overlays for DH board.
- Phytec:
- Rename "Phycore" to "phyboard-sargas" DT files and introduce
SOM device tree file.
- Fix and enhance current support.
- STM32MP21:
- Add Bsec support.
- STM32MP23:
- Add LTDC and LVDS support and enable display on STM32MP235F-DK
board.
- STM32MP25:
- Enable display on STM32MP235F-DK board.
* tag 'stm32-dt-for-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (42 commits)
arm64: defconfig: Enable STMicroelectronics STM32 display support
arm64: dts: st: enable display support on stm32mp257f-dk board
arm64: dts: st: describe power supplies for stm32mp257f-dk board
arm64: dts: st: enable display support on stm32mp235f-dk board
arm64: dts: st: describe power supplies for stm32mp235f-dk board
arm64: dts: st: add clock-cells to syscfg node on stm32mp231
arm64: dts: st: add lvds support on stm32mp235
arm64: dts: st: add ltdc support on stm32mp235
arm64: dts: st: add ltdc support on stm32mp231
arm64: dts: st: omit unused pinctrl groups from stm32mp25 dtb files
arm64: dts: st: add bootph-all in bsec node to stm32mp215f-dk
arm64: dts: st: add bsec support to stm32mp21
ARM: dts: stm32: fix misalignments in nodes of stm32mp131
ARM: dts: stm32: fix misalignments in nodes of stm32mp151
arm64: dts: st: describe i2c2 / i2c8 on stm32mp235f-dk
arm64: dts: st: describe i2c2 / i2c8 on stm32mp257f-dk
arm64: dts: st: disable DMA usage for i2c on stm32mp257f-ev1
arm64: dts: st: add i2c2 pinmux nodes in stm32mp25-pinctrl.dtsi
arm64: dts: st: update i2c nodes interrupt/wakeup-source in stm32mp231
arm64: dts: st: update i2c nodes interrupt/wakeup-source in stm32mp251
...
projects / thirdparty / kernel / linux.git / log
