summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-03-16wifi: rtl8xxxu: fix potential use of uninitialized valueYi Cong1-20/+8
The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper function encounters an unhandled rate index, it may return without setting these values, leading to the use of uninitialized stack data. Remove the helper rtl8xxxu_desc_to_mcsrate() and inline the logic into rtl8xxxu_update_ra_report(). This fixes the use of uninitialized 'mcs' and 'nss' variables for legacy rates. The new implementation explicitly handles: - Legacy rates: Set bitrate only. - HT rates (MCS0-15): Set MCS flags, index, and NSS (1 or 2) directly. - Invalid rates: Return early. Fixes: 7de16123d9e2 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report") Cc: stable@vger.kernel.org Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yi Cong <yicong@kylinos.cn> Link: https://lore.kernel.org/all/96e31963da0c42dcb52ce44f818963d7@realtek.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260306071627.56501-1-cong.yi@linux.dev
2026-03-16wifi: rtl8xxxu: Mark RTL8188ETV (0bda:0179) as testedJ. Neuschäfer1-0/+1
This WiFi chip appears in the "TCU Fernsehfee 3.0" set-top box. I have tested that it works in WPA2-PSK-CCMP client mode. Cc: Jes.Sorensen@gmail.com Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260303-rtl8xxx-tested-v1-1-291a38a6ff2f@posteo.net
2026-03-16drm/atomic: Add affected colorops with affected planesChaitanya Kumar Borah1-0/+7
When drm_atomic_add_affected_planes() adds a plane to the atomic state, the associated colorops are not guaranteed to be included. This can leave colorop state out of the transaction when planes are pulled in implicitly (eg. during modeset or internal commits). Also add affected colorops when adding affected planes to keep plane and color pipeline state consistent within the atomic transaction. v2: Add affected colorops only when a pipeline is enabled Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Cc: <stable@vger.kernel.org> #v6.19+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260310113238.3495981-3-chaitanya.kumar.borah@intel.com
2026-03-16drm/colorop: Preserve bypass value in duplicate_state()Chaitanya Kumar Borah1-2/+0
__drm_atomic_helper_colorop_duplicate_state() unconditionally sets state->bypass = true after copying the existing state. This override causes the new atomic state to no longer reflect the currently committed hardware state. Since the bypass property directly controls whether the colorop is active in hardware, resetting it to true can inadvertently disable an active colorop during a subsequent commit, particularly for internal driver commits where userspace does not touch the property. Drop the unconditional assignment and preserve the duplicated bypass value. Fixes: 8c5ea1745f4c ("drm/colorop: Add BYPASS property") Cc: <stable@vger.kernel.org> #v6.19+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260310113238.3495981-2-chaitanya.kumar.borah@intel.com
2026-03-16soc: qcom: socinfo: add SoC ID for IPQ5210 familyKathiravan Thirumoorthy1-0/+5
SoCs based on IPQ5210 is shipped under two different naming schemes namely IPQ52xx and QCF2xxx/QCF3xxx. In the later variants Passive Optical Network (PON) interface acts as the backhaul where as in the former it is ethernet backhaul. Add the SoC IDs for the same. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260313-b4-ipq5210_soc_ids-v1-2-97faae3fef95@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16Merge tag 'drm-xe-next-2026-03-12' of ↵Dave Airlie54-257/+2100
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - add VM_BIND DECOMPRESS support and on-demand decompression (Nitin) - Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13 (Lionel) Cross-subsystem Changes: - Introduce the DRM RAS infrastructure over generic netlink (Riana, Rodrigo) Core Changes: - Two-pass MMU interval notifiers (Thomas) Driver Changes: - Merge drm/drm-next into drm-xe-next (Brost) - Fix overflow in guc_ct_snapshot_capture (Mika, Fixes) - Extract gt_pta_entry (Gustavo) - Extra enabling patches for NVL-P (Gustavo) - Add Wa_14026578760 (Varun) - Add type-specific GT loop iterator (Roper) - Refactor xe_migrate_prepare_vm (Raag) - Don't disable GuCRC in suspend path (Vinay, Fixes) - Add missing kernel docs in xe_exec_queue.c (Niranjana) - Change TEST_VRAM to work with 32-bit resource_size_t (Wajdeczko) - Fix memory leak in xe_vm_madvise_ioctl (Varun, Fixes) - Skip access counter queue init for unsupported platforms (Himal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/abLUVfSHu8EHRF9q@lstrano-desk.jf.intel.com
2026-03-16remoteproc: sysmon: Use the unified QMI service ID instead of defining it ↵Daniel Lezcano1-1/+1
locally Instead of defining a local macro with a custom name for the QMI service identifier, use the one provided in qmi.h and remove the locally defined macro. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260309230346.3584252-5-daniel.lezcano@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: pdr: Use the unified QMI service ID instead of defining it locallyDaniel Lezcano3-6/+3
Instead of defining a local macro with a custom name for the QMI service identifier, use the one provided in qmi.h and remove the locally defined macro. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260309230346.3584252-7-daniel.lezcano@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: pmic_glink_altmode: Fix SVID=DP && unconnected edge caseKonrad Dybcio1-7/+11
The commit referenced in Fixes started evaluating the value of alt_port->mux_ctrl before checking the active SVID. This led to drm_aux_hpd_bridge_notify() no longer being called for the 'DP unplug' case. Perhaps somewhat interestingly, the firmware sends a notification with SVID=DP, mux_ctrl=MUX_CTRL_STATE_NO_CONN and pin_assignment=0 on unplug. 'pin_assignment' was previously interpreted as a bitfield excerpt from the second byte of the DP pg_altmode payload (and stored as an u8). That value is used in pmic_glink_altmode_sc8280xp_notify(), decremented by 1 (DPAM_HPD_A). Previously, this would result in an u8 underflow that would rollover to 0xff (which prior to the Fixes patch would have caused a pmic_glink_altmode_safe() and 'disconnected' bridge notification). That check was removed, without a replacement. Resolve this issue by making sure the SID=DP && mux_ctrl=NO_CONN combo once again results in a HPD bridge notification. Fixes: 0539c5a6fdef ("soc: qcom: pmic_glink_altmode: Consume TBT3/USB4 mode notifications") Reported-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Tested-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260306-topic-pgaltmode_fixup-v1-1-ec154b2d8e89@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_eiMukesh Ojha2-2/+2
It looks element length declared in servreg_loc_pfr_req_ei for reason not matching servreg_loc_pfr_req's reason field due which we could observe decoding error on PD crash. qmi_decode_string_elem: String len 81 >= Max Len 65 Fix this by matching with servreg_loc_pfr_req's reason field. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20260129152320.3658053-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: llcc: Use guards for mutex handlingUnnathi Chalicheemala1-20/+8
Replacing manual lock/unlock pairs with guard() removes the need to think about unlocking entirely and keeps the function trivially structured. Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-external_llcc_changes1set-v1-2-6347e52e648e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: llcc: Add per-slice counter and common llcc slice descriptorUnnathi Chalicheemala1-29/+28
Fix incorrect slice activation/deactivation accounting by replacing the bitmap-based activation tracking with per-slice atomic reference counters. This resolves mismatches that occur when multiple client drivers vote for the same slice or when llcc_slice_getd() is called multiple times. As part of this fix, simplify slice descriptor handling by eliminating dynamic allocation. llcc_slice_getd() now returns a pointer to a preallocated descriptor, removing the need for repeated allocation/free cycles and ensuring consistent reference tracking across all users. Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-external_llcc_changes1set-v1-1-6347e52e648e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: socinfo: Add SoC IDs for SM7450 and SM7450PAelin Reidel1-0/+2
SM7450 and SM7450P are two SoCs in the 'fillmore' family. Signed-off-by: Aelin Reidel <aelin@mainlining.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260302-fillmore-socids-v2-2-e6c5ad167ec4@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: pd-mapper: Simplify code using of_root to get root device tree nodeVladimir Zapolskiy1-7/+1
A few lines of code are removed by using the global non-NULL of_root pointer to access the root device tree node instead of its recalculation. Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224110213.3929063-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: llcc: Add configuration data for SDM670Richard Acayan1-0/+105
Add system cache table and configs for the SDM670 SoC. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260210021957.13357-3-mailingradian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: smp2p: Add support for smp2p v2Chris Lew1-4/+44
smp2p v2 adds support for allowing remote processors to write outbound smp2p items without completing the feature negotiation. This is required for processors that start before linux to write out signals like error and clock ready and unblock their bootup. If a remote processor only supports v1, smp2p can version down by mirroring the peer version during the negotiation stage. When using smp2p version 2, the remote does not wait for the ssr ack before setting the items. To accommodate this, set the last_value of all the entries to 0 when SSR is detected. This forces smp2p to detect the new values written by the remote. Because the SSR ack is skipped, the down transition of bits is missed in smp2p version 2. Signed-off-by: Chris Lew <chris.lew@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-smp2pv2-v3-2-4060b859b1e2@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: smp2p: Add irqchip state supportChris Lew1-0/+55
A remoteproc booted during earlier boot stages such as UEFI or the bootloader, may need to be attached to without restarting the remoteproc hardware. To do this the remoteproc will need to check the ready and handover states in smp2p without an interrupt notification. Create qcom_smp2p_start_in() to initialize the shadow state without notifying clients because these early events happened in the past. Add support for the .irq_get_irqchip_state callback so remoteproc can read the current state of the fatal, ready and handover bits. Signed-off-by: Chris Lew <chris.lew@oss.qualcomm.com> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127-smp2pv2-v3-1-4060b859b1e2@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16spi: amlogic-spisg: Use IS_ERR() instead of IS_ERR_OR_NULL()Felix Gu1-3/+3
devm_clk_get_enabled() and devm_clk_hw_get_clk() return error pointers on failure and never return NULL. So IS_ERR_OR_NULL() is unnecessary, replace them with IS_ERR(). Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260308-spisg-1-v1-1-4e209faf228d@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ASoC: amd: Move to GPIO descriptorsMark Brown206-1385/+2080
Linus Walleij <linusw@kernel.org> says: After a quick look and test-compile I can determine that all of these drivers include <linux/gpio.h> for no reason whatsoever, so fixing it is low hanging fruit. Link: https://patch.msgid.link/20260314-asoc-amd-v1-0-31afed06e022@kernel.org
2026-03-16spi: axiado: Fix double-free in ax_spi_probe()Felix Gu1-20/+11
ctlr is allocated using devm_spi_alloc_host(), which automatically handles reference counting via the devm framework. Calling spi_controller_put() manually in the probe error path is redundant and results in a double-free. Fixes: e75a6b00ad79 ("spi: axiado: Add driver for Axiado SPI DB controller") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260302-axiado-v1-1-1132819f1cb7@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16spi: amlogic-spisg: Fix memory leak in aml_spisg_probe()Felix Gu1-8/+4
In aml_spisg_probe(), ctlr is allocated by spi_alloc_target()/spi_alloc_host(), but fails to call spi_controller_put() in several error paths. This leads to a memory leak whenever the driver fails to probe after the initial allocation. Convert to use devm_spi_alloc_host()/devm_spi_alloc_target() to fix the memory leak. Fixes: cef9991e04ae ("spi: Add Amlogic SPISG driver") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260308-spisg-v1-1-2cace5cafc24@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16spi: amlogic: spifc-a4: Remove redundant clock cleanupFelix Gu1-39/+7
The driver uses devm_clk_get_enabled() which enables the clock and registers a callback to automatically disable it when the device is unbound. Remove the redundant aml_sfc_disable_clk() call in the error paths and remove callback. Fixes: 4670db6f32e9 ("spi: amlogic: add driver for Amlogic SPI Flash Controller") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260308-spifc-a4-1-v1-1-77e286c26832@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16Merge tag 'drm-intel-gt-next-2026-03-12' of ↵Dave Airlie7-29/+69
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: Fixes/improvements/new stuff: - Fix potential overflow of shmem scatterlist length (Janusz Krzysztofik) Miscellaneous: - Keep mock file open during unfaultable migrate with fill [selftests] (Krzysztof Karas) - Test for imported buffers with drm_gem_is_imported() (Thomas Zimmermann) - Fix corrupted copyright symbols in selftest files [guc] (Konstantin Khorenko) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patch.msgid.link/abKBHNFsBQCv2h3e@linux
2026-03-16Merge tag 'v7.0-rc4' into drm-rust-nextDanilo Krummrich513-3019/+5439
We need the latest fixes from drm-rust-fixes in drm-rust-next as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-15Merge tag 'scsi-fixes' of ↵Linus Torvalds5-11/+5
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "The one core change is a re-roll of the tag allocation fix from the last pull request that uses the correct goto to unroll all the allocations. The remianing fixes are all small ones in drivers" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: hisi_sas: Fix NULL pointer exception during user_scan() scsi: qla2xxx: Completely fix fcport double free scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend scsi: core: Fix error handling for scsi_alloc_sdev()
2026-03-15Merge tag 'irq-urgent-2026-03-15' of ↵Linus Torvalds1-4/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Ingo Molnar: "Two fixes for the riscv-aplic irqchip driver: - Fix probing dependency bug on probing failure - Fix double register_syscore() bug" * tag 'irq-urgent-2026-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/riscv-aplic: Register syscore operations only once irqchip/riscv-aplic: Do not clear ACPI dependencies on probe failure
2026-03-15md/md-llbitmap: raise barrier before state machine transitionYu Kuai1-4/+4
Move the barrier raise operation before calling llbitmap_state_machine() in both llbitmap_start_write() and llbitmap_start_discard(). This ensures the barrier is in place before any state transitions occur, preventing potential race conditions where the state machine could complete before the barrier is properly raised. Cc: stable@vger.kernel.org Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/20260223024038.3084853-3-yukuai@fnnas.com Signed-off-by: Yu Kuai <yukuai@fnnas.com>
2026-03-15md/md-llbitmap: skip reading rdevs that are not in_syncYu Kuai1-1/+2
When reading bitmap pages from member disks, the code iterates through all rdevs and attempts to read from the first available one. However, it only checks for raid_disk assignment and Faulty flag, missing the In_sync flag check. This can cause bitmap data to be read from spare disks that are still being rebuilt and don't have valid bitmap information yet. Reading stale or uninitialized bitmap data from such disks can lead to incorrect dirty bit tracking, potentially causing data corruption during recovery or normal operation. Add the In_sync flag check to ensure bitmap pages are only read from fully synchronized member disks that have valid bitmap data. Cc: stable@vger.kernel.org Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Link: https://lore.kernel.org/linux-raid/20260223024038.3084853-2-yukuai@fnnas.com Signed-off-by: Yu Kuai <yukuai@fnnas.com>
2026-03-15md/raid5: set chunk_sectors to enable full stripe I/O splittingYu Kuai1-0/+1
Set chunk_sectors to the full stripe width (io_opt) so that the block layer splits I/O at full stripe boundaries. This ensures that large writes are aligned to full stripes, avoiding the read-modify-write overhead that occurs with partial stripe writes in RAID-5/6. When chunk_sectors is set, the block layer's bio splitting logic in get_max_io_size() uses blk_boundary_sectors_left() to limit I/O size to the boundary. This naturally aligns split bios to full stripe boundaries, enabling more efficient full stripe writes. Test results with 24-disk RAID5 (chunk_size=64k): dd if=/dev/zero of=/dev/md0 bs=10M oflag=direct Before: 461 MB/s After: 520 MB/s (+12.8%) Link: https://lore.kernel.org/linux-raid/20260223035834.3132498-1-yukuai@fnnas.com Suggested-by: Christoph Hellwig <hch@infradead.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Yu Kuai <yukuai@fnnas.com>
2026-03-15md/raid10: fix deadlock with check operation and nowait requestsJosh Hunt1-2/+2
When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") Cc: stable@vger.kernel.org Signed-off-by: Josh Hunt <johunt@akamai.com> Link: https://lore.kernel.org/linux-raid/20260303005619.1352958-1-johunt@akamai.com Signed-off-by: Yu Kuai <yukuai@fnnas.com>
2026-03-15md: suppress spurious superblock update error message for dm-raidChen Cheng1-1/+3
dm-raid has external metadata management (mddev->external = 1) and no persistent superblock (mddev->persistent = 0). For these arrays, there's no superblock to update, so the error message is spurious. The error appears as: md_update_sb: can't update sb for read-only array md0 Fixes: 8c9e376b9d1a ("md: warn about updating super block failure") Reported-by: Tj <tj.iam.tj@proton.me> Closes: https://lore.kernel.org/all/20260128082430.96788-1-tj.iam.tj@proton.me/ Signed-off-by: Chen Cheng <chencheng@fnnas.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/linux-raid/20260210133847.269986-1-chencheng@fnnas.com Signed-off-by: Yu Kuai <yukuai@fnnas.com>
2026-03-15misc: pci_endpoint_test: Give reserved BARs a distinct error codeNiklas Cassel1-2/+18
Give reserved BARs a distinct error code, such that the pci_endpoint_test selftest will be able to skip test cases that are run against reserved BARs. Signed-off-by: Niklas Cassel <cassel@kernel.org> [mani: Used __fls(CAP_BAR0_RESERVED) instead of PCI_ENDPOINT_CAP_BAR0_RESERVED_BIT] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-21-cassel@kernel.org
2026-03-15PCI: endpoint: pci-epf-test: Advertise reserved BARsNiklas Cassel1-0/+24
Advertise reserved BARs as reserved in the Capabilities register, such that the host side driver will be able to skip reserved BARs. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-20-cassel@kernel.org
2026-03-15PCI: dwc: Disable BARs in common code instead of in each glue driverNiklas Cassel12-89/+25
The current EPC core design relies on an EPC driver disabling all BARs by default. An EPF driver will then enable the BARs that it wants to enabled. This design is there because there is no epc->ops->disable_bar(). (There is a epc->ops->clear_bar(), but that is only to disable a BAR that has been enabled using epc->ops->set_bar() first.) By default, an EPF driver will not be able to get/enable BARs that are marked as BAR_RESERVED or BAR_DISABLED (see pci_epc_get_next_free_bar()). Since the current EPC code design requires an EPC driver to disable all BARs by default, move this to DWC common code from each glue driver. BAR_RESERVED BARs are not disabled by default because these BARs are hardware backed, and should only be disabled explicitly by an EPF driver if absolutely necessary for the EPF driver to function correctly. (This is similar to how e.g. NVMe may have vendor specific BARs outside of the mandatory BAR0 which contains the NVMe registers.) Note that there is currently no EPC operation to disable a BAR that has not first been programmed using pci_epc_set_bar(). If an EPF driver ever wants to disable a BAR marked as BAR_RESERVED, a disable_bar() operation would have to be added first. No functional changes intended. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-19-cassel@kernel.org
2026-03-15PCI: dwc: Replace certain BAR_RESERVED with BAR_DISABLED in glue driversNiklas Cassel5-15/+27
Most DWC based EPC glue drivers that have BARs marked as BAR_RESERVED in epc_features also call dw_pcie_ep_reset_bar() for these reserved BARs in ep->ops->init(). (The only exception is pci-keystone.c.) An EPF driver will be able to get/enable BARs that have been disabled/reset using dw_pcie_ep_reset_bar(), except if the BAR is marked as BAR_RESERVED (see pci_epc_get_next_free_bar()). Thus, all EPC drivers that have BARs marked as BAR_RESERVED in epc_features and call dw_pcie_ep_reset_bar(), should really have these BARs marked as BAR_DISABLED. If dw_pcie_ep_reset_bar() is not called by the glue driver, the BARs are kept as BAR_RESERVED. No EPC drivers outside drivers/pci/controllers/dwc mark their BARs as BAR_RESERVED, so there is nothing to do in non-DWC based EPC drivers. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-18-cassel@kernel.org
2026-03-15PCI: endpoint: Introduce pci_epc_bar_type BAR_DISABLEDNiklas Cassel1-2/+3
Add a pci_epc_bar_type BAR_DISABLED to more clearly differentiate from BAR_RESERVED. This BAR type will only be used to describe a BAR that the EPC driver should disable, and will thus never be available to an EPF driver. (Unlike BAR_RESERVED, which will never be disabled by default by an EPC driver.) Co-developed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Link: https://patch.msgid.link/20260312130229.2282001-17-cassel@kernel.org
2026-03-15PCI: dw-rockchip: Describe RK3588 BAR4 DMA ctrl windowKoichiro Den1-1/+14
On RK3588 PCIe3_4L in EP mode, the integrated DMA controller registers are permanently mapped to BAR4 and must not be repurposed by EPF drivers. When the remote peer needs to access these registers, it must use the fixed BAR4 window instead of creating another inbound mapping in a different BAR. Mixing the fixed window with an additional mapping can lead to incorrect behavior. Advertise the DMA controller MMIO window as a reserved BAR subregion so EPF drivers can reuse it safely. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-16-cassel@kernel.org
2026-03-15PCI: endpoint: Do not mark the BAR succeeding a 64-bit BAR as BAR_RESERVEDNiklas Cassel6-16/+0
A BAR that can only be configured as a 64-bit BAR by an EPC driver is marked as such using the "only_64bit" flag. Currently, the documentation says that an EPC driver should explicitly mark the BAR succeeding an "only_64bit" BAR as BAR_RESERVED. However, a 64-bit BAR will always take up two BARs. It is thus redundant to mark both BARs. pci_epc_get_next_free_bar() already skips the BAR succeeding a "only_64bit" BAR, regardless if the succeeding BAR is marked as BAR_RESERVED or not. Thus, drop the BAR_RESERVED for a BAR succeeding a "only_64bit" BAR. No functional changes. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260312130229.2282001-13-cassel@kernel.org
2026-03-15PCI: rzg3s-host: Add support for RZ/G3E PCIe controllerJohn Madieu1-0/+93
Add support for the PCIe controller found in RZ/G3E SoCs to the existing RZ/G3S PCIe host controller driver. The RZ/G3E PCIe controller is similar to the RZ/G3S, with the following key differences: - Supports PCIe Gen3 (8.0 GT/s) link speeds alongside Gen2 (5.0 GT/s) - Uses a different reset control mechanism via AXI registers instead of the Linux reset framework - Requires specific SYSC configuration for link state control and Root Complex mode selection Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> [mani: added a readl_relaxed() before fsleep() to flush previous write] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-13-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Add PCIe Gen3 (8.0 GT/s) link speed supportJohn Madieu1-6/+20
Extend the link speed configuration to support Gen3 (8.0 GT/s) in addition to Gen2 (5.0 GT/s). This is required for RZ/G3E PCIe host support, which is Gen3 capable. Instead of relying on DT max-link-speed for configuration, read the hardware capabilities from the PCI_EXP_LNKCAP register to determine the maximum supported speed. The DT max-link-speed property is now only used as an optional limit when explicitly specified, which aligns with PCIe subsystem expectations. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-12-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Explicitly set class code for RZ/G3E compatibilityJohn Madieu1-0/+8
Program the class code register explicitly during PCIe configuration initialization. RZ/G3E requires this register to be set, while RZ/G3S has these values as hardware defaults. This configuration is harmless for RZ/G3S where these match the hardware defaults, and necessary for RZ/G3E to properly identify the device as a PCI bridge. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-11-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Add SoC-specific configuration and initialization callbacksJohn Madieu1-17/+44
Add optional cfg_pre_init, cfg_post_init, and cfg_deinit callbacks to handle SoC-specific configuration methods. While RZ/G3S uses the Linux reset framework with dedicated reset lines, other SoC variants like RZ/G3E control configuration resets through PCIe AXI registers. As Linux reset bulk API gracefully handles optional NULL reset lines (num_cfg_resets = 0 for RZ/G3E), the driver continues to use the standard reset framework when reset lines are available, while custom callbacks are only invoked when provided. This provides a balanced pattern where: - RZ/G3S: Uses callbacks that fall back to the reset framework - RZ/G3E: Sets num_cfg_resets=0, provides cfg_pre_init/cfg_post_init/cfg_deinit Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-10-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Make configuration reset lines optionalJohn Madieu1-3/+3
Some SoC variants such as RZ/G3E handle configuration reset control through PCIe AXI registers instead of dedicated reset lines. Make cfg_resets optional by using devm_reset_control_bulk_get_optional_exclusive() to allow SoCs to use alternative or complementary reset control mechanisms. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-9-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Make SYSC register offsets SoC-specificJohn Madieu1-26/+85
In preparation for adding RZ/G3E support, move the RST_RSM_B register offset and mask into a SoC-specific data structure. Compared with RZ/G3S, the RZ/G3E SYSC controls different functionalities for the PCIe controller. Make SYSC operations conditional on the presence of register offset information, allowing the driver to handle SoCs that don't use the RST_RSM_B signal. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-8-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Rework inbound window algorithm for supporting RZ/G3E SoCJohn Madieu1-24/+29
The existing inbound window configuration algorithm has two issues that prevent proper operation on RZ/G3E: 1. Over-mapping: Using roundup_pow_of_two() on the remaining region size can result in windows that extend beyond the intended memory region. 2. Alignment violation: Addresses are only aligned to 4K regardless of the actual window size. According to the RZ/G3S HW manual (Rev.1.10, section 34.6.6.7) and RZ/G3E HW manual (Rev.1.15, section 6.6.7.6), bit carry must not occur when adding AXI Window Base and AXI Window Mask registers. This effectively requires the base address to be aligned to the window size. RZ/G3E strictly enforces these constraints and requires precise window boundaries with properly aligned addresses. Rework the algorithm to properly handle arbitrary region sizes and alignment constraints by splitting non-power-of-2 regions into multiple windows. The new approach iteratively selects the largest power-of-2 size that: - Fits within the remaining region (__fls of remaining size) - Does not exceed the natural alignment of the CPU address (__ffs) - Does not exceed the natural alignment of the PCI address (__ffs) This ensures windows never over-map beyond the intended region and satisfies the hardware requirement that base address + mask must not cause bit carry, while maintaining the 4K * 2^N byte window size constraint. The reworked algorithm is required for RZ/G3E support and remains fully compatible with RZ/G3S. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-4-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Reorder reset assertion during suspendJohn Madieu1-9/+9
Reorder the reset assertion sequence during suspend from power_resets -> cfg_resets to cfg_resets -> power_resets. This change ensures the suspend sequence follows the reverse order of the probe/init sequence, where power_resets are deasserted first followed by cfg_resets. Additionally, this ordering is required for RZ/G3E support where cfg resets are controlled through PCIe AXI registers (offset 0x310h). According to the RZ/G3E hardware manual (Rev.1.15, section 6.6.6.1.1 "Changing the Initial Values of the Registers"), AXI register access requires ARESETn to be de-asserted and the clock to be supplied. Since ARESETn is part of power_resets, cfg_resets must be asserted before power_resets, otherwise the AXI registers become inaccessible. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-3-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Fix reset handling in probe error pathJohn Madieu1-2/+1
Fix incorrect reset_control_bulk_deassert() call in the probe error path. When unwinding from a failed pci_host_probe(), the configuration resets should be asserted to restore the hardware to its initial state, not deasserted again. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-2-john.madieu.xa@bp.renesas.com
2026-03-15iio: adc: mt6359-auxadc: Fix comma spacingGiorgi Tchankvetadze1-1/+1
Fix incorrect whitespace around comma on line 325 to comply with kernel coding style. This silences checkpatch errors "ERROR: space prohibited before that ','" and "ERROR: space required after that ','". No functional change. Signed-off-by: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-15iio: dac: mcp47feb02: Fix Vref validation [1-999] caseAriana Lazar1-27/+22
Store reference voltages in uV instead of mV to avoid invalid error code in dev_err_probe() call. Vref variables store the actual value returned by devm_regulator_get_enable_read_voltage() function instead of the results of dividing it by MILLI. The corner case [1-999] divided by MILLI of the voltage reference variable value would become 0 is covered too. Fixes: bf394cc80369 ("iio: dac: adding support for Microchip MCP47FEB02") Link: https://lore.kernel.org/all/aYXvP5FLA5BvkoVX@stanley.mountain/ Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-15iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()Josh Poimboeuf1-10/+5
If 'pin' is not one of its expected values, the value of 'int_out_ctrl_shift' is undefined. With UBSAN enabled, this causes Clang to generate undefined behavior, resulting in the following warning: drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume() Prevent the UB and improve error handling by returning an error if 'pin' has an unexpected value. While at it, simplify the code a bit by moving the 'pin_name' assignment to the first switch statement. Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support") Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-07 01:52:55 +0300