summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-10-17tools: docs: parse_data_structs.py: drop contents headerMauro Carvalho Chehab
When used in practice, one may want to have multiple header files on a single rst file, like: *********************** Digital TV uAPI symbols *********************** .. contents:: Table of Contents :depth: 2 :local: Frontend ======== .. kernel-include:: include/uapi/linux/dvb/frontend.h :generate-cross-refs: :toc: Demux ===== .. kernel-include:: include/uapi/linux/dvb/dmx.h :generate-cross-refs: :toc: ... So, don't add ..contents:: here. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <4bf353e5248133a3b0abd82519a38453402fe7c6.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17drm/i915/dp: Fix panel replay when DSC is enabledImre Deak
Prevent enabling panel replay if the sink doesn't support this due to DSC being enabled. Panel replay has two modes, updating full frames or only selected regions of the frame. If the sink doesn't support Panel Replay in full frame update mode with DSC prevent Panel Replay completely if DSC is enabled. If the sink doesn't support Panel Replay only in the selective update mode while DSC is enabled, it will still support Panel Replay in the full frame update mode, so only prevent selective updates in this case. v2: - Use Panel Replay instead of PR in debug prints. (Jouni) - Rebase on change tracking the link DSC state in the crtc state. Cc: Jouni Högander <jouni.hogander@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the linkImre Deak
The state of all the CRTCs on an MST link must be recomputed, if DSC gets enabled on any of the CRTCs on the link. For instance an MST docking station's Panel Replay capability may depend on whether DSC is enabled on any of the dock's streams (aka CRTCs). To assist the Panel Replay state computation for a CRTC based on the above, track in the CRTC state if DSC is enabled on any CRTC on an MST link. The intel_link_bw_limits::force_fec_pipes mask is used for a reason similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST link if DSC is enabled on any of the link's CRTCs. The FEC enabled state for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is always enabled by the HW for UHBR, hence it's not tracked by the intel_crtc_state::fec_enable flag for such links, where this flag is always false). Based on the above, to be able to determine the DSC state on both non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link state (instead of the FEC-enabled-on-link state) for each CRTC in intel_link_bw_limits. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Track DSC enabled status on the MST linkImre Deak
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI) this will always match the CRTC's DSC state, those links having only a single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will be as follows: CRTC#0: - compression_enable = true - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b CRTC#1: - compression_enable = false - compression_enabled_on_link = true - fec_enable = true for 8b10b, false for 128b132b This patch only sets compression_enabled_on_link for CRTC#0 above and enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b MST link. A follow-up change will make sure that the state of all the CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on any CRTC, setting compression_enabled_on_link and fec_enable for these. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC configImre Deak
Reuse the DP-SST helper to compute the state for the FEC enabled state for DP-MST as well. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17drm/i915/dp: Export helper to determine if FEC on non-UHBR links is requiredImre Deak
Export the helper function to determine if FEC is required on a non-UHBR (8b10b) SST or MST link. A follow up change will take this into use for MST as well. While at it determine the output type from the CRTC state, which allows dropping the intel_dp argument. Also make the function return the required FEC state, instead of setting this in the CRTC state, which allows only querying this requirement, without changing the state. Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that the function determines if FEC is required on an 8b10b link (on 128b132b links FEC is always enabled by the HW implicitly, so the function will return false for that case). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17drm/i915/dp: Ensure the FEC state stays disabled for UHBR linksImre Deak
Atm, in the DP SST case the FEC state is computed before intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr() will always return false and the FEC state will be always computed assuming a non-UHBR link. This happens to work, since the FEC state is recomputed later in intel_dp_mtp_tu_compute_config(), where port_clock will be set already, so intel_crtc_state::fec_enable will be reset as expected for UHBR. This also depends on link rates being tried in an increasing order (i.e. from non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus intel_crtc_state::fec_enable being set for the non-UHBR rates and getting reset for the first UHBR rate as expected. A follow-up change will reuse intel_dp_fec_compute_config() for the DP MST state computation, prepare for that here, making sure that the function determines the correct intel_crtc_state::fec_enable=false state for UHBR link rates based on the above. The DP SST and MST state computation should be further unified to avoid computing/setting the intel_crtc_state::fec_enable state multiple times, but that's left for a follow-up change. For now add only code comments about this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17drm/i915/dsc: Add helper to enable the DSC configuration for a CRTCImre Deak
Add a helper to enable the DSC compression configuration for a CRTC. Follow-up changes will introduce tracking for the same DSC state on the whole link, which will need to be set whenever DSC is enabled for the CRTC. Also, according to the above, when querying the DSC state on the link, both the CRTC's and the link's DSC state must be considered. Setting the DSC configuration for a CRTC and querying the DSC configuration for the link (added by follow-up changes) is better done via helper functions based on the above, prepare for that here. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17selftests/bpf: Fix redefinition of 'off' as different kind of symbolBrahmajit Das
This fixes the following build error CLNG-BPF [test_progs] verifier_global_ptr_args.bpf.o progs/verifier_global_ptr_args.c:228:5: error: redefinition of 'off' as different kind of symbol 228 | u32 off; | ^ The symbol 'off' was previously defined in tools/testing/selftests/bpf/tools/include/vmlinux.h, which includes an enum i40e_ptp_gpio_pin_state from drivers/net/ethernet/intel/i40e/i40e_ptp.c: enum i40e_ptp_gpio_pin_state { end = -2, invalid = -1, off = 0, in_A = 1, in_B = 2, out_A = 3, out_B = 4, }; This enum is included when CONFIG_I40E is enabled. As of commit 032676ff8217 ("LoongArch: Update Loongson-3 default config file"), CONFIG_I40E is set in the defconfig, which leads to the conflict. Renaming the local variable avoids the redefinition and allows the build to succeed. Suggested-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Brahmajit Das <listout@listout.xyz> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20251017171551.53142-1-listout@listout.xyz Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-10-17riscv: dts: thead: add zfh for th1520Han Gao
th1520 support Zfh ISA extension. It supports the same RISC-V extensions as SG2042. commit cb074bed1186 ("riscv: dts: sophgo: add zfh for sg2042") Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17riscv: dts: thead: add ziccrse for th1520Han Gao
Existing rv64 hardware conforms to the rva20 profile. Ziccrse is an additional extension required by the rva20 profile, so th1520 has this extension. Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17riscv: dts: thead: add xtheadvector to the th1520 devicetreeHan Gao
The th1520 support xtheadvector [1] so it can be included in the devicetree. Also include vlenb for the cpu. And set vlenb=16 [2]. This can be tested by passing the "mitigations=off" kernel parameter. Link: https://lore.kernel.org/linux-riscv/20241113-xtheadvector-v11-4-236c22791ef9@rivosinc.com/ [1] Link: https://lore.kernel.org/linux-riscv/aCO44SAoS2kIP61r@ghost/ [2] Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17bpf: Do not disable preemption in bpf_test_run().Sahil Chandna
The timer mode is initialized to NO_PREEMPT mode by default, this disables preemption and force execution in atomic context causing issue on PREEMPT_RT configurations when invoking spin_lock_bh(), leading to the following warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6107, name: syz.0.17 preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 Preemption disabled at: [<ffffffff891fce58>] bpf_test_timer_enter+0xf8/0x140 net/bpf/test_run.c:42 Fix this, by removing NO_PREEMPT/NO_MIGRATE mode check. Also, the test timer context no longer needs explicit calls to migrate_disable()/migrate_enable() with rcu_read_lock()/rcu_read_unlock(). Use helpers rcu_read_lock_dont_migrate() and rcu_read_unlock_migrate() instead. Reported-by: syzbot+1f1fbecb9413cdbfbef8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1f1fbecb9413cdbfbef8 Suggested-by: Yonghong Song <yonghong.song@linux.dev> Suggested-by: Menglong Dong <menglong.dong@linux.dev> Acked-by: Yonghong Song <yonghong.song@linux.dev> Tested-by: syzbot+1f1fbecb9413cdbfbef8@syzkaller.appspotmail.com Co-developed-by: Brahmajit Das <listout@listout.xyz> Signed-off-by: Brahmajit Das <listout@listout.xyz> Signed-off-by: Sahil Chandna <chandna.sahil@gmail.com> Link: https://lore.kernel.org/r/20251014185635.10300-1-chandna.sahil@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-10-17spi: airoha: driver fixes & improvementsMark Brown
Merge series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>: This patch series greatly improve airoha snfi driver and fix a number of serious bugs. Fixed bugs: * Fix reading/writing of flashes with more than one plane per lun * Fill the buffer with 0xff before writing * Fix reading of flashes supporting continuous reading mode * Fix error paths Improvements: * Add support of dual/quad wires spi modes in exec_op(). This also fix flash reading/writing if dirmap can't be created. * Support of dualio/quadio flash reading commands * Remove dirty hack that reads flash page settings from SNFI registers during driver startup * Add support of EN7523 SoC Patched kernel tests: root@OpenWrt:/lib/modules/6.6.79# insmod mtd_oobtest.ko dev=1 [ 263.191711] [ 263.193218] ================================================= [ 263.199014] mtd_oobtest: MTD device: 1 [ 263.202768] mtd_oobtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 263.216791] mtd_test: scanning for bad eraseblocks [ 263.221956] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 263.227361] mtd_oobtest: test 1 of 5 [ 265.077216] mtd_oobtest: writing OOBs of whole device [ 265.121767] mtd_oobtest: written up to eraseblock 0 [ 275.174147] mtd_oobtest: written up to eraseblock 256 [ 285.210279] mtd_oobtest: written up to eraseblock 512 [ 295.241724] mtd_oobtest: written up to eraseblock 768 [ 305.280167] mtd_oobtest: written up to eraseblock 1024 [ 315.326883] mtd_oobtest: written up to eraseblock 1280 [ 325.364049] mtd_oobtest: written up to eraseblock 1536 [ 335.398609] mtd_oobtest: written up to eraseblock 1792 [ 345.358981] mtd_oobtest: written 2047 eraseblocks [ 345.363694] mtd_oobtest: verifying all eraseblocks [ 345.386088] mtd_oobtest: verified up to eraseblock 0 [ 349.830833] mtd_oobtest: verified up to eraseblock 256 [ 354.276245] mtd_oobtest: verified up to eraseblock 512 [ 358.721496] mtd_oobtest: verified up to eraseblock 768 [ 363.166881] mtd_oobtest: verified up to eraseblock 1024 [ 367.612694] mtd_oobtest: verified up to eraseblock 1280 [ 372.058211] mtd_oobtest: verified up to eraseblock 1536 [ 376.503820] mtd_oobtest: verified up to eraseblock 1792 [ 380.914843] mtd_oobtest: verified 2047 eraseblocks [ 380.919660] mtd_oobtest: test 2 of 5 [ 384.202620] mtd_oobtest: writing OOBs of whole device [ 384.247584] mtd_oobtest: written up to eraseblock 0 [ 394.305121] mtd_oobtest: written up to eraseblock 256 [ 404.342199] mtd_oobtest: written up to eraseblock 512 [ 414.374204] mtd_oobtest: written up to eraseblock 768 [ 424.409891] mtd_oobtest: written up to eraseblock 1024 [ 434.453378] mtd_oobtest: written up to eraseblock 1280 [ 444.494321] mtd_oobtest: written up to eraseblock 1536 [ 454.534480] mtd_oobtest: written up to eraseblock 1792 [ 464.490962] mtd_oobtest: written 2047 eraseblocks [ 464.495681] mtd_oobtest: verifying all eraseblocks [ 464.518015] mtd_oobtest: verified up to eraseblock 0 [ 468.955635] mtd_oobtest: verified up to eraseblock 256 [ 473.395502] mtd_oobtest: verified up to eraseblock 512 [ 477.834373] mtd_oobtest: verified up to eraseblock 768 [ 482.272717] mtd_oobtest: verified up to eraseblock 1024 [ 486.712148] mtd_oobtest: verified up to eraseblock 1280 [ 491.150704] mtd_oobtest: verified up to eraseblock 1536 [ 495.589439] mtd_oobtest: verified up to eraseblock 1792 [ 499.993138] mtd_oobtest: verified 2047 eraseblocks [ 499.997951] mtd_oobtest: test 3 of 5 [ 503.404228] mtd_oobtest: writing OOBs of whole device [ 503.448822] mtd_oobtest: written up to eraseblock 0 [ 513.480773] mtd_oobtest: written up to eraseblock 256 [ 523.489361] mtd_oobtest: written up to eraseblock 512 [ 533.506896] mtd_oobtest: written up to eraseblock 768 [ 543.506268] mtd_oobtest: written up to eraseblock 1024 [ 553.506503] mtd_oobtest: written up to eraseblock 1280 [ 563.511266] mtd_oobtest: written up to eraseblock 1536 [ 573.519567] mtd_oobtest: written up to eraseblock 1792 [ 583.455111] mtd_oobtest: written 2047 eraseblocks [ 583.459837] mtd_oobtest: verifying all eraseblocks [ 583.499358] mtd_oobtest: verified up to eraseblock 0 [ 592.382953] mtd_oobtest: verified up to eraseblock 256 [ 601.267297] mtd_oobtest: verified up to eraseblock 512 [ 610.150907] mtd_oobtest: verified up to eraseblock 768 [ 619.034702] mtd_oobtest: verified up to eraseblock 1024 [ 627.919683] mtd_oobtest: verified up to eraseblock 1280 [ 636.821168] mtd_oobtest: verified up to eraseblock 1536 [ 645.705487] mtd_oobtest: verified up to eraseblock 1792 [ 654.520336] mtd_oobtest: verified 2047 eraseblocks [ 654.525134] mtd_oobtest: test 4 of 5 [ 657.578146] mtd_oobtest: attempting to start write past end of OOB [ 657.584336] mtd_oobtest: an error is expected... [ 657.588974] mtd_oobtest: error occurred as expected [ 657.593848] mtd_oobtest: attempting to start read past end of OOB [ 657.599953] mtd_oobtest: an error is expected... [ 657.604569] mtd_oobtest: error occurred as expected [ 657.609450] mtd_oobtest: attempting to write past end of device [ 657.615367] mtd_oobtest: an error is expected... [ 657.619990] mtd_oobtest: error occurred as expected [ 657.624864] mtd_oobtest: attempting to read past end of device [ 657.630715] mtd_oobtest: an error is expected... [ 657.635333] mtd_oobtest: error occurred as expected [ 657.641043] mtd_oobtest: attempting to write past end of device [ 657.646966] mtd_oobtest: an error is expected... [ 657.651574] mtd_oobtest: error occurred as expected [ 657.656451] mtd_oobtest: attempting to read past end of device [ 657.662277] mtd_oobtest: an error is expected... [ 657.666901] mtd_oobtest: error occurred as expected [ 657.671774] mtd_oobtest: test 5 of 5 [ 659.382333] mtd_oobtest: writing OOBs of whole device [ 659.388056] mtd_oobtest: written up to eraseblock 0 [ 659.393526] mtd_oobtest: written up to eraseblock 0 [ 659.704525] mtd_oobtest: written up to eraseblock 256 [ 659.710187] mtd_oobtest: written up to eraseblock 256 [ 660.021093] mtd_oobtest: written up to eraseblock 512 [ 660.026752] mtd_oobtest: written up to eraseblock 512 [ 660.338427] mtd_oobtest: written up to eraseblock 768 [ 660.344048] mtd_oobtest: written up to eraseblock 768 [ 660.655718] mtd_oobtest: written up to eraseblock 1024 [ 660.661462] mtd_oobtest: written up to eraseblock 1024 [ 660.970676] mtd_oobtest: written up to eraseblock 1280 [ 660.976386] mtd_oobtest: written up to eraseblock 1280 [ 661.286858] mtd_oobtest: written up to eraseblock 1536 [ 661.292587] mtd_oobtest: written up to eraseblock 1536 [ 661.605397] mtd_oobtest: written up to eraseblock 1792 [ 661.611142] mtd_oobtest: written up to eraseblock 1792 [ 661.918754] mtd_oobtest: written 2046 eraseblocks [ 661.923458] mtd_oobtest: verifying all eraseblocks [ 661.928812] mtd_oobtest: verified up to eraseblock 0 [ 662.072499] mtd_oobtest: verified up to eraseblock 256 [ 662.216152] mtd_oobtest: verified up to eraseblock 512 [ 662.359956] mtd_oobtest: verified up to eraseblock 768 [ 662.503238] mtd_oobtest: verified up to eraseblock 1024 [ 662.646847] mtd_oobtest: verified up to eraseblock 1280 [ 662.790603] mtd_oobtest: verified up to eraseblock 1536 [ 662.934269] mtd_oobtest: verified up to eraseblock 1792 [ 663.076329] mtd_oobtest: verified 2046 eraseblocks [ 663.081114] mtd_oobtest: finished with 0 errors [ 663.085647] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_pagetest.ko dev=1 [ 1142.213082] [ 1142.214590] ================================================= [ 1142.220433] mtd_pagetest: MTD device: 1 [ 1142.224278] mtd_pagetest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1142.238388] mtd_test: scanning for bad eraseblocks [ 1142.243536] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1142.248935] mtd_pagetest: erasing whole device [ 1143.962562] mtd_pagetest: erased 2047 eraseblocks [ 1143.967301] mtd_pagetest: writing whole device [ 1144.011729] mtd_pagetest: written up to eraseblock 0 [ 1154.137933] mtd_pagetest: written up to eraseblock 256 [ 1164.265201] mtd_pagetest: written up to eraseblock 512 [ 1174.393365] mtd_pagetest: written up to eraseblock 768 [ 1184.525700] mtd_pagetest: written up to eraseblock 1024 [ 1194.650920] mtd_pagetest: written up to eraseblock 1280 [ 1204.773676] mtd_pagetest: written up to eraseblock 1536 [ 1214.896934] mtd_pagetest: written up to eraseblock 1792 [ 1224.942600] mtd_pagetest: written 2047 eraseblocks [ 1224.947410] mtd_pagetest: verifying all eraseblocks [ 1225.053133] mtd_pagetest: verified up to eraseblock 0 [ 1250.760034] mtd_pagetest: verified up to eraseblock 256 [ 1276.448242] mtd_pagetest: verified up to eraseblock 512 [ 1302.138825] mtd_pagetest: verified up to eraseblock 768 [ 1327.824020] mtd_pagetest: verified up to eraseblock 1024 [ 1353.532178] mtd_pagetest: verified up to eraseblock 1280 [ 1379.234385] mtd_pagetest: verified up to eraseblock 1536 [ 1404.943865] mtd_pagetest: verified up to eraseblock 1792 [ 1430.468816] mtd_pagetest: verified 2047 eraseblocks [ 1430.473702] mtd_pagetest: crosstest [ 1430.477717] mtd_pagetest: reading page at 0x0 [ 1430.482328] mtd_pagetest: reading page at 0xffdf800 [ 1430.487469] mtd_pagetest: reading page at 0x0 [ 1430.492084] mtd_pagetest: verifying pages read at 0x0 match [ 1430.497668] mtd_pagetest: crosstest ok [ 1430.501409] mtd_pagetest: erasecrosstest [ 1430.505323] mtd_pagetest: erasing block 0 [ 1430.511511] mtd_pagetest: writing 1st page of block 0 [ 1430.517166] mtd_pagetest: reading 1st page of block 0 [ 1430.522505] mtd_pagetest: verifying 1st page of block 0 [ 1430.527739] mtd_pagetest: erasing block 0 [ 1430.532565] mtd_pagetest: writing 1st page of block 0 [ 1430.538229] mtd_pagetest: erasing block 2046 [ 1430.544181] mtd_pagetest: reading 1st page of block 0 [ 1430.549498] mtd_pagetest: verifying 1st page of block 0 [ 1430.554718] mtd_pagetest: erasecrosstest ok [ 1430.558900] mtd_pagetest: erasetest [ 1430.562381] mtd_pagetest: erasing block 0 [ 1430.567208] mtd_pagetest: writing 1st page of block 0 [ 1430.572858] mtd_pagetest: erasing block 0 [ 1430.577680] mtd_pagetest: reading 1st page of block 0 [ 1430.582990] mtd_pagetest: verifying 1st page of block 0 is all 0xff [ 1430.589279] mtd_pagetest: erasetest ok [ 1430.593023] mtd_pagetest: finished with 0 errors [ 1430.597651] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_readtest.ko dev=1 [ 1478.691648] [ 1478.693158] ================================================= [ 1478.698981] mtd_readtest: MTD device: 1 [ 1478.702829] mtd_readtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1478.716939] mtd_test: scanning for bad eraseblocks [ 1478.722072] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1478.727475] mtd_readtest: testing page read [ 1548.352125] mtd_readtest: finished [ 1548.355553] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 1617.353002] [ 1617.354511] ================================================= [ 1617.360332] mtd_speedtest: MTD device: 1 [ 1617.364258] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 1617.380150] mtd_test: scanning for bad eraseblocks [ 1617.385428] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 1621.021861] mtd_speedtest: testing eraseblock write speed [ 1700.915306] mtd_speedtest: eraseblock write speed is 3279 KiB/s [ 1700.921250] mtd_speedtest: testing eraseblock read speed [ 1734.931886] mtd_speedtest: eraseblock read speed is 7705 KiB/s [ 1738.682742] mtd_speedtest: testing page write speed [ 1818.818644] mtd_speedtest: page write speed is 3269 KiB/s [ 1818.824058] mtd_speedtest: testing page read speed [ 1852.913595] mtd_speedtest: page read speed is 7687 KiB/s [ 1856.674492] mtd_speedtest: testing 2 page write speed [ 1936.437284] mtd_speedtest: 2 page write speed is 3285 KiB/s [ 1936.442869] mtd_speedtest: testing 2 page read speed [ 1970.498124] mtd_speedtest: 2 page read speed is 7694 KiB/s [ 1970.503624] mtd_speedtest: Testing erase speed [ 1974.343389] mtd_speedtest: erase speed is 68316 KiB/s [ 1974.348479] mtd_speedtest: Testing 2x multi-block erase speed [ 1976.068855] mtd_speedtest: 2x multi-block erase speed is 152811 KiB/s [ 1976.075309] mtd_speedtest: Testing 4x multi-block erase speed [ 1977.790232] mtd_speedtest: 4x multi-block erase speed is 153301 KiB/s [ 1977.796693] mtd_speedtest: Testing 8x multi-block erase speed [ 1979.511905] mtd_speedtest: 8x multi-block erase speed is 153273 KiB/s [ 1979.518367] mtd_speedtest: Testing 16x multi-block erase speed [ 1981.230700] mtd_speedtest: 16x multi-block erase speed is 153539 KiB/s [ 1981.237249] mtd_speedtest: Testing 32x multi-block erase speed [ 1982.948381] mtd_speedtest: 32x multi-block erase speed is 153648 KiB/s [ 1982.954918] mtd_speedtest: Testing 64x multi-block erase speed [ 1984.665992] mtd_speedtest: 64x multi-block erase speed is 153655 KiB/s [ 1984.672531] mtd_speedtest: finished [ 1984.676054] ================================================= root@OpenWrt:/lib/modules/6.6.79# insmod mtd_stresstest.ko dev=1 [ 2190.651750] [ 2190.653263] ================================================= [ 2190.659087] mtd_stresstest: MTD device: 1 [ 2190.663105] mtd_stresstest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2190.679846] mtd_test: scanning for bad eraseblocks [ 2190.684981] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2190.690389] mtd_stresstest: doing operations [ 2190.694655] mtd_stresstest: 0 operations done [ 2214.262705] mtd_stresstest: 1024 operations done [ 2239.019612] mtd_stresstest: 2048 operations done [ 2262.820899] mtd_stresstest: 3072 operations done [ 2285.061376] mtd_stresstest: 4096 operations done [ 2308.297322] mtd_stresstest: 5120 operations done [ 2330.530459] mtd_stresstest: 6144 operations done [ 2352.651759] mtd_stresstest: 7168 operations done [ 2375.188275] mtd_stresstest: 8192 operations done [ 2397.738174] mtd_stresstest: 9216 operations done [ 2414.792572] mtd_stresstest: finished, 10000 operations done [ 2414.798257] ================================================= Speed test of original driver (with patch to fix support of flashes with more than one plane per lun) root@OpenWrt:/lib/modules/6.6.79# insmod mtd_speedtest.ko dev=1 [ 2894.142208] [ 2894.143719] ================================================= [ 2894.149556] mtd_speedtest: MTD device: 1 [ 2894.153486] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128 [ 2894.168888] mtd_test: scanning for bad eraseblocks [ 2894.174023] mtd_test: scanned 2047 eraseblocks, 0 are bad [ 2897.500416] mtd_speedtest: testing eraseblock write speed [ 2977.807233] mtd_speedtest: eraseblock write speed is 3262 KiB/s [ 2977.813171] mtd_speedtest: testing eraseblock read speed [ 3013.906597] mtd_speedtest: eraseblock read speed is 7260 KiB/s [ 3017.440320] mtd_speedtest: testing page write speed [ 3097.833394] mtd_speedtest: page write speed is 3259 KiB/s [ 3097.838812] mtd_speedtest: testing page read speed [ 3134.004981] mtd_speedtest: page read speed is 7245 KiB/s [ 3137.538423] mtd_speedtest: testing 2 page write speed [ 3217.906288] mtd_speedtest: 2 page write speed is 3260 KiB/s [ 3217.911883] mtd_speedtest: testing 2 page read speed [ 3254.049757] mtd_speedtest: 2 page read speed is 7251 KiB/s [ 3254.055254] mtd_speedtest: Testing erase speed [ 3257.599146] mtd_speedtest: erase speed is 74027 KiB/s [ 3257.604213] mtd_speedtest: Testing 2x multi-block erase speed [ 3259.320945] mtd_speedtest: 2x multi-block erase speed is 153139 KiB/s [ 3259.327413] mtd_speedtest: Testing 4x multi-block erase speed [ 3261.044585] mtd_speedtest: 4x multi-block erase speed is 153098 KiB/s [ 3261.051047] mtd_speedtest: Testing 8x multi-block erase speed [ 3262.786520] mtd_speedtest: 8x multi-block erase speed is 151479 KiB/s [ 3262.792979] mtd_speedtest: Testing 16x multi-block erase speed [ 3264.509898] mtd_speedtest: 16x multi-block erase speed is 153130 KiB/s [ 3264.516454] mtd_speedtest: Testing 32x multi-block erase speed [ 3266.233403] mtd_speedtest: 32x multi-block erase speed is 153125 KiB/s [ 3266.239961] mtd_speedtest: Testing 64x multi-block erase speed [ 3267.957985] mtd_speedtest: 64x multi-block erase speed is 153029 KiB/s [ 3267.964525] mtd_speedtest: finished [ 3267.968039] ================================================= It looks like a patched driver is a bit faster write speed: 3260 KiB/s vs 3277 KiB/s read speed: 7252 KiB/s vs 7695 KiB/s
2025-10-17arm64: debug: always unmask interrupts in el0_softstp()Ada Couprie Diaz
We intend that EL0 exception handlers unmask all DAIF exceptions before calling exit_to_user_mode(). When completing single-step of a suspended breakpoint, we do not call local_daif_restore(DAIF_PROCCTX) before calling exit_to_user_mode(), leaving all DAIF exceptions masked. When pseudo-NMIs are not in use this is benign. When pseudo-NMIs are in use, this is unsound. At this point interrupts are masked by both DAIF.IF and PMR_EL1, and subsequent irq flag manipulation may not work correctly. For example, a subsequent local_irq_enable() within exit_to_user_mode_loop() will only unmask interrupts via PMR_EL1 (leaving those masked via DAIF.IF), and anything depending on interrupts being unmasked (e.g. delivery of signals) will not work correctly. This was detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING. Move the call to `try_step_suspended_breakpoints()` outside of the check so that interrupts can be unmasked even if we don't call the step handler. Fixes: 0ac7584c08ce ("arm64: debug: split single stepping exception entry") Cc: <stable@vger.kernel.org> # 6.17 Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> [catalin.marinas@arm.com: added Mark's rewritten commit log and some whitespace] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-10-17arm64/sysreg: Fix GIC CDEOI instruction encodingLorenzo Pieralisi
The GIC CDEOI system instruction requires the Rt field to be set to 0b11111 otherwise the instruction behaviour becomes CONSTRAINED UNPREDICTABLE. Currenly, its usage is encoded as a system register write, with a constant 0 value: write_sysreg_s(0, GICV5_OP_GIC_CDEOI) While compiling with GCC, the 0 constant value, through these asm constraints and modifiers ('x' modifier and 'Z' constraint combo): asm volatile(__msr_s(r, "%x0") : : "rZ" (__val)); forces the compiler to issue the XZR register for the MSR operation (ie that corresponds to Rt == 0b11111) issuing the right instruction encoding. Unfortunately LLVM does not yet understand that modifier/constraint combo so it ends up issuing a different register from XZR for the MSR source, which in turns means that it encodes the GIC CDEOI instruction wrongly and the instruction behaviour becomes CONSTRAINED UNPREDICTABLE that we must prevent. Add a conditional to write_sysreg_s() macro that detects whether it is passed a constant 0 value and issues an MSR write with XZR as source register - explicitly doing what the asm modifier/constraint is meant to achieve through constraints/modifiers, fixing the LLVM compilation issue. Fixes: 7ec80fb3f025 ("irqchip/gic-v5: Add GICv5 PPI support") Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Cc: Sascha Bischoff <sascha.bischoff@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-10-17btrfs: send: fix duplicated rmdir operations when using extrefsTing-Chang Hou
Commit 29d6d30f5c8a ("Btrfs: send, don't send rmdir for same target multiple times") has fixed an issue that a send stream contained a rmdir operation for the same directory multiple times. After that fix we keep track of the last directory for which we sent a rmdir operation and compare with it before sending a rmdir for the parent inode of a deleted hardlink we are processing. But there is still a corner case that in between rmdir dir operations for the same inode we find deleted hardlinks for other parent inodes, so tracking just the last inode for which we sent a rmdir operation is not enough. Hardlinks of a file in the same directory are stored in the same INODE_REF item, but if the number of hardlinks is too large and can not fit in a leaf, we use INODE_EXTREF items to store them. The key of an INODE_EXTREF item is (inode_id, INODE_EXTREF, hash[name, parent ino]), so between two hardlinks for the same parent directory, we can find others for other parent directories. For example for the reproducer below we get the following (from a btrfs inspect-internal dump-tree output): item 0 key (259 INODE_EXTREF 2309449) itemoff 16257 itemsize 26 index 6925 parent 257 namelen 8 name: foo.6923 item 1 key (259 INODE_EXTREF 2311350) itemoff 16231 itemsize 26 index 6588 parent 258 namelen 8 name: foo.6587 item 2 key (259 INODE_EXTREF 2457395) itemoff 16205 itemsize 26 index 6611 parent 257 namelen 8 name: foo.6609 (...) So tracking the last directory's inode number does not work in this case since we process a link for parent inode 257, then for 258 and then back again for 257, and that second time we process a deleted link for 257 we think we have not yet sent a rmdir operation. Fix this by using a rbtree to keep track of all the directories for which we have already sent rmdir operations, and add those directories to the 'check_dirs' ref list in process_recorded_refs() only if the directory is not yet in the rbtree, otherwise skip it since it means we have already sent a rmdir operation for that directory. The following test script reproduces the problem: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV mount $DEV $MNT mkdir $MNT/a $MNT/b echo 123 > $MNT/a/foo for ((i = 1; i <= 1000; i++)); do ln $MNT/a/foo $MNT/a/foo.$i ln $MNT/a/foo $MNT/b/foo.$i done btrfs subvolume snapshot -r $MNT $MNT/snap1 btrfs send $MNT/snap1 -f /tmp/base.send rm -r $MNT/a $MNT/b btrfs subvolume snapshot -r $MNT $MNT/snap2 btrfs send -p $MNT/snap1 $MNT/snap2 -f /tmp/incremental.send umount $MNT mkfs.btrfs -f $DEV mount $DEV $MNT btrfs receive $MNT -f /tmp/base.send btrfs receive $MNT -f /tmp/incremental.send rm -f /tmp/base.send /tmp/incremental.send umount $MNT When running it, it fails like this: $ ./test.sh (...) At subvol snap1 At snapshot snap2 ERROR: rmdir o257-9-0 failed: No such file or directory CC: <stable@vger.kernel.org> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Ting-Chang Hou <tchou@synology.com> [ Updated changelog ] Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-10-17btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()Dewei Meng
If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised. syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: <TASK> btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...] Fixes: 3bb17a25bcb0 ("btrfs: add get_tree callback for new mount API") CC: stable@vger.kernel.org # 6.12+ Reviewed-by: Daniel Vacek <neelx@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Dewei Meng <mengdewei@cqsoftware.com.cn> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-10-17spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()Dan Carpenter
The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Update the error checking to match. Fixes: 64d87ccfae33 ("spi: aspeed: Only map necessary address window region") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aPJpEnfK31pHz8_w@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-17HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_opsZhang Lixu
The same suspend and resume callbacks are used for both suspend-to-RAM/idle and hibernation. These callbacks invoke pm_suspend_via_firmware() and pm_resume_via_firmware(), respectively. In the .freeze() of hibernation, pm_suspend_via_firmware() returns false, causing the driver to put ISH into D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true, leading the driver to treat ISH as resuming from D3 instead of D0i3. The asymmetric behavior between .freeze() and .thaw() during hibernation can cause the client connection states on the firmware side and the driver side to become inconsistent. To address the inconsistent client connection states issue, separate hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does not need to save any firmware-related state when entering hibernation, it is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus from changing the ISH power state. No actions are required in .thaw(). Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use IPC RESET instead of void message in ish_wakeup()Zhang Lixu
On ISH power-up, the bootloader enters sleep after preparing to load the main firmware, waiting for the driver to be ready. When the driver is ready, it sends a void message to wake up the bootloader and load the main firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for handshake. This void message-based IPC handshake only works if the main firmware has not been loaded. During hibernation resume, if the restore kernel has the ISH driver, the driver wakes up the bootloader to load the main firmware and perform IPC handshake. However, when switching to the image kernel, since the main firmware is already loaded, sending a void message in the .restore() callback does not trigger IPC handshake. By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of a void message, we can explicitly wake up the bootloader and perform IPC handshake, regardless of the firmware state. Additionally, since ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for recvd_hw_ready in ish_hw_start() is removed. The timeout for waiting for HW ready is set to 10 seconds, matching the original timeout value used in ish_wakeup(), to ensure reliable wakeup on hardware that requires more time, such as the Lenovo ThinkPad X1 Titanium Gen 1. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: ipc: Always schedule FW reset work on RESET_NOTIFY/ACKZhang Lixu
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate an FW reset handshake. Upon receiving this, the peer should reply with MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset handshake work function when receiving either MNG_RESET_NOTIFY or MNG_RESET_NOTIFY_ACK. Previously, driver only scheduled the work function on MNG_RESET_NOTIFY. This patch ensures the work function is scheduled on both messages, but only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-ipc: Reset clients state on resume from D3Zhang Lixu
When ISH resumes from D3, the connection between ishtp clients and firmware is lost. The ish_resume() function schedules resume_work asynchronously to re-initiate the connection and then returns immediately. This can cause a race where the upper-layer ishtp client driver's .resume() may execute before the connection is fully restored, leaving the client in a stale connected state. If the client sends messages during this window, the firmware cannot respond. To avoid this, reset the ishtp clients' state before returning from ish_resume() if ISH is resuming from D3. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ishtp-hid: Clear suspended flag only after connected on resumeZhang Lixu
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered on from D3, causing all previous client connections between the firmware and driver to be lost. Although the underlying ishtp bus driver initiates a client reconnection flow, this process is asynchronous. As a result, when hid_ishtp_cl_resume_handler() is executed, the connection may not have been re-established yet. Clearing the suspended flag prematurely in this scenario can lead to a timeout when the upper-layer HID sensor driver set feature during resume. To prevent such timeouts, only clear the suspended flag after confirming that the connection state is ISHTP_CL_CONNECTED. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Add ishtp_get_connection_state() interfaceZhang Lixu
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing ishtp client drivers to retrieve the current connection state. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blockingZhang Lixu
During suspend/resume tests with S2IDLE, some ISH functional failures were observed because of delay in executing ISH resume handler. Here schedule_work() is used from resume handler to do actual work. schedule_work() uses system_wq, which is a per CPU work queue. Although the queuing is not bound to a CPU, but it prefers local CPU of the caller, unless prohibited. Users of this work queue are not supposed to queue long running work. But in practice, there are scenarios where long running work items are queued on other unbound workqueues, occupying the CPU. As a result, the ISH resume handler may not get a chance to execute in a timely manner. In one scenario, one of the ish_resume_handler() executions was delayed nearly 1 second because another work item on an unbound workqueue occupied the same CPU. This delay causes ISH functionality failures. A similar issue was previously observed where the ISH HID driver timed out while getting the HID descriptor during S4 resume in the recovery kernel, likely caused by the same workqueue contention problem. Create dedicated unbound workqueues for all ISH operations to allow work items to execute on any available CPU, eliminating CPU-specific bottlenecks and improving resume reliability under varying system loads. Also ISH has three different components, a bus driver which implements ISH protocols, a PCI interface layer and HID interface. Use one dedicated work queue for all of them. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17Merge tag 'io_uring-6.18-20251016' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Revert of a change that went into an older kernel, and which has been reported to cause a regression for some write workloads on LVM while a snapshop is being created - Fix a regression from this merge window, where some compilers (and/or certain .config options) would cause an earlier evaluations of a dereference which would then cause a NULL pointer dereference. I was only able to reproduce this with OPTIMIZE_FOR_SIZE=y, but David Howells hit it with just KASAN enabled. Depending on how things inlined, this makes sense - Fix for a missing lock around a mem region unregistration - Fix for ring resizing with the same placement after resize * tag 'io_uring-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/rw: check for NULL io_br_sel when putting a buffer io_uring: fix unexpected placement on same size resizing io_uring: protect mem region deregistration Revert "io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()"
2025-10-17cgroup/misc: fix misc_res_type kernel-doc warningRandy Dunlap
Format the kernel-doc for SCALE_HW_CALIB_INVALID correctly to avoid a kernel-doc warning: Warning: include/linux/misc_cgroup.h:26 Enum value 'MISC_CG_RES_TDX' not described in enum 'misc_res_type' Fixes: 7c035bea9407 ("KVM: TDX: Register TDX host key IDs to cgroup misc controller") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-10-17Merge tag 'block-6.18-20251016' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe pull request via Keith: - iostats accounting fixed on multipath retries (Amit) - secure concatenation response fixup (Martin) - tls partial record fixup (Wilfred) - Fix for a lockdep reported issue with the elevator lock and blk group frozen operations - Fix for a regression in this merge window, where updating 'nr_requests' would not do the right thing for queues with shared tags * tag 'block-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: nvme/tcp: handle tls partially sent records in write_space() block: Remove elevator_lock usage from blkg_conf frozen operations blk-mq: fix stale tag depth for shared sched tags in blk_mq_update_nr_requests() nvme-auth: update sc_c in host response nvme-multipath: Skip nr_active increments in RETRY disposition
2025-10-17Merge tag 'mmc-v6.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull mmc cleanup from Ulf Hansson: "Move rpmb_frame struct and constants to rpmb common header This helps us to avoid sharing an immutable branch between our git trees. I was planning to send it before rc1, but I didn't make it" * tag 'mmc-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: rpmb: move rpmb_frame struct and constants to common header
2025-10-17Merge tag 'sound-6.18-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes. All changes are rather boring device-specific fixes and quirks: - A few fixes for missing NULL checks - ASoC NAU8821 fixes for jack and irq handling - Various fixes for ASoC TAS2781, IDT821034, sc8280xp, max9809x, wcd938x, and SoundWire - Usual HD-audio and USB-audio quirks" * tag 'sound-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (27 commits) ALSA: hda/realtek: Fix mute led for HP Omen 17-cb0xxx ALSA: usb-audio: fix vendor quirk for Logitech H390 ALSA: usb-audio: add volume quirks for MS LifeChat LX-3000 ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails ASoC: max98090/91: fixed max98091 ALSA widget powering up/down ASoC: dt-bindings: Add compatible string fsl,imx-audio-tlv320 ASoC: codecs: wcd938x-sdw: remove redundant runtime pm calls ASoC: sdw_utils: add rt1321 part id to codec_info_list ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings ALSA: usb-audio: add mixer_playback_min_mute quirk for Logitech H390 ASoC: nau8821: Avoid unnecessary blocking in IRQ handler ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit ASoC: nau8821: Consistently clear interrupts before unmasking ASoC: nau8821: Generalize helper to clear IRQ status ASoC: nau8821: Cancel jdet_work before handling jack ejection ASoC: codecs: Fix gain setting ranges for Renesas IDT821034 codec ASoC: tas2781: Update ti,tas2781.yaml for adding tas58xx ASoC: tas2781: Support more newly-released amplifiers tas58xx in the driver ASoC: qcom: sc8280xp: Add support for QCS615 ...
2025-10-17Merge tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "As per usual xe/amdgpu are the leaders, with some i915 and then a bunch of scattered fixes. There are a bunch of stability fixes for some older amdgpu cards. draw: - Avoid color truncation gpuvm: - Avoid kernel-doc warning sched: - Avoid double free i915: - Skip GuC communication warning if reset is in progress - Couple frontbuffer related fixes - Deactivate PSR only on LNL and when selective fetch enabled xe: - Increase global invalidation timeout to handle some workloads - Fix NPD while evicting BOs in an array of VM binds - Fix resizable BAR to account for possibly needing to move BARs other than the LMEMBAR - Fix error handling in xe_migrate_init() - Fix atomic fault handling with mixed mappings or if the page is already in VRAM - Enable media samplers power gating for platforms before Xe2 - Fix de-registering exec queue from GuC when unbinding - Ensure data migration to system if indicated by madvise with SVM - Fix kerneldoc for kunit change - Always account for cacheline alignment on migration - Drop bogus assertion on eviction amdgpu: - Backlight fix - SI fixes - CIK fix - Make CE support debug only - IP discovery fix - Ring reset fixes - GPUVM fault memory barrier fix - Drop unused structures in amdgpu_drm.h - JPEG debugfs fix - VRAM handling fixes for GPUs without VRAM - GC 12 MES fixes amdkfd: - MES fix ast: - Fix display output after reboot bridge: - lt9211: Fix version check panthor: - Fix MCU suspend qaic: - Init bootlog in correct order - Treat remaining == 0 as error in find_and_map_user_pages() - Lock access to DBC request queue rockchip: - vop2: Fix destination size in atomic check" * tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernel: (44 commits) drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies drm/xe/evict: drop bogus assert drm/xe/migrate: don't misalign current bytes drm/xe/kunit: Fix kerneldoc for parameterized tests drm/xe/svm: Ensure data will be migrated to system if indicated by madvise. drm/gpuvm: Fix kernel-doc warning for drm_gpuvm_map_req.map drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabled drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off accel/qaic: Synchronize access to DBC request queue head & tail pointer accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() accel/qaic: Fix bootlog initialization ordering drm/rockchip: vop2: use correct destination rectangle height check drm/draw: fix color truncation in drm_draw_fill24 drm/xe/guc: Check GuC running state before deregistering exec queue drm/xe: Enable media sampler power gating drm/xe: Handle mixed mappings and existing VRAM on atomic faults drm/xe/migrate: Fix an error path drm/xe: Move rebar to be done earlier drm/xe: Don't allow evicting of BOs in same VM in array of VM binds drm/xe: Increase global invalidation timeout to 1000us ...
2025-10-17drm/xe/pf: Allow to restore auto-provisioning modeMichal Wajdeczko
After doing tweaks to the VFs provisioning we may want to restore back the auto-provisioning mode. Allow that unless VFs are still enabled. This can be also used to release all VFs resources. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17Merge tag 'i2c-for-6.18-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - PM cleanup after all prerequisites are merged with rc1 - usbio: missing addition after all dependencies are in - slimpro: DT binding schema conversion * tag 'i2c-for-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: dt-bindings: i2c: Convert apm,xgene-slimpro-i2c to DT schema i2c: usbio: Add ACPI device-id for MTL-CVF devices i2c: Remove redundant pm_runtime_mark_last_busy() calls
2025-10-17drm/xe/pf: Disable auto-provisioning if changed using debugfsMichal Wajdeczko
When we attempt to tweak VFs configurations using debugfs, stop assuming that VFs need auto-(un)provisioning. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Automatically provision VFs only in auto-modeMichal Wajdeczko
We shouldn't attempt to auto-provision VFs once we allow other provisioning methods. Make the code aware of the new condition. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Promote VFs provisioning helpersMichal Wajdeczko
As we plan to add more VFs provisioning methods, start moving related code into single place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17drm/xe/pf: Always expose VRAM provisioning data on discrete GPUsLukasz Laguna
Currently, VRAM provisioning data is only exposed if the device supports LMTT. While it should not be possible to modify VRAM provisioning on platforms without LMTT, it is still useful to be able to read the VRAM provisioning data on all discrete GPU platforms. Expose the VRAM debugfs attributes whenever running on dGFX, adjusting file permissions to read only when LMTT is not available. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251016122233.3789-1-lukasz.laguna@intel.com
2025-10-17ntfs3: Fix uninit buffer allocated by __getname()Sidharth Seela
Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN. Reported-by: syzbot+332bd4e9d148f11a87dc@syzkaller.appspotmail.com Fixes: 78ab59fee07f2 ("fs/ntfs3: Rework file operations") Signed-off-by: Sidharth Seela <sidharthseela@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ntfs3: fix uninit memory after failed mi_read in mi_format_newRaphael Pinsonneault-Thibeault
Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it. Reported-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7a2ba6b7b66340cff225 Tested-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com Fixes: 4342306f0f0d5 ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ntfs3: fix use-after-free of sbi->options in cmp_fnamesYangWen
The root cause is that sbi->options points directly to fc->fs_private. If fc->fs_private is freed while sbi still exists, sbi->options becomes a dangling pointer. This patch ensures that sbi->options is a separate copy of fc->fs_private and duplicates nls_name if present. On superblock release or error, sbi->options->nls_name and sbi->options are freed and sbi->options is set to NULL to avoid any dangling pointer. Reported-by: syzbot+d77c546c60db651a389c@syzkaller.appspotmail.com Signed-off-by: YangWen <anmuxixixi@gmail.com> [almaz.alexandrovich@paragon-software.com: remove syzbot logs from description] Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ntfs: Do not overwrite uptodate pagesMatthew Wilcox (Oracle)
When reading a compressed file, we may read several pages in addition to the one requested. The current code will overwrite pages in the page cache with the data from disc which can definitely result in changes that have been made being lost. For example if we have four consecutie pages ABCD in the file compressed into a single extent, on first access, we'll bring in ABCD. Then we write to page B. Memory pressure results in the eviction of ACD. When we attempt to write to page C, we will overwrite the data in page B with the data currently on disk. I haven't investigated the decompression code to check whether it's OK to overwrite a clean page or whether it might be possible to see corrupt data. Out of an abundance of caution, decline to overwrite uptodate pages, not just dirty pages. Fixes: 4342306f0f0d (fs/ntfs3: Add file operations and implementation) Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: stable@vger.kernel.org Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ntfs: Do not kmap page cache pages for compressionMatthew Wilcox (Oracle)
These pages are accessed through vmap; they are not accessed by calling page_address(), so they do not need to be kmapped. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ntfs: Do not kmap pages used for reading from diskMatthew Wilcox (Oracle)
These pages are accessed through DMA and vmap; they are not accessed by calling page_address(), so they do not need to be kmapped. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2025-10-17ALSA: hda/realtek: Fix mute led for HP Omen 17-cb0xxxDawn Gardner
This laptop uses the ALC285 codec, fixed by enabling the ALC285_FIXUP_HP_MUTE_LED quirk Signed-off-by: Dawn Gardner <dawn.auroali@gmail.com> Link: https://patch.msgid.link/20251016184218.31508-3-dawn.auroali@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-10-17batman-adv: use skb_crc32c() instead of skb_seq_read()Sven Eckelmann
Make batadv_bla_check_duplist() just use the new function skb_crc32c(), instead of calling skb_seq_read() with crc32c(). This is faster and simpler. Suggested-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
2025-10-17batman-adv: Start new development cycleSimon Wunderlich
This version will contain all the (major or even only minor) changes for Linux 6.19. The version number isn't a semantic version number with major and minor information. It is just encoding the year of the expected publishing as Linux -rc1 and the number of published versions this year (starting at 0). Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (corsair-psu) Rely on subsystem lockingGuenter Roeck
Attribute access is now serialized in the hardware monitoring core, so locking in the driver code is no longer necessary. Drop it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-17hwmon: (chipcap2) Drop unnecessary include filesGuenter Roeck
The driver does not perform any locking, does not execute or use any sleep related functionality, and does not allocate memory. Drop the unnecessary include files. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.3 (git 2.53.0) at 2026-11-12 01:19:48 +0000