Lt9611c improvement series#1346
Open
mohitdsor wants to merge 2213 commits into
Open
Conversation
When both 'ice' reg entry and 'qcom,ice' property are not found in DT, then it implies that ICE is not supported. So return -EOPNOTSUPP instead of -ENODEV to client drivers to specify ICE functionality is not supported. Fixes: b9ab721 ("soc: qcom: ice: Return proper error codes from devm_of_qcom_ice_get() instead of NULL") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/linux-arm-msm/8bac0358-9da0-4cbb-98ee-333b85ba4908@samsung.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260520155704.130803-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On Glymur, all QMP PHYs except the one used by USB SS0 take their reference clock from the TCSR clock controller. Since these TCSR clocks already derive from RPMH_CXO_CLK as their sole parent, there is no need to provide an extra `clkref` clock to the PHY nodes. Drop the extra RPMh CXO clock inputs and use the TCSR clocks as the PHY reference clocks instead. This also fixes the devicetree schema validation, as the bindings do not allow a separate `clkref` clock. Fixes: 4eee57d ("arm64: dts: qcom: glymur: Add USB related nodes") Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/r/20260410145205.GA554754-robh@kernel.org/ Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
…erve its pins i2c20 is used by the battmgr service on the ADSP to communicate with the SBS interface of the battery. Initializing it from Linux would break the battmgr functionality when booted in EL2. Mark those pins as reserved. Fixes: e7733b4 ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/20260312005731.12488-2-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the UFS_PHY_GDSC power domain is enabled. Specify both the UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for milos. Fixes: 04bb374 ("arm64: dts: qcom: milos: Add UFS nodes") Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-12-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes for its own resources. Before accessing ICE hardware during probe, to avoid potential unclocked register access issues (when clk_ignore_unused is not passed on the kernel command line), in addition to the 'core' clock the 'iface' clock should also be turned on by the driver. This can only be done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for eliza. Fixes: af20af3 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi") Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 54a4f02 ("KVM: MMU: make kvm_mmu_zap_page() return the Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-13-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
POWER_SEQUENCING_PCIE_M2 driver handles power supply to the PCIe M.2 connectors and is required on wide variety of ARM64 platforms such as Qcom Snapdragon X Elite laptops and Mediatek Dojo Chromebooks. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260514065017.11305-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
These FIS partition offsets were never right: the comment clearly states the FIS index is at 0xfe0000 and 0x7f * 0x200000 is 0xfe0000. Tested on the iTian SQ201. Fixes: d88b11e ("ARM: dts: Fix up SQ201 flash access") Fixes: b5a923f ("ARM: dts: gemini: Switch to redboot partition parsing") Signed-off-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The i.MX8M soc device is registered via platform_device_register_simple(), so it is not associated with a Device Tree node and the imx8m_soc_driver has no of_match_table. As a result, device_get_match_data() always returns NULL when probing the soc device. Retrieve the match data directly from the machine compatible using of_machine_get_match_data(imx8_soc_match), which provides the correct SoC data. Fixes: 2524b29 ("soc: imx8m: don't access of_root directly") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Sashiko identified a cross-thread RX length corruption bug when reviewing the thermal addition to ACPM [1]. When multiple threads concurrently send IPC requests, the ACPM polling mechanism can encounter responses belonging to other threads. To drain the queue, the driver saves these concurrent responses into an internal cache (`rx_data->cmd`) to be retrieved later by the owning thread. Previously, the driver incorrectly used `xfer->rxcnt` (the expected receive length of the *current* polling thread) when copying data for *other* threads into this cache. If the threads expected responses of different lengths, this resulted in buffer underflows (leading to reads of uninitialized memory) or potential buffer overflows. Fix this by replacing the boolean `response` flag in `struct acpm_rx_data` with `rxcnt`, caching the exact expected receive length for each specific transaction during transfer preparation. Use this cached length when saving concurrent responses. Consequently, ensure that `xfer->rxcnt` is explicitly zeroed in driver helpers (e.g., `acpm_dvfs_set_xfer`) for fire-and-forget messages to prevent uninitialized stack garbage from being interpreted as a massive expected receive length. Cc: stable@vger.kernel.org Fixes: a88927b ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Reported-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com> Closes: https://lore.kernel.org/r/20260426210255.73674-1-titouan.ameline@gmail.com/ Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-1-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Sashiko identified the leak at [1]. The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_channels_init()`. However, the driver lacked a `.remove` callback and did not free these channels on subsequent error paths inside `acpm_probe()`. Additionally, if `acpm_achan_alloc_cmds()` failed during the channel initialization loop, the function returned immediately, bypassing the manual cleanup and permanently leaking any channels successfully requested in previous loop iterations. Fix this by modifying `acpm_free_mbox_chans()` to match the `devres` action signature and registering it via `devm_add_action_or_reset()`. Cc: stable@vger.kernel.org Fixes: a88927b ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-2-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
…ling Sashiko identified severe races in the polling state machine [1]. In the ACPM driver's polling mode, threads waited for responses by monitoring the globally shared 'bitmap_seqnum'. This caused false timeouts because if a thread processed its response and freed the sequence number, a concurrent TX thread could immediately reallocate it before the polling thread woke up. Additionally, the driver suffered from a cross-thread Use-After-Free (UAF) preemption race. Previously, acpm_get_rx() cleared the sequence number of whichever RX message it drained from the hardware queue. This meant Thread A could globally free Thread B's sequence slot while Thread B was asleep. A new Thread C could then steal the slot, overwrite the buffer, and leave Thread B to wake up to corrupted state or a timeout. Fix this by rewriting the polling state machine: 1. Decouple polling from the global allocator by introducing a per-slot 'completed' flag, synchronized via smp_store_release() and smp_load_acquire(). 2. Strip acpm_get_saved_rx() out of acpm_get_rx() to make it a pure queue-draining function. Introduce a 'native_match' boolean argument which evaluates to true only if the thread natively processed its own sequence number during the call. This explicitly informs the polling loop whether it must retrieve its payload from the cross-thread cache. 3. Centralize the cache fallback and sequence number free (clear_bit) inside the polling loop. Crucially, the free operation now strictly targets the thread's own TX sequence number (xfer->txd[0]), rather than the drained RX sequence number. This enforces strict ownership: a thread only ever frees its own allocated sequence slot, and only at the exact moment it completes its poll, eliminating the UAF window. Furthermore, explicitly guard the 'native_match' assignment with an if (rx_seqnum == tx_seqnum) check, even for zero-length (no payload) responses. While an unguarded assignment wouldn't crash (because the cache fallback acpm_get_saved_rx() safely returns early on zero-length transfers) doing so would "lie" to the state machine. If a thread drained the queue and found another thread's zero-length message, setting native_match = true would falsely convince the polling loop that it natively handled its own response. Maintaining a rigorous state machine requires that native_match is only set when a thread explicitly processes its own sequence number. Cc: stable@vger.kernel.org Fixes: a88927b ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-5-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Sashiko identified memory ordering races in [1]. The ACPM driver uses a globally shared 'bitmap_seqnum' to track available sequence numbers. Even though threads now strictly free their own sequence numbers, the allocation and freeing of these bits across concurrent threads are effectively lockless operations and require explicit LKMM memory barriers. Previously, the driver used plain bitwise operators (test_bit, set_bit, clear_bit), which lack ordering guarantees. This creates two race conditions on weakly ordered architectures like ARM64: 1. Polling Release Violation: The polling thread copies its payload and calls clear_bit(). Without a release barrier, the CPU can reorder the memory operations, making the cleared bit globally visible before the payload reads have fully completed. 2. TX Acquire Violation: The TX thread loops on test_bit(), calls set_bit(), and then wipes the payload buffer via memset(). Without an acquire barrier, the CPU can speculatively execute the memset() before the bit is safely and formally claimed. If these reorderings overlap, a new TX thread can claim the sequence number and overwrite the buffer while the original polling thread is still actively reading from it. Fix this by upgrading the bitwise operators. Wrap the TX allocation in test_and_set_bit_lock() to establish formal LKMM Acquire semantics, and pair it with clear_bit_unlock() in the polling path to enforce Release semantics. Cc: stable@vger.kernel.org Fixes: a88927b ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-6-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Sashiko identified a possible infinite loop [1]. ACPM IPC sequence numbers are tracked via a 64-bit bitmap. Previously, acpm_prepare_xfer() used a do...while loop to search for a free sequence number. If all 63 available sequence numbers are leaked due to transient hardware timeouts or mailbox failures, the bitmap becomes full. The next call to acpm_prepare_xfer() would enter an infinite loop. Fix this by utilizing the kernel's optimized bitmap search functions (find_next_zero_bit / find_first_zero_bit). If the pool is completely exhausted, log the failure and return -EBUSY to allow the kernel to fail gracefully instead of hanging. Furthermore, drop the allocation loop entirely. Because acpm_prepare_xfer() is strictly called under the 'tx_lock' mutex, sequence number allocations are perfectly serialized. If find_next_zero_bit() locates a free bit, a single test_and_set_bit_lock() is mathematically guaranteed to succeed. To enforce this locking invariant, wrap the allocation in a WARN_ON_ONCE. If the atomic set fails, it indicates the driver's mutex serialization is fundamentally broken. The warning generates a stack trace for debugging, while returning -EIO immediately aborts the transfer to prevent silent payload corruption. Cc: stable@vger.kernel.org Fixes: a88927b ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-7-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
After removing of_platform_default_populate() calls the atmel-ebi driver was affected by deferred probing. platform_driver_probe() is incompatible with deferred probing. This led to atmel-ebi driver eventually not being probed on at91 sam9x60-curiosity and other sam9x60 based boards. Subsequently the nand-controller driver (nand-controller being a child node of ebi) on that platform was not probed and thus raw NAND flash was inaccessible, preventing devices to boot with rootfs on raw NAND flash (e.g. with UBI/UBIFS). Fixes: 0b0f7e6 ("ARM: at91: remove unnecessary of_platform_default_populate calls") Cc: stable@vger.kernel.org Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Alexander Dahl <ada@thorsis.com> Link: https://patch.msgid.link/20260429125930.844790-1-ada@thorsis.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
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: 41af45a ("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>
socfpga_smp_prepare_cpus() looks up the Cortex-A9 SCU node with of_find_compatible_node(), which returns a node reference that must be released with of_node_put(). The function maps the SCU registers and then returns without dropping that reference, leaking the node on both the success path and the of_iomap() failure path. Drop the reference once the mapping attempt is complete. The returned MMIO mapping does not depend on keeping the device node reference held. Fixes: 122694a ("ARM: socfpga: use of_iomap to map the SCU") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
scx_show_state.py still reads scx_aborting and scx_bypass_depth as global symbols. Those symbols no longer exist after the state was moved into struct scx_sched, so the drgn script fails when it reaches either field. Read aborting and bypass_depth from scx_root instead. This preserves the script's current root-scheduler view: with sub-scheduler support, the reported values are for the root scheduler and sub-schedulers are not enumerated. Fixes: 5c8d98a ("sched_ext: Move bypass state into scx_sched") Fixes: c1743da ("sched_ext: Move aborting flag to per-scheduler field") Signed-off-by: Zicheng Qu <quzicheng@huawei.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded: WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440 scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence: Step Result --------------------------------- ---------------------------------- 1. cpu enabled on cgroup G cpu css = A 2. cpu toggled off then on for G A killed, B created (same cgroup) 3. an exiting task keeps A alive migration skips it, A now stale 4. +memory migrates G stale A vs current B pulls cpu in 5. cpu attach runs for all tasks hits a live, cpu-unchanged task 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep. The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired. Fixes: 8195136 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Matt Fleming <mfleming@cloudflare.com> Closes: https://lore.kernel.org/all/20260601124156.2205704-1-mfleming@cloudflare.com/ Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
…culation
When sibling CPU exclusion occurs, a partition's user_xcpus may contain
CPUs that were never actually granted to it. These CPUs are present in
user_xcpus(cs) but not in cs->effective_xcpus.
The partcmd_update path in update_parent_effective_cpumask() uses
user_xcpus(cs) (via the local variable xcpus) to compute the addmask
(CPUs to return to parent) and delmask (CPUs to request from parent).
This is incorrect:
1) When newmask removes a CPU that was previously excluded by a
sibling, addmask incorrectly includes that CPU and tries to return
it to the parent even though the partition never actually owned it,
causing CPU overlap with sibling partitions and triggering warnings
in generate_sched_domains().
2) When newmask adds a previously excluded CPU that is now available,
delmask fails to request it from the parent because user_xcpus(cs)
already includes it.
Fix this by using cs->effective_xcpus instead of user_xcpus(cs) in all
partcmd_update paths that calculate addmask or delmask, including the
PERR_NOCPUS error handling paths.
Reproducers:
Example 1 - Removing a sibling-excluded CPU incorrectly returns it:
# cd /sys/fs/cgroup
# echo "0-1" > a1/cpuset.cpus
# echo "root" > a1/cpuset.cpus.partition
# echo "0-2" > b1/cpuset.cpus
# echo "root" > b1/cpuset.cpus.partition
# echo "2" > b1/cpuset.cpus
# cat cpuset.cpus.effective
# Actual: 0-1,3 Expected: 3
Example 2 - Expanding to a previously excluded CPU fails to request it:
# cd /sys/fs/cgroup
# echo "0-1" > a1/cpuset.cpus
# echo "root" > a1/cpuset.cpus.partition
# echo "0-2" > b1/cpuset.cpus
# echo "root" > b1/cpuset.cpus.partition
# echo "member" > a1/cpuset.cpus.partition
# echo "1-2" > b1/cpuset.cpus
# cat cpuset.cpus.effective
# Actual: 0-1,3 Expected: 0,3
Fixes: 2a36020 ("cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict")
Cc: stable@vger.kernel.org # v7.0+
Suggested-by: Zhang Guopeng <zhangguopeng@kylinos.cn>
Signed-off-by: Sun Shaojie <sunshaojie@kylinos.cn>
Reviewed-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
…update
When sibling CPU exclusion occurs, a partition's effective_xcpus may be
a subset of its user_xcpus. The partcmd_update path must use
effective_xcpus instead of user_xcpus when calculating CPUs to return
to or request from the parent.
Add two test cases to verify this behavior:
1) Narrowing cpuset.cpus to only the sibling-excluded CPUs should not
return CPUs to parent that the partition never actually owned.
2) Expanding cpuset.cpus after a sibling becomes a member should
correctly request the additional CPUs from parent.
Co-developed-by: Zhang Guopeng <zhangguopeng@kylinos.cn>
Signed-off-by: Zhang Guopeng <zhangguopeng@kylinos.cn>
Signed-off-by: Sun Shaojie <sunshaojie@kylinos.cn>
Reviewed-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The chenridong@huaweicloud.com is no longer a valid email, replace it with the personal email ridong.chen@linux.dev Signed-off-by: Ridong Chen <ridong.chen@linux.dev> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
When using the fixed-emmc-driver-type device tree property, the MMC core correctly selects the driver strength for the card but fails to program the host controller accordingly. This causes a mismatch where the card uses the specified driver type while the host controller defaults to Type B (since ios->drv_type remains zero). Split the driver type programming logic to handle both fixed and dynamic driver type selection paths. For fixed driver types, program the host controller with the selected drive_strength value. For dynamic selection, use the existing drv_type as before. This ensures both the eMMC device and host controller use matching driver strengths, preventing potential signal integrity issues. Fixes: 6186d06 ("mmc: parse new binding for eMMC fixed driver type") Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
…7700 The EIC7700 code in sdhci-of-dwcmshc uses host->mmc->caps2 to select different configuration paths for different card types. The current logic distinguishes eMMC and SD, but does not handle SDIO separately. Update the EIC7700 card-type checks so that eMMC, SD and SDIO are distinguished explicitly. Switch the reset path to dwcmshc_reset() so that pending interrupt state is cleared consistently, and use sdhci_enable_clk() so the clock enable sequence follows the standard SDHCI flow. Fixes: 32b2633 ("mmc: sdhci-of-dwcmshc: Add support for Eswin EIC7700") Signed-off-by: Huan He <hehuan1@eswincomputing.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The RZ/G2H (R8A774E1) SoC was previously handled via the generic "renesas,rcar-gen3-sdhi" fallback compatible string. However, because the SDHI IP on RZ/G2H is identical with the R-Car H3-N (R8A77951), it requires the specific quirks and configuration defined in `of_r8a7795_compatible` rather than the generic Gen3 data. Add the explicit "renesas,sdhi-r8a774e1" match entry to map it correctly. Note that the DT binding file renesas,sdhi.yaml does not need an update as the entry for this SoC is already present. Fixes: 3194134 ("arm64: dts: renesas: r8a774e1: Add SDHI nodes") Cc: stable@vger.kernel.org Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The previous clock uses roundup_pow_of_two() to calculate the core clock frequency. It does not meet the actual hardware meaning. The actual frequency is calculated by "ref_clk / ((div >> 1) << 1)". Fix the clock divider calculation. Fixes: 92e0991 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Gabriel Somlo <gsomlo@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The litex_mmc driver assumes the card is already probed in the BIOS and skip the phy initialization. This will cause the command fail like the following when the old card is unplugged and then insert a new card: [ 62.923593] litex-mmc f0004000.mmc: Command (cmd 8) error, status -110 [ 62.949717] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 62.976606] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.002516] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 [ 63.028442] litex-mmc f0004000.mmc: Command (cmd 55) error, status -110 Add required clock settings and initialization for the CMD 0, so it can probe the new card. Fixes: 92e0991 ("mmc: Add driver for LiteX's LiteSDCard interface") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Gabriel Somlo <gsomlo@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The really old controllers (rk2928, rk3066, rk3188) do not support UHS speeds at all, and thus never handled phase data. For that reason it never had a parse_dt callback and no driver private data at all. Commit ff6f028 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") makes the private data sort of mandatory, because the init function checks whether phases are configured internally or through the clock controller. This results in the old SoCs then experiencing NULL-pointer dereferences when they try to access that private-data struct. While we could have if (priv) conditionals in all places, it's way less cluttery to just give the old types their private-data struct. Fixes: ff6f028 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
I met one suspend/resume issue with sdr104 capable sdio wifi card (with "keep-power-in-suspend" set in DT property): After resuming from suspend to ram, the sdio wifi card stops working. Further debug shows that although ios shows the sdio card is at sdr104 mode, the voltage is still at 3V3. This is due to missing the calling of ->start_signal_voltage_switch() in sdhci_resume_host(). Fix this issue by adding ->start_signal_voltage_switch() in sdhci_resume_host(). This also matches what we do for sdhci_runtime_resume_host(). Then the question is: why this issue hasn't reported and fixed for so long time. IMHO, several reasons: Some host controllers just kick off the runtime resume for system resume, so they benefit from the well supported runtime pm code; Some platforms just use the old sdio wifi card which doesn't need signal voltage switch at all, the default voltage is 3v3 after resuming. Fixes: 6308d29 ("mmc: sdhci: add quirk for keeping card power during suspend") Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Enable IOMMUFD and VFIO cdev such that PCI pass-through to QEMU/KVM can optionally utilize native IOMMUFD. Note that because the defconfigs do not enable IOMMUFD_VFIO_CONTAINER the default PCI pass-through using VFIO with the existing container interface is not affected. Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
When CONFIG_DEBUG_BUGVERBOSE is disabled, the s390 __BUG_ENTRY() macro omits the format string pointer, so the generated __bug_table entry no longer matches struct bug_entry. With HAVE_ARCH_BUG_FORMAT enabled, the generic BUG infrastructure reads bug_entry::format via bug_get_format(). If the format word is missing, subsequent fields are read from the wrong offset, which may: - Misinterpret flags (BUG vs WARN classification errors) - Fault when dereferencing a misread format pointer The root cause is that __BUG_ENTRY() delegates format word emission to __BUG_ENTRY_VERBOSE(), which is conditional on CONFIG_DEBUG_BUGVERBOSE. Fix this by moving the format field emission directly into __BUG_ENTRY() so it is always emitted unconditionally. Remove the format parameter from __BUG_ENTRY_VERBOSE() and keep only file/line emission conditional on CONFIG_DEBUG_BUGVERBOSE. Fixes: 2b71b8a ("s390/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILED") Signed-off-by: Jan Polensky <japo@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the
uwtable annotation for functions, but not for the module. This means
that compiler-generated functions such as 'asan.module_ctor' do not
receive the uwtable annotation.
When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot
failures because the dwarf information emitted for the kasan
constructors is wrong, which causes the SCS boot patching code to
patch the constructor in an illegal manner. Specifically, the paciasp
instruction is patched, but the autiasp instruction is not. This
mismatch leads to a crash when the constructor is called during boot.
==================================================================
BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90
Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1
Specifically the faulting instruction is the (*fn)() to invoke the
constructor in do_ctors() of the init/main.c file.
Once the fix lands in rustc, this flag can be made conditional on the
rustc version. Note that passing the flag on a rustc with the fix
present has no effect.
[ The fix [1] has landed for Rust 1.98.0 (expected release on
2026-08-20).
Thus add a version check as discussed.
- Miguel ]
Fixes: d077242 ("rust: support for shadow call stack sanitizer")
Cc: stable@kernel.org
Link: rust-lang/rust#156973 [1]
Reported-by: Bo Ye <bo.ye@mediatek.com>
Debugged-by: Isaac Manjarres <isaacmanjarres@google.com>
Debugged-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Isaac Manjarres <isaacmanjarres@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260527-uwtable-module-flag-v1-1-caa41342be4b@google.com
[ Adjusted link and comment. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Starting with Rust 1.98.0 (expected 2026-08-20), the target spec will not
support `x86-softfloat` anymore [1]. Instead, `softfloat` should be used,
which is an alias. Otherwise, one gets:
error: error loading target specification: rustc-abi: invalid rustc abi: 'x86-softfloat'. allowed values: 'x86-sse2', 'softfloat' at line 3 column 32
|
= help: run `rustc --print target-list` for a list of built-in targets
Thus conditionally use one or the other depending on the version.
The alias has existed since Rust 1.95.0 (released 2026-04-16) [2], but
use the newer version instead to avoid changing how the build works for
existing compilers, at least until more testing takes place.
Cc: Ralf Jung <post@ralfj.de>
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: rust-lang/rust#157151 [1]
Link: rust-lang/rust#151154 [2]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260530114925.260754-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
It makes no sense to restore the saved value for a sticky mixer, since setting any value is a no-op. However, in some rare cases, SET_CUR is effective despite GET_CUR always returns a constant value. These mixers are not sticky, but there's no way to distinguish them. Without any additional information, the best thing we can do is to set the mixer value to the maximum before bailing out, so that a soft mixer can still reach the maximum hardware volume if the mixer turns out to be non-sticky. Meanwhile, all channels must be synchronized to prevent imbalance volume. Fixes: 86aa1ea ("ALSA: usb-audio: Do not expose sticky mixers") Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260531-uac-sticky-error-path-v1-1-12c2329d17ef@rong.moe Signed-off-by: Takashi Iwai <tiwai@suse.de>
Lenovo Yoga Pro 7 15ASH11 with AMD RYZEN AI MAX+ 388 (Strix Halo, ACP 7.0) uses Realtek ALC287 series codec and no any DMIC connected by ACP. All DMICs directly connet with ALC codec. Without this quirk, Input Device of Gnome Sound settings shows Internal Stereo Microphone and Digital Microphone by default. In fact, Digital Microphone of ACP doesn't work due to no connecting with ALC287 codec, the Internal Stereo Microphone as analog device based on snd_hda_intel driver can work well. Add a DMI quirk to override the flag to 0, consistent with the existing entry for the HN7306EA. Signed-off-by: Jackie Dong <xy-jackie@139.com> Link: https://patch.msgid.link/20260527102005.58528-1-xy-jackie@139.com Signed-off-by: Mark Brown <broonie@kernel.org>
The MSI Bravo 17 C7VF routes its internal digital microphone through the ACP6x. The machine driver only enables the DMIC for boards present in the DMI quirk table, so on this model the internal mic is never detected and no capture device is created. Add a quirk entry matching the board's DMI identifiers so the DMIC is enabled and the internal microphone works. Signed-off-by: João Miguel <jmiguel.ghp@gmail.com> Link: https://patch.msgid.link/20260523213548.5219-1-jmiguel.ghp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
When configuring 32 slots TDM (channels == slots == 32), the xMR (Mask Register) write used: ~0UL - ((1 << min(channels, slots)) - 1) The literal "1" is a signed 32-bit int. Shifting it by 32 positions is undefined behaviour which may set this register to 0xFFFFFFFF, masking all 32 slots. Use GENMASK_U32() macro instead. For 32 slots this produces a zero mask: ~GENMASK_U32(31, 0) = ~0xFFFFFFFF = 0x00000000 Behaviour for fewer than 32 slots is unchanged. Fixes: 770f58d ("ASoC: fsl_sai: Support multiple data channel enable bits") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Reviewed-by: Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://patch.msgid.link/20260601083327.1535185-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
The MSI Raider A18 HX A9WJG has an internal digital microphone connected through AMD ACP6x, but this machine does not expose the AcpDmicConnected ACPI property, so acp_yc_mach does not bind. Add a DMI quirk for this model. This was tested on an MSI Raider A18 HX A9WJG with board MS-182L, BIOS E182LAMS.31A, AMD ACP6x rev 0x62, and Realtek ALC274. After applying the quirk, the internal microphone appears as an acp6x DMIC capture device and records correctly. Signed-off-by: David Glushkov <david.glushkov@sntiq.com> Link: https://patch.msgid.link/20260531214512.170716-1-david.glushkov@sntiq.com Signed-off-by: Mark Brown <broonie@kernel.org>
The ASUS Vivobook 18 M1807GA (AMD ACP7.x, PCI 1022:15e2, subsystem 1043:3531) exposes a single Realtek RT721 SDCA codec on SoundWire link 1. The BIOS reports the ACP audio config flag as 0 (SoundWire mode), so snd_pci_ps claims the device, brings up the SoundWire managers and enumerates the RT721 peripheral (sdw:0:1:025d:0721:01); the rt721-sdca codec driver binds successfully. No sound card is created, however: acp63_sdw_machine_select() walks snd_soc_acpi_amd_acp70_sdw_machines[] and finds no entry whose declared SoundWire peripherals are all present on the bus. The only existing RT721 entry, acp70_rt721_l1u0_tas2783x2_l1u8b, additionally requires two TAS2783 amplifiers and deliberately exposes the RT721 as jack + DMIC only. This M1807GA variant has no external amplifiers - the RT721's internal AIF2 amplifier path drives the speakers - so that entry never matches and no machine device is registered. Add a standalone RT721 machine entry for link 1 exposing all three RT721 endpoints (jack/AIF1, speaker amplifier/AIF2, DMIC/AIF3), mirroring the standalone RT722 configuration. Place it after the TAS2783 combo entry so platforms that do have the external amplifiers continue to match the more specific entry first. ACPI _ADR of the codec: 0x000130025D072101 (link_id=1 version=3 mfg_id=0x025d Realtek part_id=0x0721 class=0x01). Verified on the hardware: with the entry present the amd_sdw machine binds, an "amd-soundwire" card is registered exposing the rt721-sdca AIF1 (SimpleJack) and AIF2 (SmartAmp) PCM devices, and audio plays out of the built-in speakers. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221282 Signed-off-by: Aleksander Pshenitsyn <brains.fatman@gmail.com> Link: https://patch.msgid.link/20260531101159.14241-1-brains.fatman@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
…d streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases. Fixes: 9b1dbd6 ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain") Signed-off-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: new full-speed USB device number 2 using xhci-hcd usb 1-1: New USB device found, idVendor=3c20, idProduct=3d21 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210726905926 Signed-off-by: Lianqin Hu <hulianqin@vivo.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/TYUPR06MB62174610061C213260E1A992D2102@TYUPR06MB6217.apcprd06.prod.outlook.com
The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged. Fixes: 32cb23a ("ALSA: seq: dummy: Allow UMP conversion") Signed-off-by: Kyle Zeng <kylebot@openai.com> Link: https://patch.msgid.link/20260605080204.32045-1-kylebot@openai.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
After commit 0652a3d ("tracing: Fix CFI violation in probestub being called by tprobes"), there are many build errors when building ARCH=arm multi_v7_defconfig + CONFIG_CFI=y like: In file included from drivers/base/devres.c:17: In file included from drivers/base/trace.h:16: In file included from include/linux/tracepoint.h:23: include/linux/cfi.h:44:6: error: call to undeclared function 'get_kernel_nofault'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 44 | if (get_kernel_nofault(hash, func - cfi_get_offset())) | ^ 1 error generated. get_kernel_nofault() is called in the generic version of cfi_get_func_hash() but nothing ensures uaccess.h is always included for a proper expansion and prototype. Include uaccess.h in cfi.h to clear up the errors. Cc: stable@vger.kernel.org Fixes: 0652a3d ("tracing: Fix CFI violation in probestub being called by tprobes") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Lenovo Yoga Air 14 (83QK) laptop keyboard becomes unresponsive after the standard atkbd init sequence. Controlled testing on the actual hardware shows the F5 (ATKBD_CMD_RESET_DIS / deactivate) command specifically corrupts the EC state, causing zero IRQ1 interrupts after init. Skipping only the deactivate command (while keeping F4 ENABLE) resolves the issue completely: both keystroke input and CapsLock LED toggle work correctly. The reverse test - skipping only F4 while keeping F5 - makes the problem worse (zero keystroke interrupts), confirming F5 is the sole culprit. Add a DMI quirk entry for LENOVO/83QK using the existing atkbd_deactivate_fixup callback, consistent with the existing entries for LG Electronics and HONOR FMB-P that address the same EC F5 deactivate issue. Signed-off-by: Zeyu WANG <zeyu.thomas.wang@gmail.com> Link: https://patch.msgid.link/20260602170909.14725-1-zeyu.thomas.wang@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
After commit 9cf6e24 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR BCC-N, aka HONOR MagicBook 14 2026's internal keyboard stops working. Adding the atkbd_deactivate_fixup quirk fixes it. DMI: HONOR BCC-N/BCC-N-PCB, BIOS 1.04 04/07/2026 Fixes: 9cf6e24 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID") Reported-by: Hongfei Ren <lcrhf@outlook.com> Link: colorcube/Linux-on-Honor-Magicbook-14-Pro#1 (comment) Tested-by: Hongfei Ren <lcrhf@outlook.com> Cc: stable@kernel.org Signed-off-by: Cryolitia PukNgae <cryolitia.pukngae@linux.dev> Link: https://patch.msgid.link/20260605-honor-v1-1-78e05e491193@linux.dev Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When build-testing this driver without CONFIG_IRQ_DOMAIN causes
a compile-time error:
drivers/regulator/mt6363-regulator.c: In function 'mt6363_regulator_probe':
drivers/regulator/mt6363-regulator.c:884:18: error: implicit declaration of function 'irq_find_host' [-Wimplicit-function-declaration]
884 | domain = irq_find_host(interrupt_parent);
| ^~~~~~~~~~~~~
drivers/regulator/mt6363-regulator.c:884:16: error: assignment to 'struct irq_domain *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
884 | domain = irq_find_host(interrupt_parent);
| ^
drivers/regulator/mt6363-regulator.c:896:30: error: implicit declaration of function 'irq_create_fwspec_mapping'; did you mean 'irq_create_of_mapping'? [-Wimplicit-function-declaration]
896 | info->virq = irq_create_fwspec_mapping(&fwspec);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| irq_create_of_mapping
This is rather hard to trigger because so many other drivers
enable IRQ_DOMAIN already, but I ran into this on an s390
randconfig build.
Ensure this is always enabled using a Kconfig 'select IRQ_DOMAIN'
entry, as we do for all other users of this.
Fixes: 3c36965 ("regulator: Add support for MediaTek MT6363 SPMI PMIC Regulators")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260526102003.2527570-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
… self-deadlock When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic(). Fixes: 3bfdc63 ("rtmutex: Use waiter::task instead of current in remove_waiter()") Signed-off-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org
syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63 ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb98 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex(). Fixes: 3bfdc63 ("rtmutex: Use waiter::task instead of current in remove_waiter()") Reported-by: syzbot+78147abe6c524f183ee9@syzkaller.appspotmail.com Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/all/69f114ac.050a0220.ac8b.0003.GAE@google.com/ Link: https://patch.msgid.link/20260507112913.1019537-1-dave@stgolabs.net
…ate()
There is an bug in which an uninitialized stack variable is used in
rseq_exit_user_update() as reported by syzbot:
BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline]
The local variable:
struct rseq_ids ids = {
.cpu_id = task_cpu(t),
.mm_cid = task_mm_cid(t),
.node_id = cpu_to_node(ids.cpu_id),
};
According to the C standard, the evaluation order of expressions in an
initializer list is indeterminately sequenced. The compiler (Clang, in
this KMSAN build) evaluates `cpu_to_node(ids.cpu_id)` *before*
`ids.cpu_id` is initialized with `task_cpu(t)`.
This is fixed by moving the assignment of ids.node_id outside the
structure initialization.
Fixes: 82f5724 ("rseq: Implement read only ABI enforcement for optimized RSEQ V2 mode")
Closes: https://syzkaller.appspot.com/bug?extid=185a631927096f9da2fc
Reported-by: syzbot+185a631927096f9da2fc@syzkaller.appspotmail.com
Signed-off-by: Qing Wang <wangqing7171@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://patch.msgid.link/20260602030854.574038-1-wangqing7171@gmail.com
The stub for arch_inlined_clockevent_set_next_coupled() has 'u64 u64 cycles' in its parameter list. Since u64 is a typedef, the compiler parses the second 'u64' as the parameter name, making 'cycles' an unused token. Remove the duplicate so the parameter is correctly named. Fixes: 89f951a ("clockevents: Provide support for clocksource coupled comparators") Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/7tostpvxzdn6tobmyow63a5rweatls5kux3scqp2vzhe7mv6uq@ecr746b4hyhf
The validation check uses '>' instead of '>=' when comparing tv_usec against USEC_PER_SEC, allowing the value 1000000 through. After conversion to nanoseconds (*= 1000), this produces tv_nsec == NSEC_PER_SEC, violating the timespec invariant that tv_nsec must be less than NSEC_PER_SEC. Use '>=' to reject tv_usec values that are not in the valid range of 0 to 999999. Fixes: 5e0fb1b ("y2038: time: avoid timespec usage in settimeofday()") Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/4rikk44zew3s6577dugmx4jyblz7o5c57niuap6ct3td5yfm6w@gh7pcumg7qor
These pointers are only modified once in vdso_setup_data_pages(), during the init phase. Make them read-only after that. Drop __refdata as that would conflict with __ro_after_init. Modpost does accept the reference from a __ro_after_init symbol to an __init one. Fixes: 05988db ("vdso/datastore: Allocate data pages dynamically") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260513-vdso-ro-after-init-v1-1-4b51f74015a4@linutronix.de
tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel. What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely. Fix this by calling timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ] Fixes: 7ee9887 ("timers: Implement the hierarchical pull model") Reported-by: Alon Kariv <alonka@amazon.com> Signed-off-by: Amit Matityahu <amitmat@amazon.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260603170139.33628-1-amitmat@amazon.com
Family 0x1a, models 0xd0 - 0xef are Zen6, so add them to the range which sets X86_FEATURE_ZEN6. [ bp: Massage commit message. ] Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260530061819.9721-1-Pratik.Vishwakarma@amd.com
topology_num_nodes_per_package() reports values greater than one on certain AMD systems resulting in resctrl's Intel model specific SNC detection printing the confusing message: "CoD enabled system? Resctrl not supported" Add a check for Intel systems before looking at the topology. [ reinette: Add Closes tag, fix tag typos, rework changelog ] Fixes: 59674fc ("x86/resctrl: Fix SNC detection") Reported-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Babu Moger <babu.moger@amd.com> Link: https://patch.msgid.link/9849330f45ac86344cc5ac54df2d313906d70bc4.1780634584.git.reinette.chatre@intel.com Closes: https://lore.kernel.org/lkml/37ac0376-43a3-4283-a3d5-4d57b3bec578@amd.com/
Add a new optional `lontium,port-select` property to describe the DSI input port configuration for the LT9611C variant, which supports single-port (A or B) and dual-port (A+B) operation. This property allows explicitly selecting the active DSI input port(s): 0 = port A (default) 1 = port B 2 = ports A and B (dual-port) Link: https://patch.msgid.link/20260611-lt9611-b4-send-v1-1-42abbcd3bb1e@oss.qualcomm.com Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
The on-chip MCU may take longer than 100ms to respond on some hardware variants or slower I2C buses, causing spurious -ETIMEDOUT errors during normal operation. Double the poll timeout from 100ms to 200ms to improve reliability without changing the poll interval. Link: https://patch.msgid.link/20260611-lt9611-b4-send-v1-2-42abbcd3bb1e@oss.qualcomm.com Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Remove two redundant lt9611c_reset() calls: 1. In lt9611c_bridge_atomic_pre_enable(): a reset is already performed during probe and resume; calling it again on every display enable adds ~440ms of unnecessary latency. 2. At the end of lt9611c_probe(): a reset was already performed earlier in probe before lt9611c_lock(). The second reset is redundant. Also, the DRM HDMI bridge framework requires hdmi_write_hdmi_infoframe and hdmi_clear_hdmi_infoframe callbacks for HDMI vendor-specific infoframe (VSI) support, used for features such as HDR metadata signalling. This patch add stub implementations that return success. Wire them into the bridge function table. Also, Store the chip variant enum value in the of_match_table .data field and retrieve it via of_device_get_match_data() when probing from a DT node. Fall back to i2c_device_id.driver_data for non-DT (e.g. ACPI) probe paths. This is the standard kernel pattern for passing per-compatible data through the OF match table, and avoids relying solely on the I2C device ID table for chip type detection when DT is available. Populate bridge.vendor and bridge.product so the DRM HDMI framework can report the correct manufacturer and product name in the HDMI connector properties (visible via xrandr --prop and related sysfs entries). Link: https://patch.msgid.link/20260611-lt9611-b4-send-v1-3-42abbcd3bb1e@oss.qualcomm.com Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Some board designs connect only DSI port B, or both DSI ports A and B, to the LT9611C. Add support for a 'lontium,port-select' DT property that allows the board DTS to specify which DSI port(s) the chip should use: 0 = PORT_SELECT_A (default, single DSI port A) 1 = PORT_SELECT_B (single DSI port B) 2 = PORT_SELECT_AB (dual DSI ports A+B) When the property is absent the driver defaults to PORT_SELECT_A (0), preserving backward compatibility with existing DTS files. The selected port is programmed into the chip via lt9611c_select_port() during probe, after the chip ID has been verified. Link: https://patch.msgid.link/20260611-lt9611-b4-send-v1-4-42abbcd3bb1e@oss.qualcomm.com Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Patches for improvements and fixes in lt9611c driver