summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-20of: reserved_mem: prevent OOB when too many dynamic regions are definedSang-Heon Jeon
On boot, fdt_scan_reserved_mem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAX_RESERVED_REGIONS. If the device tree defines more than MAX_RESERVED_REGIONS dynamically-placed regions, fdt_scan_reserved_mem() writes past the end of the local array. Add a bounds check that logs an error and skips the excess regions, restoring the original behavior. Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260614133807.2165124-2-ekffu200098@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Add more DTS test casesKrzysztof Kozlowski
Add a few more test cases for valid and incorrect DTS for dt-check-style. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-7-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Print proper line number of indentation detection placeKrzysztof Kozlowski
Script judges the indentation however always suggests it is the first line which is wrong, e.g.: sigmastar/mstar-infinity2m.dtsi:1: [indent-unit-dts] indent unit must be 1 tab in DTS, got '\t\t' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-6-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Handle properly DTC-style includesKrzysztof Kozlowski
dt-check-style was not properly handling DTC directives (starting with '/', e.g. /dts-v1/ or /include/), thus a few DTS files had false positive like: apm/apm-merlin.dts:1: [indent-unit-dts] indent unit must be 1 tab in DTS, got '\t\t' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-5-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Expect first device_typeKrzysztof Kozlowski
A few nodes do have "device_type" property which is mostly, but not always, the first property in a device node, when applicable. Adjust the DTS coding style rules to actually expect the device_type first and improve the dt-check-style to handle this correctly. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-4-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Rework handling YAML/DTS in rulesKrzysztof Kozlowski
Individual rules behave differently depending whether they handle bindings (YAML) or DTS, but the code was focusing on type of indentation (spaces vs tabs). That indentation is actually irrelevant in some rules, so differentiate based on file type. This will be more relevant in the future when more rules act differently on DTS, than on bindings. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-3-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Allow space-aligning indentation in DTSKrzysztof Kozlowski
DTS often have spaces after tabs in indentation for aligning continued lines of comments or list properties, thus allow such cases to avoid many false positives. What we can easily detect is a space followed by tab or too many spaces (more than alignment). OTOH, DTS example in YAML files does not have tabs at all and there is already rule for that, thus there is no point to check for mixed indentation there. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-2-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Narrow disallowing of tab in DTS only to YAMLKrzysztof Kozlowski
DTS in the bindings (example in a YAML file) does not have tabs at all, but regular DTS do, therefore entire check check_tab_in_dts() has confusing name and should apply only to YAML files. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-1-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dt-bindings: power: maxim,max17042: Fix temp types to signedRob Herring (Arm)
The max17042 binding described "maxim,cold-temp" and "maxim,over-heat-temp" as unsigned values, but in-tree DTS examples use negative temperatures such as a cold threshold below zero degrees. Document the temperature properties as signed int32 values so the schema matches existing DTS data and the driver can use signed helpers. Assisted-by: Codex:gpt-5-5 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260612215315.1889039-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20of: reserved_mem: print skipped node name when too many regions are definedSang-Heon Jeon
When too many reserved memory regions are defined, fdt_init_reserved_mem_node() logs an error and skips the region without naming the node. Print the node name so the skipped node can be identified, matching fdt_scan_reserved_mem(). Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260614133807.2165124-3-ekffu200098@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20Merge tag 'mm-hotfixes-stable-2026-07-20-11-37' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "12 hotfixes. 8 are cc:stable and the remainder address post-7.1 issues or aren't considered appropriate for backporting. 10 are for MM. All are singletons - please see the relevant changelogs for details" * tag 'mm-hotfixes-stable-2026-07-20-11-37' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/memory-failure: trace: change memory_failure_event to ras subsystem mm: page_reporting: allow driver to set batch capacity mm/kmemleak: fix checksum computation for per-cpu objects mm/damon/core: disallow overlapping input ranges for damon_set_regions() MAINTAINERS: add Usama as a THP reviewer fat: avoid stack overflow warning mm/damon/core: validate ranges in damon_set_regions() m68k: avoid -Wunused-but-set-parameter in clear_user_page() mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established mm/page_vma_mapped: fix device-private PMD handling MAINTAINERS: s/SeongJae/SJ/ userfaultfd: prevent registration of special VMAs
2026-07-20Merge tag 'v7.2-p2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: - Fix potential crash in rhashtable walk * tag 'v7.2-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: rhashtable: clear stale iter->p on table restart
2026-07-20drm/panel: panel-edp: Adjust T8 timing for AUO B116XAK01.6 and B140XTK02.4Dio Zhang
Screen garbage or flickering can be observed during mode changes (such as VT switches) on systems using the AUO B116XAK01.6 and B140XTK02.4 panels. This occurs because the backlight is enabled before the video signal stabilizes. Waveform measurements show that the panel signal takes around 140ms to stabilize after a mode change, meaning the previous 50ms T8 timing was insufficient. To resolve this issue, adjust the eDP panel delay entry from delay_200_500_e50 to delay_200_500_e200 (increasing T8 from 50ms to 200ms). This matches the updated panel specifications from AUO, which now formally define T8 as 200ms to mask any display abnormalities during mode changes. Signed-off-by: Dio Zhang <dioyc_zhang@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260720025358.2781136-1-dioyc_zhang@compal.corp-partner.google.com
2026-07-20hfs: port HFS+ b-tree bitmap corruption checkAditya Prakash Srivastava
In HFS+ filesystems, during b-tree open (hfs_btree_open()), the code verifies that the allocation map bit for the tree header (node 0) is set. If not, it indicates a corrupted map record/bitmap and mounts the volume as read-only (SB_RDONLY) to prevent further damage. HFS filesystems share the same b-tree structure but currently lack this corruption detection check. Port this check to HFS, aligning its implementation with HFS+ to maintain consistent b-tree logic across both filesystems: 1. Define struct hfs_bmap_ctx, and define HFS_TREE_HEAD and the relevant map record indices in include/linux/hfs_common.h. 2. Port the necessary offset and length validation helpers to fs/hfs/btree.h as static inline functions with robust null pointer checks. 3. Implement static hfs_bmap_get_map_page() in fs/hfs/btree.c. 4. Implement static hfs_bmap_test_bit() in fs/hfs/btree.c to inspect the B-tree bitmap using the get_map_page helper. 5. Implement static hfs_bmap_clear_bit() in fs/hfs/btree.c. 6. Rewrite hfs_bmap_alloc() in fs/hfs/btree.c to use the unified hfs_bmap_get_map_page() helper, eliminating redundant page and offset calculation code. 7. Refactor hfs_bmap_free() in fs/hfs/btree.c to use the new hfs_bmap_clear_bit() helper. 8. In hfs_btree_open(), retrieve the header node via hfs_bnode_find(), test its allocation bit with hfs_bmap_test_bit(), and release it using hfs_bnode_put(). Suggested-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/all/6a36101b.be22b350.2a3e9.0001.GAE@google.com/T/#r446d0fed2a2900bd805534bbcb799d86619ae2ea Signed-off-by: Aditya Prakash Srivastava <aditya.ansh182@gmail.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260716074150.1660-1-aditya.ansh182@gmail.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-20selftests/futex: Give circular-list nodes static storageMiles Krause
The registered robust-list head has static storage but points at three automatic lock nodes. GCC warns about storing the address of a local variable in the static head when building the selftest with -Wall. Give the nodes static storage as well. This keeps every object in the circular list alive through child exit without changing the list topology. Signed-off-by: Miles Krause <mileskrause5200@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260711-futex-robust-list-static-nodes-v1-1-723754d75cf5@gmail.com
2026-07-20Merge branch 'selftests-bpf-fix-compilation-with-release-1'Kumar Kartikeya Dwivedi
Viktor Malik says: ==================== selftests/bpf: Fix compilation with RELEASE=1 When compiling BPF selftests with RELEASE=1 (which most notably adds -O2), GCC reports several warnings. These are by default treated as errors and abort the compilation. This series fixes all of the issues such that selftests can be compiled with RELEASE=1. ==================== Link: https://patch.msgid.link/cover.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-20selftests/bpf: Silence maybe-uninitialized compiler warning in libarenaViktor Malik
When compiling BPF selftests with -O2, GCC reports a maybe-uninitialized warning in libarena code: In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:11: In function ‘libarena_asan_init’, inlined from ‘run_test’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:59:8, inlined from ‘test_libarena_asan’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:91:2: /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:126:14: error: ‘globals_pages’ may be used uninitialized [-Werror=maybe-uninitialized] 126 | args = (struct asan_init_args){ | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ 127 | .arena_all_pages = arena_all_pages, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 128 | .arena_globals_pages = globals_pages, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 129 | }; | ~ /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h: In function ‘test_libarena_asan’: /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:118:13: note: ‘globals_pages’ was declared here 118 | u64 globals_pages; | ^~~~~~~~~~~~~ Silence the warning by initializing globals_pages to 0. Fixes: cfc00618b9df ("selftests/bpf: Add ASAN support for libarena selftests") Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/bpf/9f77a5c05c3c731ab2655fd66716ab9de4478b15.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-20selftests/bpf: Silence array bounds warning in global_map_resizeViktor Malik
When compiling BPF selftests with -O2, GCC reports an array bounds violation warning in global_map_resize test: In function ‘global_map_resize_bss_subtest’, inlined from ‘test_global_map_resize’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:228:3: /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:64:33: error: array subscript 1 is above array bounds of ‘int[1]’ [-Werror=array-bounds=] 64 | skel->bss->array[i] = 1; | ~~~~~~~~~~~~~~~~^~~ In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:6: ./test_global_map_resize.skel.h: In function ‘test_global_map_resize’: ./test_global_map_resize.skel.h:44:21: note: while referencing ‘array’ 44 | int array[1]; | ^~~~~ This is a false positive because `array` (a BPF map) has been resized from within the BPF program. GCC doesn't know that so let us silence the warning by accessing the array via a plain pointer. Fixes: 08b089567573 ("libbpf: Selftests for resizing datasec maps") Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/bpf/57765bc465a27923c3c093eba222cc24d08d8c40.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-20selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256Viktor Malik
Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the result of malloc. It is more accurate since malloc returns NULL, not an error code, on failure and it also prevents the following false GCC warning when compiling BPF selftests with -O2: In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:4: /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c: In function ‘test_sha256’: ./test_progs.h:393:22: error: ‘data’ may be used uninitialized [-Werror=maybe-uninitialized] 393 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:28:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 28 | if (!ASSERT_OK_PTR(data, "malloc")) | ^~~~~~~~~~~~~ In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32, from ./test_progs.h:37: /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Fixes: f09f57c74677 ("selftests/bpf: Add test for libbpf_sha256()") Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/bpf/f9dec09cca0c2aa5eeb4fdcd400a13aa19e2c073.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-20selftests/bpf: Check malloc result with ASSERT_NEQ in test_loaderViktor Malik
Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the result of malloc. It is more accurate since malloc returns NULL, not an error code, on failure and it also prevents the following false GCC warning when compiling BPF selftests with -O2: In file included from test_loader.c:6: test_loader.c: In function ‘verify_stderr’: /bpf-next/tools/testing/selftests/bpf/test_progs.h:393:22: error: ‘buf’ may be used uninitialized [-Werror=maybe-uninitialized] 393 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ test_loader.c:810:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 810 | if (!ASSERT_OK_PTR(buf, "malloc")) | ^~~~~~~~~~~~~ In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32, from /bpf-next/tools/testing/selftests/bpf/test_progs.h:37: /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Fixes: 554e4eb9e4b7 ("selftests/bpf: Reuse stderr parsing for libarena ASAN tests") Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/bpf/e25d50805fbcb3632f24b488568ab5ba49b82094.1784112948.git.vmalik@redhat.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-20selftests/futex: Use thread synchronization helpers instead of usleep()Yuwen Chen
This test uses usleep() to delay the main thread after creating the test thread[s] under the assumption that they already are blocked on the futex when the main thread continues. That "works" on otherwise idle systems, but fails under load resulting in failed selftests because the requeue operation starts before the waiters reached the kernel. Replace the usleep() waits by the new thread synchronization helpers to cure that. [ tglx: Adapted to test harness changes, fixed coding style, sanitized the timeout handling and rewrote change log. Co-developed-by: Edward Liaw <edliaw@google.com> Signed-off-by: Yuwen Chen <ywen.chen@foxmail.com> Signed-off-by: Edward Liaw <edliaw@google.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/tencent_76B9DE9C9FE5C57F6D74B5149970DF8CCF0A@qq.com
2026-07-20selftests/futex: Provide thread creation and synchronization helpersYuwen Chen
There are timing issues in the use of threads in some selftests for futexes as the tests rely on timed waits to ensure that the other test thread[s] reached the lock wait function in the kernel. That "works" on halfways idle systems, but fails under load which results in tests failing. Provide a set of helper functions to create test threads and to wait for them to reach the lock wait by monitoring /proc/$PID/wchan. [ tglx: Fixup coding style, move the timeout into the helper, adapt to test harness changes and massage change log ] Signed-off-by: Yuwen Chen <ywen.chen@foxmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/tencent_4C90BE98BBC48B38B9FBC6A95C45CF49F309@qq.com
2026-07-20x86/apic: Ensure ICR register write value is handled as 32 bitsMelody Wang
The low 32-bit ICR data is prepared by __prepare_ICR(), which returns a 32-bit value. However, when this value is assigned to a new variable, it's easy to mistakenly declare that variable with a different width. To avoid this class of mistakes, use __prepare_ICR() directly as the function argument instead of storing its result in an intermediate variable. This also shaves off a bunch of lines in the code. There should be no functionality change resulting from this. Signed-off-by: Melody Wang <huibo.wang@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260708012117.177959-1-huibo.wang@amd.com
2026-07-20ALSA: hda/tas2781: clear cali_data.total_sz when calibration read failsPhilipp Oster
tas2563_save_calibration() assigns cali_data.total_sz before it reads the per-device calibration data from EFI, but its error paths return without clearing it again. cali_data.cali_reg_array is left all zero, because the function returns before the register addresses are assigned. On the first playback tasdev_load_calibrated_data() does if (!data || !cali_data->total_sz) return; which passes, since total_sz is still non-zero. It then issues five 4-byte bulk writes to p->r0_reg, p->r0_low_reg, p->invr0_reg, p->pow_reg and p->tlimit_reg, all of which are 0. Register 0 decodes to book 0 / page 0 / register 0x00, so the auto-incrementing block write zeroes registers 0x00 to 0x03. Register 0x03 is PB_CFG1, which holds AMP_LEVEL, so the amplifier gain is set to its minimum and the speaker stays silent. This is reproducible on a Lenovo Yoga 7 14ARB7 (two TAS2563 on I2C, ACPI INT8866) whose factory calibration was never written to UEFI, so the EFI read fails with EFI_NOT_FOUND. The two woofers driven by the amplifiers are silent while the tweeters driven directly by the ALC287 play. Reading the amplifier registers over i2c shows PWR_CTL = 0x00 (active) and the TDM slots correctly programmed by the RCA profile, but PB_CFG1 = 0x00. With this change PB_CFG1 keeps its power-on default of 0x20 and both woofers play. tas2781_save_calibration() in tas2781_hda.c already clears total_sz on failure; do the same for the TAS2563 variant. Signed-off-by: Philipp Oster <philippdev5396@outlook.de> Link: https://patch.msgid.link/20260720-tas2781-calfix-v1-1-3a5fa6ad90bc@outlook.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-20ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Samsung 750XBE/730XBEZhang Heng
Add a codec SSID quirk for Samsung ELECTRONICS 750XBE/730XBE using HDA_CODEC_QUIRK() instead of SND_PCI_QUIRK(), because the alsa-info report from this device does not expose a PCI subsystem ID, only the HDA codec subsystem ID (0x144d:0xc824) is available. This applies ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET to fix sound being very low and distorted on the headphone jack of this system. Reported-by: Caio Ramos <caioramos97@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=208663 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260720123702.799474-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-20ALSA: hda/realtek: Fix speakers on Lunnen Ground 14Nikita Maksimov
The firmware on the Lunnen Ground 14 marks pin 0x1b as unused even though the internal speakers are connected to it. As a result, the speakers are not detected. Add a pin configuration quirk for PCI subsystem ID 2782:a212 to configure pin 0x1b as an internal speaker. The pin configuration was tested on a Lunnen Ground 14 (DMI product LL4FA) with an ALC269VC codec. The internal speakers and microphone work as expected. Cc: stable@vger.kernel.org Signed-off-by: Nikita Maksimov <nickstogramm@yandex.ru> Link: https://patch.msgid.link/20260720180214.73770-1-nickstogramm@yandex.ru Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-20selftests/rseq: Add missing test binaries to .gitignoreCihan Karadag
legacy_check and check_optimized are built by this Makefile via TEST_GEN_PROGS_EXTENDED but are not listed in .gitignore, causing them to show up as untracked files after a build. Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260705215346.1132764-1-cihan.cihan@gmail.com
2026-07-20entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall ↵Thomas Gleixner
execution The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Link: https://patch.msgid.link/20260712141346.772209074@kernel.org
2026-07-20entry: Make return type of syscall_trace_enter() boolThomas Gleixner
This prepares for changing the return types of syscall_enter_from_user_mode[_work]() to bool, which in turn separates the decision of invoking the syscall from the syscall number, which might have been changed in the call by ptrace, seccomp, tracing. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260712141346.699072205@kernel.org
2026-07-20entry: Rework trace_syscall_enter()Thomas Gleixner
Reread the syscall number from pt_regs and stop returning the eventually modified syscall number. That moves the reread to the end of syscall_trace_enter() and prepares for moving it to the call site. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260712141346.639115923@kernel.org
2026-07-20entry: Rework syscall_audit_enter()Thomas Gleixner
Move it out of line and let it reread the syscall number on it's own. That makes the low level entry code denser and allows to move the reread to the call site of syscall_trace_enter() once the tracer is fixed up. To prevent the compiler from putting audit_context() out of line and thereby breaking dead code elimination, mark audit_context() __always_inline. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260712141346.576865340@kernel.org
2026-07-20regcache: Warn if regcache_sync() is called in cache_only modeMark Brown
phucduc.bui@gmail.com <phucduc.bui@gmail.com> did a bit of work to help people avoid running into silly errors. Link: https://patch.msgid.link/20260720033238.52479-1-phucduc.bui@gmail.com
2026-07-20regcache: Validate cache_only state in regcache_sync_region()bui duc phuc
Add a WARN_ON() check to ensure regcache_sync_region() is not called while cache_only is enabled. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260720033238.52479-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-20regcache: Warn if regcache_sync() is called in cache_only modebui duc phuc
Calling regcache_sync() while cache_only is enabled is invalid API usage, since writes are intentionally kept in the cache and cannot be synchronized to hardware. Document that callers must disable cache_only before calling regcache_sync(), and reject incorrect usage with a WARN_ON() and -EINVAL. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260720033238.52479-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-20blk-crypto: Update docs for blk-crypto-fallback motivationEric Biggers
The "Objective" section of inline-encryption.rst suggests that blk-crypto-fallback is just for testing. That's no longer accurate, so update it accordingly. Also fix a typo later in the document. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-7-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20blk-crypto: Remove unused function blk_crypto_config_supported()Eric Biggers
blk_crypto_config_supported() is no longer called, so remove it. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Update docs for data pathEric Biggers
Update the "Data path changes" section to accurately document and elaborate on the current implementation of file contents en/decryption. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Remove unused function fscrypt_finalize_bounce_page()Eric Biggers
fscrypt_finalize_bounce_page() is no longer called, so remove it. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20f2fs: Update outdated comment in f2fs_write_begin()Eric Biggers
Refer to f2fs_set_bio_crypt_ctx() instead of the removed function f2fs_encrypt_one_page(). Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fs: Update outdated comment for SB_INLINECRYPTEric Biggers
Update the comment for SB_INLINECRYPT to match the latest code, where SB_INLINECRYPT now controls whether blk-crypto uses inline encryption hardware rather than whether blk-crypto is used. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Update encryption policy version docsEric Biggers
Update the wording of the documentation to put v1 encryption policies a bit more firmly in the past, explicitly calling them "deprecated" (which is consistent with the warning message the kernel has printed ever since v5.4). Do the same for FS_IOC_GET_ENCRYPTION_POLICY which supports only v1 policies, and remove the explicit recommendation to fall back to it. Also clarify that reusing master keys across policies isn't the best practice or normal usage, even though it's technically allowed for v2. Link: https://patch.msgid.link/20260718212526.53943-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Replace some variable-size memsets with fixed-sizeEric Biggers
For zeroing IVs and raw keys, remove the misguided optimization of zeroing the actual size used (typically 16 and 64 bytes respectively) instead of the max size (32 and 64 bytes respectively). Using a compile-time constant size allows the compiler to specialize the memset for that size (typically by inlining a few 'mov' instructions), which is more important than zeroing a few extra bytes with these small sizes. Link: https://patch.msgid.link/20260718205606.50713-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Add safety checks to non-block-based en/decryptionEric Biggers
fscrypt_encrypt_pagecache_blocks(), fscrypt_encrypt_block_inplace(), fscrypt_decrypt_block_inplace() would dereference a NULL fscrypt_inode_info pointer if they were to be called on a file that hasn't been opened yet or on a block-based filesystem. Since they have the ability to report errors anyway, add WARN_ON_ONCE checks for this. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-18-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Merge bio.c and inline_crypt.c into block.cEric Biggers
Now that fscrypt always uses blk-crypto on block-based filesystems, there's no meaningful difference between bio.c and inline_crypt.c. Therefore merge the two files into one named block.c. Note: I didn't carry over bio.c's "Copyright (C) 2015, Motorola Mobility", as none of the code that applied to remained. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-17-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Remove unused functions and workqueueEric Biggers
Remove functions that are no longer used: - fscrypt_decrypt_bio() - fscrypt_decrypt_pagecache_blocks() - fscrypt_inode_uses_fs_layer_crypto() - fscrypt_inode_uses_inline_crypto() - fscrypt_enqueue_decrypt_work() This makes the decryption workqueue unused, so remove it too. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-16-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Remove fs-layer zeroout codeEric Biggers
Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the fs-layer zeroout code in fs/crypto/bio.c is unused code. Remove it, then fold fscrypt_zeroout_range_inline_crypt() into fscrypt_zeroout_range(). Then make fscrypt_alloc_bounce_page() and fscrypt_crypt_data_unit() static, since they're no longer called from any other file. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-15-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Remove fscrypt_dio_supported()Eric Biggers
On block-based filesystems, fscrypt file contents encryption is now always implemented using blk-crypto. This implementation supports direct I/O. Therefore, fscrypt_dio_supported() now always returns true, except in the edge case where statx(STATX_DIOALIGN) is called on an encrypted regular file that hasn't had its key set up. But that was really a workaround rather than the desired behavior, so we can disregard it. Thus, fscrypt_dio_supported() is no longer needed. Remove it. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-14-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Replace calls to fscrypt_inode_uses_inline_crypto()Eric Biggers
Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the calls to fscrypt_inode_uses_inline_crypto() in fs/crypto/inline_crypt.c (which contains functions that are called only from block-based filesystems) are equivalent to checking whether the file is an encrypted regular file, i.e. fscrypt_needs_contents_encryption(). Use that instead. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-13-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fs/buffer: Remove fs-layer decryption codeEric Biggers
Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the fs-layer decryption code in fs/buffer.c is unused code. Remove it. Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-12-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20f2fs: Remove fs-layer file contents en/decryption codeEric Biggers
Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the fs-layer en/decryption code in f2fs is unused code. Remove it. Note that the struct f2fs_io_info field encrypted_page is kept because it is still used by the garbage collection path to relocate encrypted blocks using raw meta pages from META_MAPPING. Link: https://patch.msgid.link/20260713023708.9245-11-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>