]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
3 months agoMerge tag 'sound-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Linus Torvalds [Thu, 9 Apr 2026 18:17:16 +0000 (11:17 -0700)] 
Merge tag 'sound-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Still a bit higher amount than wished, but nothing looks really scary,
  and all changes are about nice and smooth device-specific fixes.

   - HD-audio quirks, one revert for a regression and another oneliner

   - AMD ACP quirks

   - Fixes for SDCA interrupt handling

   - A few Intel SOF, avs and NVL fixes

   - Fixes for TAS2552 DT, NAU8325, and STM32"

* tag 'sound-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms
  ASoC: SDCA: Unregister IRQ handlers on module remove
  ASoC: SDCA: mask Function_Status value
  ASoC: SDCA: Fix overwritten var within for loop
  ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J
  ASoC: SOF: Intel: hda: modify period size constraints for ACE4
  ALSA: hda/intel: enforce stricter period-size alignment for Intel NVL
  ASoC: nau8325: Add software reset during probe
  Revert "ALSA: hda/realtek: Add quirk for Gigabyte Technology to fix headphone"
  ASoC: Intel: avs: Fix memory leak in avs_register_i2s_test_boards()
  ASoC: SOF: Intel: fix iteration in is_endpoint_present()
  ASoC: SOF: Intel: Fix endpoint index if endpoints are missing
  ASoC: SDCA: Fix errors in IRQ cleanup
  ASoC: amd: acp: add Lenovo P16s G5 AMD quirk for legacy SDW machine
  ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
  ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10

3 months agoMerge tag 'mmc-v7.0-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Linus Torvalds [Thu, 9 Apr 2026 18:13:15 +0000 (11:13 -0700)] 
Merge tag 'mmc-v7.0-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

Pull MMC fixes from Ulf Hansson:

 - vub300: Fix use-after-free and NULL-deref on disconnect

* tag 'mmc-v7.0-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: vub300: fix use-after-free on disconnect
  mmc: vub300: fix NULL-deref on disconnect

3 months agoMerge tag 'pmdomain-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh...
Linus Torvalds [Thu, 9 Apr 2026 18:09:12 +0000 (11:09 -0700)] 
Merge tag 'pmdomain-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

Pull pmdomain fixes from Ulf Hansson:

 - imx: Prevent hang at power down for imx8mp-blk-ctrl

 - thead: Fix buffer overflow for TH1520 AON driver

 - Change Ulf Hansson's email

* tag 'pmdomain-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
  MAINTAINERS, mailmap: Change Ulf Hansson's email
  pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled
  firmware: thead: Fix buffer overflow and use standard endian macros

3 months agoMerge tag 'dma-mapping-7.0-2026-04-09' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Thu, 9 Apr 2026 18:02:35 +0000 (11:02 -0700)] 
Merge tag 'dma-mapping-7.0-2026-04-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux

Pull dma-mapping fix from Marek Szyprowski:
 "A fix for DMA-mapping subsystem, which hides annoying, false-positive
  warnings from DMA-API debug on coherent platforms like x86_64 (Mikhail
  Gavrilov)"

* tag 'dma-mapping-7.0-2026-04-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
  dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement

3 months agoarm64: mte: Skip TFSR_EL1 checks and barriers in synchronous tag check mode
Muhammad Usama Anjum [Wed, 11 Mar 2026 17:50:50 +0000 (17:50 +0000)] 
arm64: mte: Skip TFSR_EL1 checks and barriers in synchronous tag check mode

With KASAN_HW_TAGS (MTE) in synchronous mode, tag check faults are
reported as immediate Data Abort exceptions. The TFSR_EL1.TF1 bit is
never set since faults never go through the asynchronous path.
Therefore, reading TFSR_EL1 and executing data and instruction barriers
on kernel entry, exit, context switch and suspend is unnecessary
overhead.

As with the check_mte_async_tcf and clear_mte_async_tcf paths for
TFSRE0_EL1, extend the same optimisation to kernel entry/exit, context
switch and suspend.

All mte kselftests pass. The kunit before and after the patch show same
results.

A selection of test_vmalloc benchmarks running on a arm64 machine.
v6.19 is the baseline. (>0 is faster, <0 is slower, (R)/(I) =
statistically significant Regression/Improvement). Based on significance
and ignoring the noise, the benchmarks improved.

* 77 result classes were considered, with 9 wins, 0 losses and 68 ties

Results of fastpath [1] on v6.19 vs this patch:

+----------------------------+----------------------------------------------------------+------------+
| Benchmark                  | Result Class                                             |   barriers |
+============================+==========================================================+============+
| micromm/fork               | fork: p:1, d:10 (seconds)                                |  (I) 2.75% |
|                            | fork: p:512, d:10 (seconds)                              |      0.96% |
+----------------------------+----------------------------------------------------------+------------+
| micromm/munmap             | munmap: p:1, d:10 (seconds)                              |     -1.78% |
|                            | munmap: p:512, d:10 (seconds)                            |      5.02% |
+----------------------------+----------------------------------------------------------+------------+
| micromm/vmalloc            | fix_align_alloc_test: p:1, h:0, l:500000 (usec)          |     -0.56% |
|                            | fix_size_alloc_test: p:1, h:0, l:500000 (usec)           |      0.70% |
|                            | fix_size_alloc_test: p:4, h:0, l:500000 (usec)           |      1.18% |
|                            | fix_size_alloc_test: p:16, h:0, l:500000 (usec)          |     -5.01% |
|                            | fix_size_alloc_test: p:16, h:1, l:500000 (usec)          |     13.81% |
|                            | fix_size_alloc_test: p:64, h:0, l:100000 (usec)          |      6.51% |
|                            | fix_size_alloc_test: p:64, h:1, l:100000 (usec)          |     32.87% |
|                            | fix_size_alloc_test: p:256, h:0, l:100000 (usec)         |      4.17% |
|                            | fix_size_alloc_test: p:256, h:1, l:100000 (usec)         |      8.40% |
|                            | fix_size_alloc_test: p:512, h:0, l:100000 (usec)         |     -0.48% |
|                            | fix_size_alloc_test: p:512, h:1, l:100000 (usec)         |     -0.74% |
|                            | full_fit_alloc_test: p:1, h:0, l:500000 (usec)           |      0.53% |
|                            | kvfree_rcu_1_arg_vmalloc_test: p:1, h:0, l:500000 (usec) |     -2.81% |
|                            | kvfree_rcu_2_arg_vmalloc_test: p:1, h:0, l:500000 (usec) |     -2.06% |
|                            | long_busy_list_alloc_test: p:1, h:0, l:500000 (usec)     |     -0.56% |
|                            | pcpu_alloc_test: p:1, h:0, l:500000 (usec)               |     -0.41% |
|                            | random_size_align_alloc_test: p:1, h:0, l:500000 (usec)  |      0.89% |
|                            | random_size_alloc_test: p:1, h:0, l:500000 (usec)        |      1.71% |
|                            | vm_map_ram_test: p:1, h:0, l:500000 (usec)               |      0.83% |
+----------------------------+----------------------------------------------------------+------------+
| schbench/thread-contention | -m 16 -t 1 -r 10 -s 1000, avg_rps (req/sec)              |      0.05% |
|                            | -m 16 -t 1 -r 10 -s 1000, req_latency_p99 (usec)         |      0.60% |
|                            | -m 16 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec)      |      0.00% |
|                            | -m 16 -t 4 -r 10 -s 1000, avg_rps (req/sec)              |     -0.34% |
|                            | -m 16 -t 4 -r 10 -s 1000, req_latency_p99 (usec)         |     -0.58% |
|                            | -m 16 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec)      |      9.09% |
|                            | -m 16 -t 16 -r 10 -s 1000, avg_rps (req/sec)             |     -0.74% |
|                            | -m 16 -t 16 -r 10 -s 1000, req_latency_p99 (usec)        |     -1.40% |
|                            | -m 16 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec)     |      0.00% |
|                            | -m 16 -t 64 -r 10 -s 1000, avg_rps (req/sec)             |     -0.78% |
|                            | -m 16 -t 64 -r 10 -s 1000, req_latency_p99 (usec)        |     -0.11% |
|                            | -m 16 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec)     |      0.11% |
|                            | -m 16 -t 256 -r 10 -s 1000, avg_rps (req/sec)            |      2.64% |
|                            | -m 16 -t 256 -r 10 -s 1000, req_latency_p99 (usec)       |      3.15% |
|                            | -m 16 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec)    |     17.54% |
|                            | -m 32 -t 1 -r 10 -s 1000, avg_rps (req/sec)              |     -1.22% |
|                            | -m 32 -t 1 -r 10 -s 1000, req_latency_p99 (usec)         |      0.85% |
|                            | -m 32 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec)      |      0.00% |
|                            | -m 32 -t 4 -r 10 -s 1000, avg_rps (req/sec)              |     -0.34% |
|                            | -m 32 -t 4 -r 10 -s 1000, req_latency_p99 (usec)         |      1.05% |
|                            | -m 32 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec)      |      0.00% |
|                            | -m 32 -t 16 -r 10 -s 1000, avg_rps (req/sec)             |     -0.41% |
|                            | -m 32 -t 16 -r 10 -s 1000, req_latency_p99 (usec)        |      0.58% |
|                            | -m 32 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec)     |      2.13% |
|                            | -m 32 -t 64 -r 10 -s 1000, avg_rps (req/sec)             |      0.67% |
|                            | -m 32 -t 64 -r 10 -s 1000, req_latency_p99 (usec)        |      2.07% |
|                            | -m 32 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec)     |     -1.28% |
|                            | -m 32 -t 256 -r 10 -s 1000, avg_rps (req/sec)            |      1.01% |
|                            | -m 32 -t 256 -r 10 -s 1000, req_latency_p99 (usec)       |      0.69% |
|                            | -m 32 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec)    |     13.12% |
|                            | -m 64 -t 1 -r 10 -s 1000, avg_rps (req/sec)              |     -0.25% |
|                            | -m 64 -t 1 -r 10 -s 1000, req_latency_p99 (usec)         |     -0.48% |
|                            | -m 64 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec)      |     10.53% |
|                            | -m 64 -t 4 -r 10 -s 1000, avg_rps (req/sec)              |     -0.06% |
|                            | -m 64 -t 4 -r 10 -s 1000, req_latency_p99 (usec)         |      0.00% |
|                            | -m 64 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec)      |      0.00% |
|                            | -m 64 -t 16 -r 10 -s 1000, avg_rps (req/sec)             |     -0.36% |
|                            | -m 64 -t 16 -r 10 -s 1000, req_latency_p99 (usec)        |      0.52% |
|                            | -m 64 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec)     |      0.11% |
|                            | -m 64 -t 64 -r 10 -s 1000, avg_rps (req/sec)             |      0.52% |
|                            | -m 64 -t 64 -r 10 -s 1000, req_latency_p99 (usec)        |      3.53% |
|                            | -m 64 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec)     |     -0.10% |
|                            | -m 64 -t 256 -r 10 -s 1000, avg_rps (req/sec)            |      2.53% |
|                            | -m 64 -t 256 -r 10 -s 1000, req_latency_p99 (usec)       |      1.82% |
|                            | -m 64 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec)    |     -5.80% |
+----------------------------+----------------------------------------------------------+------------+
| syscall/getpid             | mean (ns)                                                | (I) 15.98% |
|                            | p99 (ns)                                                 | (I) 11.11% |
|                            | p99.9 (ns)                                               | (I) 16.13% |
+----------------------------+----------------------------------------------------------+------------+
| syscall/getppid            | mean (ns)                                                | (I) 14.82% |
|                            | p99 (ns)                                                 | (I) 17.86% |
|                            | p99.9 (ns)                                               |  (I) 9.09% |
+----------------------------+----------------------------------------------------------+------------+
| syscall/invalid            | mean (ns)                                                | (I) 17.78% |
|                            | p99 (ns)                                                 | (I) 11.11% |
|                            | p99.9 (ns)                                               |     13.33% |
+----------------------------+----------------------------------------------------------+------------+

[1] https://gitlab.arm.com/tooling/fastpath

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoerofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
Junrui Luo [Thu, 9 Apr 2026 13:59:39 +0000 (21:59 +0800)] 
erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()

Some crafted images can have illegal (!partial_decoding &&
m_llen < m_plen) extents, and the LZ4 inplace decompression path
can be wrongly hit, but it cannot handle (outpages < inpages)
properly: "outpages - inpages" wraps to a large value and
the subsequent rq->out[] access reads past the decompressed_pages
array.

However, such crafted cases can correctly result in a corruption
report in the normal LZ4 non-inplace path.

Let's add an additional check to fix this for backporting.

Reproducible image (base64-encoded gzipped blob):

H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g
dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i
PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz
2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w
ywAAAAAAAADwu14ATsEYtgBQAAA=

$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt
$ dd if=/mnt/data of=/dev/null bs=4096 count=1

Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
3 months agobitops: Update kernel-doc for sign_extendXX()
Andy Shevchenko [Tue, 7 Apr 2026 15:14:31 +0000 (17:14 +0200)] 
bitops: Update kernel-doc for sign_extendXX()

The sign_extendXX() lack of Return section and have other style
issues. Address that by updating kernel-doc accordingly.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agopowerpc/xive: simplify xive_spapr_debug_show()
Yury Norov [Tue, 3 Mar 2026 20:08:37 +0000 (15:08 -0500)] 
powerpc/xive: simplify xive_spapr_debug_show()

The function creates temporary buffer to convert xibm->bitmap to a
human-readable list before passing it to seq_printf. Drop it and print
the list by seq_printf() directly with the "%*pbl" specifier.

Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com> for powerpc patch
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agothermal: intel: switch cpumask_get() to using cpumask_print_to_pagebuf()
Yury Norov [Tue, 3 Mar 2026 20:08:38 +0000 (15:08 -0500)] 
thermal: intel: switch cpumask_get() to using cpumask_print_to_pagebuf()

The function opencodes cpumask_print_to_pagebuf() with more generic
bitmap_print_to_pagebuf(). Switch to using the proper API.

Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agocoresight: don't use bitmap_print_to_pagebuf()
Yury Norov [Tue, 3 Mar 2026 20:08:39 +0000 (15:08 -0500)] 
coresight: don't use bitmap_print_to_pagebuf()

Switch the driver to using the proper sysfs_emit("%*pbl") where
appropriate.

Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agolib/prime_numbers: drop temporary buffer in dump_primes()
Yury Norov [Tue, 3 Mar 2026 20:08:40 +0000 (15:08 -0500)] 
lib/prime_numbers: drop temporary buffer in dump_primes()

The function uses temporary buffer to convert primes bitmap into
human readable format. Switch to using kunit_info("%*pbl")", and
drop the buffer.

Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agodrm/xe: switch xe_pagefault_queue_init() to using bitmap_weighted_or()
Yury Norov [Mon, 2 Mar 2026 01:11:58 +0000 (20:11 -0500)] 
drm/xe: switch xe_pagefault_queue_init() to using bitmap_weighted_or()

The function calls bitmap_or() immediately followed by bitmap_weight().
Switch to using the dedicated bitmap_weighted_or() and save one bitmap
traverse.

Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agoice: use bitmap_empty() in ice_vf_has_no_qs_ena
Yury Norov [Mon, 2 Mar 2026 01:11:57 +0000 (20:11 -0500)] 
ice: use bitmap_empty() in ice_vf_has_no_qs_ena

bitmap_empty() is more verbose and efficient, as it stops traversing
{r,t}xq_ena as soon as the 1st set bit found.

Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agoice: use bitmap_weighted_xor() in ice_find_free_recp_res_idx()
Yury Norov [Mon, 2 Mar 2026 01:11:56 +0000 (20:11 -0500)] 
ice: use bitmap_weighted_xor() in ice_find_free_recp_res_idx()

Use the right helper and save one bitmaps traverse.

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Yury Norov <ynorov@nvidia.com>
3 months agoHID: logitech-hidpp: fix race condition when accessing stale stack pointer
Benoît Sevens [Wed, 1 Apr 2026 14:48:11 +0000 (14:48 +0000)] 
HID: logitech-hidpp: fix race condition when accessing stale stack pointer

The driver uses hidpp->send_receive_buf to point to a stack-allocated
buffer in the synchronous command path (__do_hidpp_send_message_sync).
However, this pointer is not cleared when the function returns.

If an event is processed (e.g. by a different thread) while the
send_mutex is held by a new command, but before that command has
updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
observe that the mutex is locked and dereference the stale pointer.

This results in an out-of-bounds access on a different thread's kernel
stack (or a NULL pointer dereference on the very first command).

Fix this by:
1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
   in the synchronous command path.
2. Moving the assignment of the local 'question' and 'answer' pointers
   inside the mutex_is_locked() block in the handler, and adding
   a NULL check before dereferencing.

Signed-off-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agocan: raw: fix ro->uniq use-after-free in raw_rcv()
Samuel Page [Wed, 8 Apr 2026 14:30:13 +0000 (15:30 +0100)] 
can: raw: fix ro->uniq use-after-free in raw_rcv()

raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
but receiver deletion is deferred with call_rcu(). This leaves a window
where raw_rcv() may still be running in an RCU read-side critical section
after raw_release() frees ro->uniq, leading to a use-after-free of the
percpu uniq storage.

Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
socket destructor. can_rx_unregister() takes an extra reference to the
socket and only drops it from the RCU callback, so freeing uniq from
sk_destruct ensures the percpu area is not released until the relevant
callbacks have drained.

Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters")
Cc: stable@vger.kernel.org # v4.1+
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>
Link: https://patch.msgid.link/26ec626d-cae7-4418-9782-7198864d070c@bynar.io
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
[mkl: applied manually]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 months agoi2c: spacemit: introduce pio for k1
Troy Mitchell [Sat, 7 Feb 2026 15:08:22 +0000 (23:08 +0800)] 
i2c: spacemit: introduce pio for k1

This patch introduces I2C PIO functionality for the Spacemit K1 SoC,
enabling the use of I2C in atomic context.

When i2c xfer_atomic is invoked, use_pio is set accordingly.

Since an atomic context is required, all interrupts are disabled when
operating in PIO mode. Even with interrupts disabled, the bits in the
ISR (Interrupt Status Register) will still be set, so error handling can
be performed by polling the relevant status bits in the ISR.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260207-b4-k3-i2c-pio-v7-2-626942d94d91@linux.spacemit.com
3 months agoi2c: spacemit: move i2c_xfer_msg()
Troy Mitchell [Sat, 7 Feb 2026 15:08:21 +0000 (23:08 +0800)] 
i2c: spacemit: move i2c_xfer_msg()

The upcoming PIO support requires a wait_pio_xfer() helper, which is
invoked from xfer_msg().

Since wait_pio_xfer() depends on err_check(), move the definition of
xfer_msg() after err_check() to avoid a forward declaration of
err_check().

Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Alex Elder <elder@riscstar.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260207-b4-k3-i2c-pio-v7-1-626942d94d91@linux.spacemit.com
3 months agocan: ucan: fix devres lifetime
Johan Hovold [Fri, 27 Mar 2026 10:45:20 +0000 (11:45 +0100)] 
can: ucan: fix devres lifetime

USB drivers bind to USB interfaces and any device managed resources
should have their lifetime tied to the interface rather than parent USB
device. This avoids issues like memory leaks when drivers are unbound
without their devices being physically disconnected (e.g. on probe
deferral or configuration changes).

Fix the control message buffer lifetime so that it is released on driver
unbind.

Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices")
Cc: stable@vger.kernel.org # 4.19
Cc: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260327104520.1310158-1-johan@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
3 months agoHID: winwing: Enable rumble effects
Ivan Gorinov [Sat, 7 Mar 2026 05:22:46 +0000 (05:22 +0000)] 
HID: winwing: Enable rumble effects

Enable rumble motor control on TGRIP-15E and TGRIP-15EX throttle grips
by sending haptic feedback commands (EV_FF events) to the input device.

Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: core: do not allow parsing 0-sized reports
Dmitry Torokhov [Wed, 1 Apr 2026 06:04:13 +0000 (23:04 -0700)] 
HID: core: do not allow parsing 0-sized reports

Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
reworked collection parsing code and inadvertently allowed returning
"success" when parsing 0-sized reports where old code returned -EINVAL.

Restore the original behavior by doing an explicit check.

Note that the error message now differs from the generic "item fetching
failed at offset %u/%u" that is now used only for non-empty descriptors.

Fixes: d7db259bd6df ("HID: core: factor out hid_parse_collections()")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: usbhid: refactor endpoint lookup
Johan Hovold [Mon, 30 Mar 2026 09:50:34 +0000 (11:50 +0200)] 
HID: usbhid: refactor endpoint lookup

Use the common USB helper for looking up interrupt-in endpoints instead
of open coding.

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: huawei: fix CD30 keyboard report descriptor issue
Miao Li [Wed, 18 Mar 2026 09:12:49 +0000 (17:12 +0800)] 
HID: huawei: fix CD30 keyboard report descriptor issue

When the Huawei CD30 USB keyboard undergoes 500 reboot cycles,
initialization may fail due to a report descriptor problem.
The error log is as follows:
[pid:175,cpu0,kworker/0:1,6]usb 1-1.2.2: new low-speed USB device number 6 using xhci-hcd
[pid:175,cpu0,kworker/0:1,9]usb 1-1.2.2: New USB device found, idVendor=12d1, idProduct=109b, bcdDevice= 1.03
[pid:175,cpu0,kworker/0:1,0]usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[pid:175,cpu0,kworker/0:1,1]usb 1-1.2.2: Product: HUAWEI USB Wired Keyboard
[pid:175,cpu0,kworker/0:1,2]usb 1-1.2.2: Manufacturer: HUAWEI
[pid:175,cpu0,kworker/0:1,4]input: HUAWEI HUAWEI USB Wired Keyboard as /devices/platform/efc00000.hisi_usb/efc00000.dwc3/xhci-hcd.1.auto/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:12D1:109B.0002/input/input6
[pid:175,cpu0,kworker/0:1,5]hid-generic 0003:12D1:109B.0002: input,hidraw1: USB HID v1.10 Keyboard [HUAWEI HUAWEI USB Wired Keyboard] on usb-xhci-hcd.1.auto-1.2.2/input0
[pid:175,cpu0,kworker/0:1,9]hid-generic 0003:12D1:109B.0003: collection stack underflow
[pid:175,cpu0,kworker/0:1,0]hid-generic 0003:12D1:109B.0003: item 0 0 0 12 parsing failed
[pid:175,cpu0,kworker/0:1,1]hid-generic: probe of 0003:12D1:109B.0003 failed with error -22
...
When encountering such a situation, fix it with the correct report descriptor.

Signed-off-by: Miao Li <limiao@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: playstation: validate num_touch_reports in DualShock 4 reports
Benoît Sevens [Mon, 23 Mar 2026 12:47:37 +0000 (12:47 +0000)] 
HID: playstation: validate num_touch_reports in DualShock 4 reports

The DualShock 4 HID driver fails to validate the num_touch_reports field
received from the device in both USB and Bluetooth input reports.
A malicious device could set this field to a value larger than the
allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
leading to an out-of-bounds read in dualshock4_parse_report().

This can result in kernel memory disclosure when processing malicious
HID reports.

Validate num_touch_reports against the array size for the respective
connection types before processing the touch data.

Signed-off-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: drop 'default !EXPERT' from tristate symbols
Thomas Weißschuh [Sat, 21 Mar 2026 13:15:45 +0000 (14:15 +0100)] 
HID: drop 'default !EXPERT' from tristate symbols

There is no reason to build random drivers for obscure hardware into the
core kernel by default.

The usages of 'default !EXPERT' for the HID_PICOLCD suboptions are kept,
as these make some sense, although they probably should use 'default y'.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agommc: sdhci-of-dwcmshc: Disable clock before DLL configuration
Shawn Lin [Wed, 8 Apr 2026 07:18:49 +0000 (15:18 +0800)] 
mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration

According to the ASIC design recommendations, the clock must be
disabled before operating the DLL to prevent glitches that could
affect the internal digital logic. In extreme cases, failing to
do so may cause the controller to malfunction completely.

Adds a step to disable the clock before DLL configuration and
re-enables it at the end.

Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
3 months agommc: core: Simplify with scoped for each OF child loop
Hans Zhang [Tue, 7 Apr 2026 01:40:33 +0000 (09:40 +0800)] 
mmc: core: Simplify with scoped for each OF child loop

Use scoped for-each loop when iterating over device nodes to simplify the
code, but also to ensure the device node reference is automatically
released when the loop scope ends.

Signed-off-by: Hans Zhang <18255117159@163.com>
Reviewed-by: Shawn Lin <shawn.lin@linux.dev>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
3 months agoarm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12
Mark Brown [Mon, 2 Mar 2026 22:53:21 +0000 (22:53 +0000)] 
arm64/sysreg: Update ID_AA64SMFR0_EL1 description to DDI0601 2025-12

The 2025 extensions add FEAT_SME2P3, including LUT6.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoarm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12
Mark Brown [Mon, 2 Mar 2026 22:53:20 +0000 (22:53 +0000)] 
arm64/sysreg: Update ID_AA64ZFR0_EL1 description to DDI0601 2025-12

The 2025 extensions add FEAT_SVE2P3 and FEAT_SVE_B16MM.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoarm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12
Mark Brown [Mon, 2 Mar 2026 22:53:19 +0000 (22:53 +0000)] 
arm64/sysreg: Update ID_AA64FPFR0_EL1 description to DDI0601 2025-12

The 2025 extensions add FEAT_F16MM and adjust some of the RES0 bits to be
RAZ instead as a placeholder for future extensions.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoarm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12
Mark Brown [Mon, 2 Mar 2026 22:53:18 +0000 (22:53 +0000)] 
arm64/sysreg: Update ID_AA64ISAR2_EL1 description to DDI0601 2025-12

The 2025 extensions update the LUT field for new instructions added by
SVE and SME 2.3, there is no separate FEAT_ feature for these.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoarm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12
Mark Brown [Mon, 2 Mar 2026 22:53:17 +0000 (22:53 +0000)] 
arm64/sysreg: Update ID_AA64ISAR0_EL1 description to DDI0601 2025-12

The 2025 extensions add FEAT_F16F32DOT and FEAT_F16F32MM.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agoarm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps
Mark Brown [Mon, 2 Mar 2026 22:53:16 +0000 (22:53 +0000)] 
arm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps

Currently for each hwcap we define both the HWCAPn_NAME definition which is
exposed to userspace and a kernel internal KERNEL_HWCAP_NAME definition
which we use internally. This is tedious and repetitive, instead use a
script to generate the KERNEL_HWCAP_ definitions from the UAPI definitions.

No functional changes intended.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 months agommc: core: Optimize size of struct mmc_queue_req
Bin Liu [Thu, 2 Apr 2026 12:31:55 +0000 (07:31 -0500)] 
mmc: core: Optimize size of struct mmc_queue_req

ioc_count won't be more than MMC_IOC_MAX_CMDS (255), retries won't be more
than MMC_NO_RETRIES (6), flags is newly introduced and uses only 1 bit.
Therefore let's change them all to become u8.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
3 months agoHID: usbhid: fix deadlock in hid_post_reset()
Oliver Neukum [Tue, 24 Mar 2026 14:24:54 +0000 (15:24 +0100)] 
HID: usbhid: fix deadlock in hid_post_reset()

You can build a USB device that includes a HID component
and a storage or UAS component. The components can be reset
only together. That means that hid_pre_reset() and hid_post_reset()
are in the block IO error handling. Hence no memory allocation
used in them may do block IO because the IO can deadlock
on the mutex held while resetting a device and calling the
interface drivers.
Use GFP_NOIO for all allocations in them.

Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoRDMA/ionic: bound node_desc sysfs read with %.64s
Kai Zen [Tue, 7 Apr 2026 09:20:22 +0000 (12:20 +0300)] 
RDMA/ionic: bound node_desc sysfs read with %.64s

node_desc[64] in struct ib_device is not guaranteed to be NUL-
terminated. The core IB sysfs handler uses "%.64s" for exactly this
reason (drivers/infiniband/core/sysfs.c:1307), since node_desc_store()
performs a raw memcpy of up to IB_DEVICE_NODE_DESC_MAX bytes with no NUL
termination:

  memcpy(desc.node_desc, buf, min_t(int, count, IB_DEVICE_NODE_DESC_MAX));

If exactly 64 bytes are written via the node_desc sysfs file, the array
contains no NUL byte. The ionic hca_type_show() handler uses unbounded
"%s" and will read past the end of node_desc into adjacent fields of
struct ib_device until it encounters a NUL.

ionic supports IB_DEVICE_MODIFY_NODE_DESC, so this is triggerable by
userspace.

Match the core handler and bound the format specifier.

Cc: stable@vger.kernel.org
Fixes: 2075bbe8ef03 ("RDMA/ionic: Register device ops for miscellaneous functionality")
Link: https://patch.msgid.link/r/CALynFi7NAbhDCt1tdaDbf6TnLvAqbaHa6-Wqf6OkzREbA_PAfg@mail.gmail.com
Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
3 months agoHID: apple: ensure the keyboard backlight is off if suspending
Aditya Garg [Sat, 4 Apr 2026 09:44:34 +0000 (15:14 +0530)] 
HID: apple: ensure the keyboard backlight is off if suspending

Some users reported that upon suspending their keyboard backlight
remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag.

Cc: stable@vger.kernel.org
Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs")
Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.")
Reported-by: André Eikmeyer <andre.eikmeyer@gmail.com>
Tested-by: André Eikmeyer <andre.eikmeyer@gmail.com>
Signed-off-by: Aditya Garg <gargaditya08@live.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
Nícolas F. R. A. Prado [Tue, 7 Apr 2026 20:59:28 +0000 (16:59 -0400)] 
HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER

The Logitech Bolt receiver once connected to a wireless device will
generate data on interface 2. If this data isn't polled, when the USB
port it is connected to gets suspended (and if that happens within 5
minutes of the last input from the wireless device), it will trigger a
remote wakeup 3 seconds later, which will result in a spurious system
wakeup if the port was suspended as part of system sleep.

Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
always polled and this spurious wakeup never happens.

With this change in place the system can be suspended with the receiver
plugged in and the system can be woken up when an input is sent from the
wireless device.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoMerge tag 'net-7.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Linus Torvalds [Thu, 9 Apr 2026 15:39:25 +0000 (08:39 -0700)] 
Merge tag 'net-7.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Pull networking fixes from Paolo Abeni:
 "Including fixes from netfilter, IPsec and wireless. This is again
  considerably bigger than the old average. No known outstanding
  regressions.

  Current release - regressions:

   - net: increase IP_TUNNEL_RECURSION_LIMIT to 5

   - eth: ice: fix PTP timestamping broken by SyncE code on E825C

  Current release - new code bugs:

   - eth: stmmac: dwmac-motorcomm: fix eFUSE MAC address read failure

  Previous releases - regressions:

   - core: fix cross-cache free of KFENCE-allocated skb head

   - sched: act_csum: validate nested VLAN headers

   - rxrpc: fix call removal to use RCU safe deletion

   - xfrm:
      - wait for RCU readers during policy netns exit
      - fix refcount leak in xfrm_migrate_policy_find

   - wifi: rt2x00usb: fix devres lifetime

   - mptcp: fix slab-use-after-free in __inet_lookup_established

   - ipvs: fix NULL deref in ip_vs_add_service error path

   - eth:
      - airoha: fix memory leak in airoha_qdma_rx_process()
      - lan966x: fix use-after-free and leak in lan966x_fdma_reload()

  Previous releases - always broken:

   - ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()

   - ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group
     dump

   - bridge: guard local VLAN-0 FDB helpers against NULL vlan group

   - xsk: tailroom reservation and MTU validation

   - rxrpc:
      - fix to request an ack if window is limited
      - fix RESPONSE authenticator parser OOB read

   - netfilter: nft_ct: fix use-after-free in timeout object destroy

   - batman-adv: hold claim backbone gateways by reference

   - eth:
      - stmmac: fix PTP ref clock for Tegra234
      - idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
      - ipa: fix GENERIC_CMD register field masks for IPA v5.0+"

* tag 'net-7.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (104 commits)
  net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()
  net: lan966x: fix page pool leak in error paths
  net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()
  nfc: pn533: allocate rx skb before consuming bytes
  l2tp: Drop large packets with UDP encap
  net: ipa: fix event ring index not programmed for IPA v5.0+
  net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
  MAINTAINERS: Add Prashanth as additional maintainer for amd-xgbe driver
  devlink: Fix incorrect skb socket family dumping
  af_unix: read UNIX_DIAG_VFS data under unix_state_lock
  Revert "mptcp: add needs_id for netlink appending addr"
  mptcp: fix slab-use-after-free in __inet_lookup_established
  net: txgbe: leave space for null terminators on property_entry
  net: ioam6: fix OOB and missing lock
  rxrpc: proc: size address buffers for %pISpc output
  rxrpc: only handle RESPONSE during service challenge
  rxrpc: Fix buffer overread in rxgk_do_verify_authenticator()
  rxrpc: Fix leak of rxgk context in rxgk_verify_response()
  rxrpc: Fix integer overflow in rxgk_verify_response()
  rxrpc: Fix missing error checks for rxkad encryption/decryption failure
  ...

3 months agoHID: alps: fix NULL pointer dereference in alps_raw_event()
Greg Kroah-Hartman [Mon, 6 Apr 2026 14:03:25 +0000 (16:03 +0200)] 
HID: alps: fix NULL pointer dereference in alps_raw_event()

Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.

Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.

Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoMerge tag 'iommu-fixes-v7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Thu, 9 Apr 2026 15:36:31 +0000 (08:36 -0700)] 
Merge tag 'iommu-fixes-v7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux

Pull IOMMU fix from Will Deacon:

 - Fix regression introduced by the empty MMU gather fix in -rc7, where
   the ->iotlb_sync() callback can be elided incorrectly, resulting in
   boot failures (hangs), crashes and potential memory corruption.

* tag 'iommu-fixes-v7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux:
  iommu: Ensure .iotlb_sync is called correctly

3 months agoHID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
Lee Jones [Tue, 24 Mar 2026 14:36:44 +0000 (14:36 +0000)] 
HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write

logi_dj_recv_send_report() assumes that all incoming REPORT_ID_DJ_SHORT
reports are 14 Bytes (DJREPORT_SHORT_LENGTH - 1) long.  It uses that
assumption to load the associated field's 'value' array with 14 Bytes of
data.  However, if a malicious user only sends say 1 Byte of data,
'report_count' will be 1 and only 1 Byte of memory will be allocated to
the 'value' Byte array.  When we come to populate 'value[1-13]' we will
experience an OOB write.

Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: logitech-dj: Standardise hid_report_enum variable nomenclature
Lee Jones [Tue, 24 Mar 2026 14:36:43 +0000 (14:36 +0000)] 
HID: logitech-dj: Standardise hid_report_enum variable nomenclature

Since we will need to differentiate between the two report_enum types
soon, let's unify the naming conventions now to save confusion and/or
unnecessary/unrelated changes in upcoming commits.

{input,output}_report_enum is used in other places to let's conform.

Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoMerge tag 'platform-drivers-x86-v7.0-4' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Thu, 9 Apr 2026 15:34:08 +0000 (08:34 -0700)] 
Merge tag 'platform-drivers-x86-v7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform drivers fixes from Ilpo Järvinen:

 - amd/pmc: Add Thinkpad L14 Gen3 to quirk_s2idle_bug

 - asus-armoury: Add support for FA607NU, GU605MU, and GV302XU.

 - intel-uncore-freq: Handle autonomous UFS status bit

 - ISST: Handle cases with less than max buckets correctly

 - intel-uncore-freq & ISST: Mark minor version 3 supported (no
   additional driver changes required)

* tag 'platform-drivers-x86-v7.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
  platform/x86: asus-armoury: add support for GU605MU
  platform/x86: asus-armoury: add support for FA607NU
  platform/x86: asus-armoury: add support for GV302XU
  platform/x86/amd: pmc: Add Thinkpad L14 Gen3 to quirk_s2idle_bug
  platform/x86/intel-uncore-freq: Increase minor version
  platform/x86: ISST: Increase minor version
  platform/x86/intel-uncore-freq: Handle autonomous UFS status bit
  platform/x86: ISST: Reset core count to 0

3 months agoHID: sony: update module description
Rosalie Wanders [Thu, 2 Apr 2026 15:59:15 +0000 (17:59 +0200)] 
HID: sony: update module description

This commit updates the hid-sony module description to make it correct
with the recent hid-sony changes alongside making it more consistent.

Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoHID: logitech-hidpp: Check bounds when deleting force-feedback effects
Günther Noack [Tue, 31 Mar 2026 07:40:51 +0000 (09:40 +0200)] 
HID: logitech-hidpp: Check bounds when deleting force-feedback effects

Without this bounds check, this might otherwise overwrite index -1.

Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.

Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
3 months agoIB/core: Fix zero dmac race in neighbor resolution
Chen Zhao [Sun, 5 Apr 2026 15:44:55 +0000 (18:44 +0300)] 
IB/core: Fix zero dmac race in neighbor resolution

dst_fetch_ha() checks nud_state without holding the neighbor lock, then
copies ha under the seqlock. A race in __neigh_update() where nud_state
is set to NUD_REACHABLE before ha is written allows dst_fetch_ha() to
read a zero MAC address while the seqlock reports no concurrent writer.

netevent_callback amplifies this by waking ALL pending addr_req workers
when ANY neighbor becomes NUD_VALID. At scale (N peers resolving ARP
concurrently), the hit probability scales as N^2, making it near-certain
for large RDMA workloads.

N(A): neigh_update(A)                   W(A): addr_resolve(A)
 |                                       [sleep]
 | write_lock_bh(&A->lock)               |
 | A->nud_state = NUD_REACHABLE          |
 | // A->ha is still 0                   |
 |                                       [woken by netevent_cb() of
 |                                         another neighbour]
 |                                       | dst_fetch_ha(A)
 |                                       |   A->nud_state & NUD_VALID
 |                                       |   read_seqbegin(&A->ha_lock)
 |                                       |   snapshot = A->ha  /* 0 */
 |                                       |   read_seqretry(&A->ha_lock)
 |                                       |   return snapshot
 | seqlock(&A->ha_lock)
 | A->ha = mac_A     /* too late */
 | sequnlock(&A->ha_lock)
 | write_unlock_bh(&A->lock)

The incorrect/zero mac is read and programmed in the device QP while it
was not yet updated. This causes silent packet loss and eventual
RETRY_EXC_ERR.

Fix by holding the neighbor read lock across the nud_state check and
ha copy in dst_fetch_ha(), ensuring it synchronizes with
__neigh_update() which is updating while holding the write lock.

Cc: stable@vger.kernel.org
Fixes: 92ebb6a0a13a ("IB/cm: Remove now useless rcu_lock in dst_fetch_ha")
Link: https://patch.msgid.link/r/20260405-fix-dmac-race-v1-1-cfa1ec2ce54a@nvidia.com
Signed-off-by: Chen Zhao <chezhao@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
3 months agoefi: Tag memblock reservations of boot services regions as RSRV_KERN
Ard Biesheuvel [Wed, 25 Feb 2026 11:03:04 +0000 (12:03 +0100)] 
efi: Tag memblock reservations of boot services regions as RSRV_KERN

By definition, EFI memory regions of type boot services code or data
have no special significance to the firmware at runtime, only to the OS.
In some cases, the firmware will allocate tables and other assets that
are passed in memory in regions of this type, and leave it up to the OS
to decide whether or not to treat the allocation as special, or simply
consume the contents at boot and recycle the RAM for ordinary use. The
reason for this approach is that it avoids needless memory reservations
for assets that the OS knows nothing about, and therefore doesn't know
how to free either.

This means that any memblock reservations covering such regions can be
marked as MEMBLOCK_RSRV_KERN - this is a better match semantically, and
is useful on x86 to distinguish true reservations from temporary
reservations that are only needed to work around firmware bugs.

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
3 months agomemblock: Permit existing reserved regions to be marked RSRV_KERN
Ard Biesheuvel [Wed, 25 Feb 2026 12:39:48 +0000 (13:39 +0100)] 
memblock: Permit existing reserved regions to be marked RSRV_KERN

Permit existing memblock reservations to be marked as RSRV_KERN. This
will be used by the EFI code on x86 to distinguish between reservations
of boot services data regions that have actual significance to the
kernel and regions that are reserved temporarily to work around buggy
firmware.

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
3 months agodrm/i915/wm: Allow SAGV with multiple pipes on pre-icl
Ville Syrjälä [Tue, 24 Mar 2026 13:48:43 +0000 (15:48 +0200)] 
drm/i915/wm: Allow SAGV with multiple pipes on pre-icl

There was never any documented reason for limiting SAGV to
single active pipe configuration on pre-icl. Allow SAGV
with multiple active pipes.

At least my CFL NUC seems happy with this when using
multiple displays. The machine actually has working
SAGV because the memory clock can be observed changing
via SA_PERF_STATUS/mchbar:0x5918.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-10-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Reduce copy-pasta in skl_print_plane_wm_changes()
Ville Syrjälä [Tue, 24 Mar 2026 13:48:42 +0000 (15:48 +0200)] 
drm/i915/wm: Reduce copy-pasta in skl_print_plane_wm_changes()

skl_print_plane_wm_changes() is rather ugly with the copy-pasted
massive printk arguments. Reduce the duplication a bit by defining
a few FMT/ARG macros. Still ugly, but perhaps a bit less fragile.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-9-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Verify 'ddb_y' as well as 'ddb'
Ville Syrjälä [Tue, 24 Mar 2026 13:48:41 +0000 (15:48 +0200)] 
drm/i915/wm: Verify 'ddb_y' as well as 'ddb'

Verify the pre-icl NV12 Y color plane DDB entry. Thus far
we've only verified the RGB/UV DDB entry.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-8-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Extract skl_ddb_entry_verify()
Ville Syrjälä [Tue, 24 Mar 2026 13:48:40 +0000 (15:48 +0200)] 
drm/i915/wm: Extract skl_ddb_entry_verify()

Extract the DDB entry verification to a helper function.
We'll have another caller soon.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-7-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Extract skl_wm_level_verify()
Ville Syrjälä [Tue, 24 Mar 2026 13:48:39 +0000 (15:48 +0200)] 
drm/i915/wm: Extract skl_wm_level_verify()

Reduce duplicated code by extracting the code to
verify a single WM level to a common function.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-6-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Verify the correct plane DDB entry
Ville Syrjälä [Tue, 24 Mar 2026 13:48:38 +0000 (15:48 +0200)] 
drm/i915/wm: Verify the correct plane DDB entry

Actually verify the DDB entry for the plane we're looking
at instead of always verifying the cursor DDB.

Fixes: 7d4561722c3b ("drm/i915: Tweak plane ddb allocation tracking")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-5-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Consolidate SAGV pipe active/interlace checks to common code
Ville Syrjälä [Tue, 24 Mar 2026 13:48:37 +0000 (15:48 +0200)] 
drm/i915/wm: Consolidate SAGV pipe active/interlace checks to common code

There are no differences between the platforms when
considering whether SAGV can be used when the pipe is
inactive or using an interlaced mode. Consolidate the
checks to common code.

Note that we weren't even checking for interlaced modes
on TGL+, but since we've previously soft defeatured
interlaced modes on TGL+ that was more or less fine.
The hardware does still have the capability though,
and in case we ever decide to resurrect it having the
check seems like a good idea.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-4-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Don't compute separate SAGV watermarks for RKL
Ville Syrjälä [Tue, 24 Mar 2026 13:48:36 +0000 (15:48 +0200)] 
drm/i915/wm: Don't compute separate SAGV watermarks for RKL

RKL is supposed to use the old SKL/ICL method for determining
whether the watermarks tolerate SAGV or not, not the TGL+ method.
Make it so.

BSpec: 49325
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-3-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agodrm/i915/wm: Reject SAGV consistently when block_time_us==0
Ville Syrjälä [Tue, 24 Mar 2026 13:48:35 +0000 (15:48 +0200)] 
drm/i915/wm: Reject SAGV consistently when block_time_us==0

We have three ways for the platform to indicate that
SAGV is not supported:
- pcode returns zero block time
- pcode returns only a single QGV point (icl+)
- pcode rejects the SAGV enable/disable command (pre-icl)

We don't currently consider all those factors when computing
pipe_sagv_reject, meaning we might still try to enable
SAGV when we should not.

I think one plausible scenario is when pcode returns a
zero block time, and all the pipes are disabled. In
that case intel_crtc_can_enable_sagv() will return true
for all pipes, and thus we might try to enable SAGV
despite pcode indicating that it's not supported.

Make sure pipe_sagv_reject will consistently reject
SAGV when our cached block time is zero. That will cover
all the aforementioned mechanisms by which SAGV can be
disabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260324134843.2364-2-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
3 months agojbd2: store jinode dirty range in PAGE_SIZE units
Li Chen [Fri, 6 Mar 2026 08:56:42 +0000 (16:56 +0800)] 
jbd2: store jinode dirty range in PAGE_SIZE units

jbd2_inode fields are updated under journal->j_list_lock, but some paths
read them without holding the lock (e.g. fast commit helpers and ordered
truncate helpers).

READ_ONCE() alone is not sufficient for the dirty range fields when they
are stored as loff_t because 32-bit platforms can observe torn loads.
Store the dirty range in PAGE_SIZE units as pgoff_t instead.

Represent the dirty range end as an exclusive end page. This avoids a
special sentinel value and keeps MAX_LFS_FILESIZE on 32-bit representable.

Publish a new dirty range by updating end_page before start_page, and
treat start_page >= end_page as empty in the accessor for robustness.

Use READ_ONCE() on the read side and WRITE_ONCE() on the write side for the
dirty range and i_flags to match the existing lockless access pattern.

Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Li Chen <me@linux.beauty>
Link: https://patch.msgid.link/20260306085643.465275-5-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoocfs2: use jbd2 jinode dirty range accessor
Li Chen [Fri, 6 Mar 2026 08:56:41 +0000 (16:56 +0800)] 
ocfs2: use jbd2 jinode dirty range accessor

ocfs2 journal commit callback reads jbd2_inode dirty range fields without
holding journal->j_list_lock.
Use jbd2_jinode_get_dirty_range() to get the range in bytes.

Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Li Chen <me@linux.beauty>
Link: https://patch.msgid.link/20260306085643.465275-4-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoext4: use jbd2 jinode dirty range accessor
Li Chen [Fri, 6 Mar 2026 08:56:40 +0000 (16:56 +0800)] 
ext4: use jbd2 jinode dirty range accessor

ext4 journal commit callbacks access jbd2_inode dirty range fields without
holding journal->j_list_lock.
Use jbd2_jinode_get_dirty_range() to get the range in bytes, and read
i_transaction with READ_ONCE() in the redirty check.

Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Li Chen <me@linux.beauty>
Link: https://patch.msgid.link/20260306085643.465275-3-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agojbd2: add jinode dirty range accessors
Li Chen [Fri, 6 Mar 2026 08:56:39 +0000 (16:56 +0800)] 
jbd2: add jinode dirty range accessors

Provide a helper to fetch jinode dirty ranges in bytes. This lets
filesystem callbacks avoid depending on the internal representation,
preparing for a later conversion to page units.

Suggested-by: Andreas Dilger <adilger@dilger.ca>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Li Chen <me@linux.beauty>
Link: https://patch.msgid.link/20260306085643.465275-2-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agotracing: Documentation: Update histogram-design.rst for fn() handling
Steven Rostedt [Mon, 26 Jan 2026 23:17:42 +0000 (18:17 -0500)] 
tracing: Documentation: Update histogram-design.rst for fn() handling

The histogram documentation describes the old method of the histogram
triggers using the fn() field of the histogram field structure to process
the field. But due to Spectre mitigation, the function pointer to handle
the fields at runtime caused a noticeable overhead. It was converted over
to a fn_num and hist_fn_call() is now used to call the specific functions
for the fields via a switch statement based on the field's fn_num value.

Update the documentation to reflect this change.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260126181742.03e8f0d5@gandalf.local.home>

3 months agojbd2: gracefully abort on transaction state corruptions
Milos Nikic [Wed, 4 Mar 2026 17:20:16 +0000 (09:20 -0800)] 
jbd2: gracefully abort on transaction state corruptions

Auditing the jbd2 codebase reveals several legacy J_ASSERT calls
that enforce internal state machine invariants (e.g., verifying
jh->b_transaction or jh->b_next_transaction pointers).

When these invariants are broken, the journal is in a corrupted
state. However, triggering a fatal panic brings down the entire
system for a localized filesystem error.

This patch targets a specific class of these asserts: those
residing inside functions that natively return integer error codes,
booleans, or error pointers. It replaces the hard J_ASSERTs with
WARN_ON_ONCE to capture the offending stack trace, safely drops
any held locks, gracefully aborts the journal, and returns -EINVAL.

This prevents a catastrophic kernel panic while ensuring the
corrupted journal state is safely contained and upstream callers
(like ext4 or ocfs2) can gracefully handle the aborted handle.

Functions modified in fs/jbd2/transaction.c:
- jbd2__journal_start()
- do_get_write_access()
- jbd2_journal_dirty_metadata()
- jbd2_journal_forget()
- jbd2_journal_try_to_free_buffers()
- jbd2_journal_file_inode()

Signed-off-by: Milos Nikic <nikic.milos@gmail.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://patch.msgid.link/20260304172016.23525-3-nikic.milos@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agojbd2: gracefully abort instead of panicking on unlocked buffer
Milos Nikic [Wed, 4 Mar 2026 17:20:15 +0000 (09:20 -0800)] 
jbd2: gracefully abort instead of panicking on unlocked buffer

In jbd2_journal_get_create_access(), if the caller passes an unlocked
buffer, the code currently triggers a fatal J_ASSERT.

While an unlocked buffer here is a clear API violation and a bug in the
caller, crashing the entire system is an overly severe response. It brings
down the whole machine for a localized filesystem inconsistency.

Replace the J_ASSERT with a WARN_ON_ONCE to capture the offending caller's
stack trace, and return an error (-EINVAL). This allows the journal to
gracefully abort the transaction, protecting data integrity without
causing a kernel panic.

Signed-off-by: Milos Nikic <nikic.milos@gmail.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://patch.msgid.link/20260304172016.23525-2-nikic.milos@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agodocs: sysctl: Add documentation for /proc/sys/xen/
Shubham Chakraborty [Wed, 4 Mar 2026 15:04:19 +0000 (20:34 +0530)] 
docs: sysctl: Add documentation for /proc/sys/xen/

Add documentation for the Xen hypervisor sysctl controls in
/proc/sys/xen/balloon/.

Documents the hotplug_unpopulated tunable (available when
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled) which controls
whether unpopulated memory regions are automatically hotplugged
when the Xen balloon driver needs to reclaim memory.

The documentation is based on source code analysis of
drivers/xen/balloon.c.

Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260304150419.16738-1-chakrabortyshubham66@gmail.com>

3 months agoext4: simplify mballoc preallocation size rounding for small files
Weixie Cui [Wed, 25 Feb 2026 05:02:31 +0000 (13:02 +0800)] 
ext4: simplify mballoc preallocation size rounding for small files

The if-else ladder in ext4_mb_normalize_request() manually rounds up
the preallocation size to the next power of two for files up to 1MB,
enumerating each step from 16KB to 1MB individually. Replace this with
a single roundup_pow_of_two() call clamped to a 16KB minimum, which
is functionally equivalent but much more concise.

Also replace raw byte constants with SZ_1M and SZ_16K from
<linux/sizes.h> for clarity, and remove the stale "XXX: should this
table be tunable?" comment that has been there since the original
mballoc code.

No functional change.

Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Weixie Cui <cuiweixie@gmail.com>
Link: https://patch.msgid.link/tencent_E9C5F1B2E9939B3037501FD04A7E9CF0C407@qq.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoDocs: hid: intel-ish-hid: make long URL usable
Randy Dunlap [Sat, 21 Mar 2026 23:09:34 +0000 (16:09 -0700)] 
Docs: hid: intel-ish-hid: make long URL usable

The '\' line continuation character in this long URL
doesn't help anything. There is no documentation tooling that
handles the line continuation character to join the 2 lines
to make a usable URL. Web browsers terminate the URL just
before the '\' character so that the second line of the URL
is lost. See:
  https://docs.kernel.org/hid/intel-ish-hid.html

Join the 2 lines together so that the URL is usable.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260321230934.435020-1-rdunlap@infradead.org>

3 months agoext4/move_extent: use folio_next_pos()
Julia Lawall [Sun, 22 Feb 2026 12:50:49 +0000 (13:50 +0100)] 
ext4/move_extent: use folio_next_pos()

A series of patches such as commit 60a70e61430b ("mm: Use
folio_next_pos()") replace folio_pos() + folio_size() by
folio_next_pos().  The former performs x << z + y << z while
the latter performs (x + y) << z, which is slightly more
efficient. This case was not taken into account, perhaps
because the argument is not named folio.

The change was performed using the following Coccinelle
semantic patch:

@@
expression folio;
@@

- folio_pos(folio) + folio_size(folio)
+ folio_next_pos(folio)

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20260222125049.1309075-1-Julia.Lawall@inria.fr
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoALSA: hda/alc269: Drop superfluous GPIO write at resume
Takashi Iwai [Thu, 9 Apr 2026 14:37:29 +0000 (16:37 +0200)] 
ALSA: hda/alc269: Drop superfluous GPIO write at resume

alc269_resume() has an extra code to write GPIO data, but this is
basically already done in the standard alc_init(), hence it's
superfluous.  Let's drop the code.

Since all external callers of alc_write_gpio_data() are gone after
this, fold the only usage of alc_write_gpio_data() into the caller and
drop the export as well.

Link: https://patch.msgid.link/20260409143735.1412134-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
3 months agoALSA: usb-audio: Add quirk flags for Feaulle Rainbow
Rong Zhang [Wed, 8 Apr 2026 18:33:05 +0000 (02:33 +0800)] 
ALSA: usb-audio: Add quirk flags for Feaulle Rainbow

Feaulle Rainbow is a wired USB-C dynamic in-ear monitor (IEM) featuring
active noise cancellation (ANC).

The supported sample rates are 48000Hz and 96000Hz at 16bit or 24bit,
but it does not support reading the current sample rate and results in
an error message printed to kmsg. Set QUIRK_FLAG_GET_SAMPLE_RATE to skip
the sample rate check.

Its playback mixer reports val = -15360/0/128. Setting -15360 (-60dB)
mutes the playback, so QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE is needed.

Add a quirk table entry matching VID/PID=0x0e0b/0xfa01 and applying
the mentioned quirk flags, so that it can work properly.

Quirky device sample:

  usb 7-1: New USB device found, idVendor=0e0b, idProduct=fa01, bcdDevice= 1.00
  usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 7-1: Product: Feaulle Rainbow
  usb 7-1: Manufacturer: Generic
  usb 7-1: SerialNumber: 20210726905926

Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260409-feaulle-rainbow-v1-1-09179e09000d@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
3 months agoDocumentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass
Li RongQing [Mon, 30 Mar 2026 10:59:57 +0000 (06:59 -0400)] 
Documentation/kernel-parameters: fix architecture alignment for pt, nopt, and nobypass

Commit ab0e7f20768a ("Documentation: Merge x86-specific boot options doc
into kernel-parameters.txt") introduced a formatting regression where
architecture tags were placed on separate lines with broken indentation.
This caused the 'nopt' [X86] parameter to appear as if it belonged to
the [PPC/POWERNV] section.

Furthermore, since the main 'iommu=' parameter heading already specifies
it is for [X86, EARLY], the subsequent standalone [X86] tags for 'pt',
'nopt', and the AMD GART options are redundant and clutter the
documentation.

Clean up the formatting by removing these redundant tags and properly
attributing the 'nobypass' option to [PPC/POWERNV].

Fixes: ab0e7f20768a ("Documentation: Merge x86-specific boot options doc into kernel-parameters.txt")
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260330105957.2271-1-lirongqing@baidu.com>

3 months agoext4: remove tl argument from ext4_fc_replay_{add,del}_range
Guoqing Jiang [Wed, 21 Jan 2026 06:38:05 +0000 (14:38 +0800)] 
ext4: remove tl argument from ext4_fc_replay_{add,del}_range

Since commit a7ba36bc94f2 ("ext4: fix fast commit alignment issues"),
both ext4_fc_replay_add_range and ext4_fc_replay_del_range get
ex based on 'val' instead of 'tl'.

Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20260121063805.19863-1-guoqing.jiang@linux.dev
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoext4: remove unused i_fc_wait
Li Chen [Tue, 20 Jan 2026 12:19:41 +0000 (20:19 +0800)] 
ext4: remove unused i_fc_wait

i_fc_wait is only initialized in ext4_fc_init_inode() and never used for
waiting or wakeups. Drop it.

Signed-off-by: Li Chen <me@linux.beauty>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20260120121941.144192-1-me@linux.beauty
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agoefi/memattr: Fix thinko in table size sanity check
Ard Biesheuvel [Thu, 26 Mar 2026 13:26:57 +0000 (14:26 +0100)] 
efi/memattr: Fix thinko in table size sanity check

While it is true that each PE/COFF runtime driver in memory can
generally be split into 3 different regions (the header, the code/rodata
region and the data/bss region), each with different permissions, it
does not mean that 3x the size of the memory map is a suitable upper
bound. This is due to the fact that all runtime drivers could be
coalesced into a single EFI runtime code region by the firmware, and if
the firmware does a good job of keeping the fragmentation down, it is
conceivable that the memory attributes table has more entries than the
EFI memory map itself.

So instead, base the sanity check on whether the descriptor size matches
the EFI memory map's descriptor size closely enough (which is not
mandated by the spec but extremely unlikely to differ in practice), and
whether the size of the whole table does not exceed 64k entries.

Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
3 months agodrm/bridge: drm_bridge_get/put(): document NULL pointer behaviour
Luca Ceresoli [Tue, 24 Mar 2026 09:08:49 +0000 (10:08 +0100)] 
drm/bridge: drm_bridge_get/put(): document NULL pointer behaviour

drm_bridge_get and drm_bridge_put() do nothing when they are passed a NULL
pointer, and they do so since their initial addition in commit 30d1b37d4c02
("drm/bridge: add support for refcounting").

This allows simpler code in various places when using these
functions. However it's not documented, so it's not clear whether it is
part of the API "contract" or just a current implementation detail that
might change in the future.

There is no visible reason to remove this NULL check, so document it,
making it part of the contract, letting users count on it.

Reviewed-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Link: https://patch.msgid.link/20260324-drm-bridge-alloc-getput-document-null-check-v1-1-fb0877c49d7e@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
3 months agosched/doc: Update yield_task description in sched-design-CFS
fangqiurong [Fri, 3 Apr 2026 05:58:06 +0000 (13:58 +0800)] 
sched/doc: Update yield_task description in sched-design-CFS

The yield_task description referenced the long-removed compat_yield
sysctl and described the function as a dequeue/enqueue cycle. Update
it to reflect current behavior: yielding the CPU by moving the
current task's position back in the runqueue.

Sync zh_CN and sp_SP translations.

Signed-off-by: fangqiurong <fangqiurong@kylinos.cn>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260403055806.358921-1-user@fqr-pc>

3 months agoDocumentation/rtla: Convert links to RST format
Costa Shulyupin [Sun, 5 Apr 2026 16:38:45 +0000 (19:38 +0300)] 
Documentation/rtla: Convert links to RST format

Web links in the documentation are not properly displayed.

In the man pages web links look like:
  Osnoise tracer  documentation:  <  <https://www.kernel.org/doc/html/lat‐
  est/trace/osnoise-tracer.html> >

On web pages the URL caption is the URL itself.

Convert tracer documentation links to RST anonymous hyperlink format
for better rendering. Use newer docs.kernel.org instead of
www.kernel.org/doc/html/latest for brevity.

After the change, the links in the man pages look like:
  Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>

On web pages the captions are the titles of the links.

Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260405163847.3337981-1-costa.shul@redhat.com>

3 months agoRDMA/mana_ib: Support memory windows
Konstantin Taranov [Tue, 31 Mar 2026 09:08:51 +0000 (02:08 -0700)] 
RDMA/mana_ib: Support memory windows

Implement .alloc_mw() and .dealloc_mw() for mana device.

This is just the basic infrastructure, MW is not practically usable until
additional kernel support for allowing user space to submit MW work
requests is completed.

Link: https://patch.msgid.link/r/20260331090851.2276205-1-kotaranov@linux.microsoft.com
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
3 months agodocs: fix typos and duplicated words across documentation
Manuel Cortez [Mon, 6 Apr 2026 03:03:23 +0000 (20:03 -0700)] 
docs: fix typos and duplicated words across documentation

Fix the following typos and duplicated words:

- admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
- core-api/real-time/differences.rst: "the the" -> "the"
- admin-guide/bcache.rst: "to to" -> "to"

Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260406030323.1196-1-mdjesuscv@gmail.com>

3 months agonvme-multipath: drop head pointer check in nvme_mpath_clear_current_path()
John Garry [Wed, 8 Apr 2026 08:03:57 +0000 (08:03 +0000)] 
nvme-multipath: drop head pointer check in nvme_mpath_clear_current_path()

A NS will always have a head pointer, so drop the check. As proof in
practice, all the nvme_mpath_clear_current_path() callers also
dereference ns->head.

This check has endured since the original changes to support multipath.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
3 months agonvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808 (Samsung PM981/983/970...
Alan Cui [Thu, 9 Apr 2026 08:15:25 +0000 (16:15 +0800)] 
nvme: add quirk NVME_QUIRK_IGNORE_DEV_SUBNQN for 144d:a808 (Samsung PM981/983/970 EVO Plus )

The firmware for Samsung 970 Evo Plus / PM981 / PM983 does not support SUBNQN.
Make quirks to suppress warnings.

# nvme id-ctrl /dev/nvme1n1
NVME Identify Controller:
vid       : 0x144d
ssvid     : 0x144d
sn        : ***
mn        : Samsung SSD 970 EVO Plus 500GB
fr        : 2B2QEXM7

mcdqpc    : 0
subnqn    :
ioccsz    : 0

Signed-off-by: Alan Cui <me@alancui.cc>
Signed-off-by: Keith Busch <kbusch@kernel.org>
3 months agonvmet-tcp: fix race between ICReq handling and queue teardown
Chaitanya Kulkarni [Wed, 8 Apr 2026 07:51:31 +0000 (00:51 -0700)] 
nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an
Initialization Connection Response (ICResp), but it does so without
serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request
(ICReq) and immediately closes the connection, target-side teardown
may start in softirq context before io_work drains the already
buffered ICReq. In that case, nvmet_tcp_schedule_release_queue()
sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue
reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can
still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the
DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and
allows a later socket state change to re-enter teardown and issue a
second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has
already moved the queue to DISCONNECTING, a send error can still
overwrite the state with NVMET_TCP_Q_FAILED, again reopening the
window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with
state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather
than propagating it as a transport error like -ECONNRESET. Keep
nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before
honoring that sentinel so receive-side parsing stays quiesced until the
existing release path completes.

Fixes: c46a6465bac2 ("nvmet-tcp: add NVMe over TCP target driver")
Cc: stable@vger.kernel.org
Reported-by: Shivam Kumar <skumar47@syr.edu>
Tested-by: Shivam Kumar <kumar.shivam43666@gmail.com>
Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
3 months agoRDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv
hkbinbin [Wed, 1 Apr 2026 12:19:07 +0000 (12:19 +0000)] 
RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv

rxe_rcv() currently checks only that the incoming packet is at least
header_size(pkt) bytes long before payload_size() is used.

However, payload_size() subtracts both the attacker-controlled BTH pad
field and RXE_ICRC_SIZE from pkt->paylen:

  payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt)
                 - RXE_ICRC_SIZE

This means a short packet can still make payload_size() underflow even
if it includes enough bytes for the fixed headers. Simply requiring
header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a
packet with a forged non-zero BTH pad can still leave payload_size()
negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length
required by payload_size(): header_size(pkt) + bth_pad(pkt) +
RXE_ICRC_SIZE.

Cc: stable@vger.kernel.org
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Link: https://patch.msgid.link/r/20260401121907.1468366-1-hkbinbinbin@gmail.com
Signed-off-by: hkbinbin <hkbinbinbin@gmail.com>
Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
3 months agoext4: unmap invalidated folios from page tables in mpage_release_unused_pages()
Deepanshu Kartikey [Fri, 5 Dec 2025 05:59:14 +0000 (11:29 +0530)] 
ext4: unmap invalidated folios from page tables in mpage_release_unused_pages()

When delayed block allocation fails (e.g., due to filesystem corruption
detected in ext4_map_blocks()), the writeback error handler calls
mpage_release_unused_pages(invalidate=true) which invalidates affected
folios by clearing their uptodate flag via folio_clear_uptodate().

However, these folios may still be mapped in process page tables. If a
subsequent operation (such as ftruncate calling ext4_block_truncate_page)
triggers a write fault, the existing page table entry allows access to
the now-invalidated folio. This leads to ext4_page_mkwrite() being called
with a non-uptodate folio, which then gets marked dirty, triggering:

    WARNING: CPU: 0 PID: 5 at mm/page-writeback.c:2960
    __folio_mark_dirty+0x578/0x880

    Call Trace:
     fault_dirty_shared_page+0x16e/0x2d0
     do_wp_page+0x38b/0xd20
     handle_pte_fault+0x1da/0x450

The sequence leading to this warning is:

1. Process writes to mmap'd file, folio becomes uptodate and dirty
2. Writeback begins, but delayed allocation fails due to corruption
3. mpage_release_unused_pages(invalidate=true) is called:
   - block_invalidate_folio() clears dirty flag
   - folio_clear_uptodate() clears uptodate flag
   - But folio remains mapped in page tables
4. Later, ftruncate triggers ext4_block_truncate_page()
5. This causes a write fault on the still-mapped folio
6. ext4_page_mkwrite() is called with folio that is !uptodate
7. block_page_mkwrite() marks buffers dirty
8. fault_dirty_shared_page() tries to mark folio dirty
9. block_dirty_folio() calls __folio_mark_dirty(warn=1)
10. WARNING triggers: WARN_ON_ONCE(warn && !uptodate && !dirty)

Fix this by unmapping folios from page tables before invalidating them
using unmap_mapping_pages(). This ensures that subsequent accesses
trigger new page faults rather than reusing invalidated folios through
stale page table entries.

Note that this results in data loss for any writes to the mmap'd region
that couldn't be written back, but this is expected behavior when
writeback fails due to filesystem corruption. The existing error message
already states "This should not happen!! Data will be lost".

Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com
Tested-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
Suggested-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20251205055914.1393799-1-kartikey406@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
3 months agodocs: fix typo in zoran driver documentation
Gleb Golovko [Tue, 7 Apr 2026 21:28:18 +0000 (00:28 +0300)] 
docs: fix typo in zoran driver documentation

Replace "an a few" with "and a few" in
Documentation/driver-api/media/drivers/zoran.rst.

Signed-off-by: Gleb Golovko <gaben123001@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260407212818.925-1-gaben123001@gmail.com>

3 months agogpio: swnode: defer probe on references to unregistered software nodes
Bartosz Golaszewski [Tue, 7 Apr 2026 13:27:58 +0000 (15:27 +0200)] 
gpio: swnode: defer probe on references to unregistered software nodes

fwnode_property_get_reference_args() now returns -ENOTCONN when called
on a software node referencing another software node which has not yet
been registered as a firmware node. It makes sense to defer probe in this
situation as the node will most likely be registered later on and we'll
be able to resolve the reference eventually. Change the behavior of
swnode_find_gpio() to return -EPROBE_DEFER if the software node reference
resolution returns -ENOTCONN.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260407-swnode-unreg-retcode-v4-2-1b2f0725eb9c@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
3 months agoRDMA/core: Prefer NLA_NUL_STRING
Florian Westphal [Mon, 30 Mar 2026 12:27:39 +0000 (14:27 +0200)] 
RDMA/core: Prefer NLA_NUL_STRING

These attributes are evaluated as c-string (passed to strcmp), but
NLA_STRING doesn't check for the presence of a \0 terminator.

Either this needs to switch to nla_strcmp() and needs to adjust printf fmt
specifier to not use plain %s, or this needs to use NLA_NUL_STRING.

As the code has been this way for long time, it seems to me that userspace
does include the terminating nul, even tough its not enforced so far, and
thus NLA_NUL_STRING use is the simpler solution.

Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service")
Link: https://patch.msgid.link/r/20260330122742.13315-1-fw@strlen.de
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
3 months agosched/cache: Allow the user space to turn on and off cache aware scheduling
Chen Yu [Wed, 1 Apr 2026 21:52:31 +0000 (14:52 -0700)] 
sched/cache: Allow the user space to turn on and off cache aware scheduling

Provide a debugfs directory llc_balancing, and a knob named
"enabled" under it to allow the user to turn off and on the
cache aware scheduling at runtime.

Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/0aa56f7fc48db2f8f700cd1aa34dedd0ec88351b.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Enable cache aware scheduling for multi LLCs NUMA node
Chen Yu [Wed, 1 Apr 2026 21:52:30 +0000 (14:52 -0700)] 
sched/cache: Enable cache aware scheduling for multi LLCs NUMA node

Introduce sched_cache_present to enable cache aware scheduling for
multi LLCs NUMA node Cache-aware load balancing should only be
enabled if there are more than 1 LLCs within 1 NUMA node.
sched_cache_present is introduced to indicate whether this
platform supports this topology.

Test results:
The first test platform is a 2 socket Intel Sapphire Rapids with 30
cores per socket. The DRAM interleaving is enabled in the BIOS so it
essential has one NUMA node with two last level caches. There are 60
CPUs associated with each last level cache.

The second test platform is a AMD Genoa. There are 4 Nodes and 32 CPUs
per node. Each node has 2 CCXs and each CCX has 16 CPUs.

hackbench/schbench/netperf/stream/stress-ng/chacha20 were launched
on these two platforms.

[TL;DR]
Sappire Rapids:
hackbench shows significant improvement when the number of
different active threads is below the capacity of a LLC.
schbench shows limitted wakeup latency improvement.
ChaCha20-xiangshan(risc-v simulator) shows good throughput
improvement. No obvious difference was observed in
netperf/stream/stress-ng in Hmean.

Genoa:
Significant improvement is observed in hackbench when
the active number of threads is lower than the number
of CPUs within 1 LLC. On v2, Aaron reported improvement
of hackbench/redis when system is underloaded.
ChaCha20-xiangshan shows huge throughput improvement.
Phoronix has tested v1 and shows good improvements in 30+
cases[3]. No obvious difference was observed in
netperf/stream/stress-ng in Hmean.

Detail:
Due to length constraints, data without much difference with
baseline is not presented.

Sapphire Rapids:
[hackbench pipe]
================
case                    load            baseline(std%)  compare%( std%)
threads-pipe-10         1-groups         1.00 (  1.22)  +26.09 (  1.10)
threads-pipe-10         2-groups         1.00 (  4.90)  +22.88 (  0.18)
threads-pipe-10         4-groups         1.00 (  2.07)   +9.00 (  3.49)
threads-pipe-10         8-groups         1.00 (  8.13)   +3.45 (  3.62)
threads-pipe-16         1-groups         1.00 (  2.11)  +26.30 (  0.08)
threads-pipe-16         2-groups         1.00 ( 15.13)   -1.77 ( 11.89)
threads-pipe-16         4-groups         1.00 (  4.37)   +0.58 (  7.99)
threads-pipe-16         8-groups         1.00 (  2.88)   +2.71 (  3.50)
threads-pipe-2          1-groups         1.00 (  9.40)  +22.07 (  0.71)
threads-pipe-2          2-groups         1.00 (  9.99)  +18.01 (  0.95)
threads-pipe-2          4-groups         1.00 (  3.98)  +24.66 (  0.96)
threads-pipe-2          8-groups         1.00 (  7.00)  +21.83 (  0.23)
threads-pipe-20         1-groups         1.00 (  1.03)  +28.84 (  0.21)
threads-pipe-20         2-groups         1.00 (  4.42)  +31.90 (  3.15)
threads-pipe-20         4-groups         1.00 (  9.97)   +4.56 (  1.69)
threads-pipe-20         8-groups         1.00 (  1.87)   +1.25 (  0.74)
threads-pipe-4          1-groups         1.00 (  4.48)  +25.67 (  0.78)
threads-pipe-4          2-groups         1.00 (  9.14)   +4.91 (  2.08)
threads-pipe-4          4-groups         1.00 (  7.68)  +19.36 (  1.53)
threads-pipe-4          8-groups         1.00 ( 10.79)   +7.20 ( 12.20)
threads-pipe-8          1-groups         1.00 (  4.69)  +21.93 (  0.03)
threads-pipe-8          2-groups         1.00 (  1.16)  +25.29 (  0.65)
threads-pipe-8          4-groups         1.00 (  2.23)   -1.27 (  3.62)
threads-pipe-8          8-groups         1.00 (  4.65)   -3.08 (  2.75)

Note: The default number of fd in hackbench is changed from 20 to various
values to ensure that threads fit within a single LLC, especially on AMD
systems. Take "threads-pipe-8, 2-groups" for example, the number of fd
is 8, and 2 groups are created.

[schbench]
The 99th percentile wakeup latency shows some improvements when the
system is underload, while it does not bring much difference with
the increasing of system utilization.

99th Wakeup Latencies Base (mean std)      Compare (mean std)   Change
=========================================================================
thread=2                 9.00(0.00)           9.00(1.73)           0.00%
thread=4                 7.33(0.58)           6.33(0.58)           +13.64%
thread=8                 9.00(0.00)           7.67(1.15)           +14.78%
thread=16                8.67(0.58)           8.67(1.53)           0.00%
thread=32                9.00(0.00)           7.00(0.00)           +22.22%
thread=64                9.33(0.58)           9.67(0.58)           -3.64%
thread=128              12.00(0.00)          12.00(0.00)           0.00%

[chacha20 on simulated risc-v]
baseline:
Host time spent: 67861ms
cache aware scheduling enabled:
Host time spent: 54441ms

Time reduced by 24%

Genoa:
[hackbench pipe]
The default number of fd is 20, which exceed the number of CPUs
in a LLC. So the fd is adjusted to 2, 4, 6, 8, 20 respectively.
Exclude the result with large run-to-run variance, 10% ~ 50%
improvement is observed when the system is underloaded:

[hackbench pipe]
================
case                    load            baseline(std%)  compare%( std%)
threads-pipe-2          1-groups         1.00 (  2.89)  +47.33 (  1.20)
threads-pipe-2          2-groups         1.00 (  3.88)  +39.82 (  0.61)
threads-pipe-2          4-groups         1.00 (  8.76)   +5.57 ( 13.10)
threads-pipe-20         1-groups         1.00 (  4.61)  +11.72 (  1.06)
threads-pipe-20         2-groups         1.00 (  6.18)  +14.55 (  1.47)
threads-pipe-20         4-groups         1.00 (  2.99)  +10.16 (  4.49)
threads-pipe-4          1-groups         1.00 (  4.23)  +43.70 (  2.14)
threads-pipe-4          2-groups         1.00 (  3.68)   +8.45 (  4.04)
threads-pipe-4          4-groups         1.00 ( 17.72)   +2.42 (  1.14)
threads-pipe-6          1-groups         1.00 (  3.10)   +7.74 (  3.83)
threads-pipe-6          2-groups         1.00 (  3.42)  +14.26 (  4.53)
threads-pipe-6          4-groups         1.00 ( 10.34)  +10.94 (  7.12)
threads-pipe-8          1-groups         1.00 (  4.21)   +9.06 (  4.43)
threads-pipe-8          2-groups         1.00 (  1.88)   +3.74 (  0.58)
threads-pipe-8          4-groups         1.00 (  2.78)  +23.96 (  1.18)

[chacha20 on simulated risc-v]
Host time spent: 54762ms
Host time spent: 28295ms

Time reduced by 48%

Suggested-by: Libo Chen <libchen@purestorage.com>
Suggested-by: Adam Li <adamli@os.amperecomputing.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/71972e12ab4f08aff422b31e34df09bdbd94de84.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Respect LLC preference in task migration and detach
Tim Chen [Wed, 1 Apr 2026 21:52:27 +0000 (14:52 -0700)] 
sched/cache: Respect LLC preference in task migration and detach

During load balancing, make can_migrate_task()
consider a task's LLC preference.
Prevent a task from being moved out of its preferred LLC.

During the regular load balancing, if
the task cannot be migrated due to LLC locality, the
nr_balance_failed also should not be increased.

Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/53da65f3d59de31e1a1dc59a4093d8dd9d4dc206.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Handle moving single tasks to/from their preferred LLC
Tim Chen [Wed, 1 Apr 2026 21:52:26 +0000 (14:52 -0700)] 
sched/cache: Handle moving single tasks to/from their preferred LLC

Cache aware scheduling mainly does two things:
1. Prevent task from migrating out of its preferred LLC if not
   nessasary.
2. Migrating task to their preferred LLC if nessasary.

For 1:
In the generic load balance, if the busiest runqueue has only one task,
active balancing may be invoked to move it away. However, this migration
might break LLC locality.

Prevent regular load balance from migrating a task that
prefers the current LLC. The load level and imbalance do not warrant
breaking LLC preference per the can_migrate_llc() policy. Here, the
benefit of LLC locality outweighs the power efficiency gained from
migrating the only runnable task away.

Before migration, check whether the task is running on its preferred
LLC: Do not move a lone task to another LLC if it would move the task
away from its preferred LLC or cause excessive imbalance between LLCs.

For 2:
On the other hand, if the migration type is migrate_llc_task, it means
that there are tasks on the env->src_cpu that want to be migrated to
their preferred LLC, launch the active load balance anyway.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/9b816d8c27fabf2a9c0e1f61a6b90afe8ec4ad52.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Add migrate_llc_task migration type for cache-aware balancing
Tim Chen [Wed, 1 Apr 2026 21:52:25 +0000 (14:52 -0700)] 
sched/cache: Add migrate_llc_task migration type for cache-aware balancing

Introduce a new migration type, migrate_llc_task, to support
cache-aware load balancing.

After identifying the busiest sched_group (having the most tasks
preferring the destination LLC), mark migrations with this type.
During load balancing, each runqueue in the busiest sched_group is
examined, and the runqueue with the highest number of tasks preferring
the destination CPU is selected as the busiest runqueue.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/b9df27c19cc5121ddb2a7d1be7f9d52fec1563dc.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Prioritize tasks preferring destination LLC during balancing
Tim Chen [Wed, 1 Apr 2026 21:52:24 +0000 (14:52 -0700)] 
sched/cache: Prioritize tasks preferring destination LLC during balancing

During LLC load balancing, first check for tasks that prefer the
destination LLC and balance them to it before others.

Mark source sched groups containing tasks preferring non local LLCs
with the group_llc_balance flag. This ensures the load balancer later
pulls or pushes these tasks toward their preferred LLCs.
The priority of group_llc_balance is lower than that of group_overloaded
and higher than that of all other group types. This is because
group_llc_balance may exacerbate load imbalance, and if the LLC balancing
attempt fails, the nr_balance_failed mechanism will trigger other group
types to rebalance the load.

The load balancer selects the busiest sched_group and migrates tasks
to less busy groups to distribute load across CPUs.

With cache-aware scheduling enabled, the busiest sched_group is
the one with most tasks preferring the destination LLC. If
the group has the llc_balance flag set, cache aware load balancing is
triggered.

Introduce the helper function update_llc_busiest() to identify the
sched_group with the most tasks preferring the destination LLC.

Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Suggested-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/baa458f45eab3f602af090c6d6af63dc864f5ec6.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Check local_group only once in update_sg_lb_stats()
Tim Chen [Wed, 1 Apr 2026 21:52:23 +0000 (14:52 -0700)] 
sched/cache: Check local_group only once in update_sg_lb_stats()

There is no need to check the local group twice for both
group_asym_packing and group_smt_balance. Adjust the code
to facilitate future checks for group types (cache-aware
load balancing) as well.

No functional changes are expected.

Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/99a57865c8ae1847087a5c00e92d24351cf3e5a8.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Count tasks prefering destination LLC in a sched group
Tim Chen [Wed, 1 Apr 2026 21:52:22 +0000 (14:52 -0700)] 
sched/cache: Count tasks prefering destination LLC in a sched group

During LLC load balancing, tabulate the number of tasks on each runqueue
that prefer the LLC contains the env->dst_cpu in a sched group.

For example, consider a system with 4 LLC sched groups (LLC0 to LLC3)
balancing towards LLC3. LLC0 has 3 tasks preferring LLC3, LLC1 has
2, and LLC2 has 1. LLC0, having the most tasks preferring LLC3, is
selected as the busiest source to pick tasks from.

Within a source LLC, the total number of tasks preferring a destination
LLC is computed by summing counts across all CPUs in that LLC. For
instance, if LLC0 has CPU0 with 2 tasks and CPU1 with 1 task preferring
LLC3, the total for LLC0 is 3.

These statistics allow the load balancer to choose tasks from source
sched groups that best match their preferred LLCs.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/3d8502a33a753c4384b368f97f64ee70b1cea0db.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Calculate the percpu sd task LLC preference
Tim Chen [Wed, 1 Apr 2026 21:52:21 +0000 (14:52 -0700)] 
sched/cache: Calculate the percpu sd task LLC preference

Calculate the number of tasks' LLC preferences for each runqueue.
This statistic is computed during task enqueue and dequeue
operations, and is used by the cache-aware load balancing.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/d15a64436d3acd19c5c53344c5e9d3d0b79b3233.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Introduce per CPU's tasks LLC preference counter
Tim Chen [Wed, 1 Apr 2026 21:52:20 +0000 (14:52 -0700)] 
sched/cache: Introduce per CPU's tasks LLC preference counter

The lowest level of sched domain for each CPU is assigned an
array where each element tracks the number of tasks preferring
a given LLC, indexed from 0 to max_lid. Since each CPU
has its dedicated sd, this implies that each CPU will have
a dedicated task LLC preference counter.

For example, sd->llc_counts[3] = 2 signifies that there
are 2 tasks on this runqueue which prefer to run within LLC3.

The load balancer can use this information to identify busy
runqueues and migrate tasks to their preferred LLC domains.
This array will be reallocated at runtime during sched domain
rebuild.

Introduce the buffer allocation mechanism, and the statistics
will be calculated in the subsequent patch.

Note: the LLC preference statistics of each CPU are reset on
sched domain rebuild and may under count temporarily, until the
CPU becomes idle and the count is cleared. This is a trade off
to avoid complex data synchronization across sched domain builds.

Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/42e79eceb8cd6be8a032401d481d101913bc5703.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Track LLC-preferred tasks per runqueue
Tim Chen [Wed, 1 Apr 2026 21:52:19 +0000 (14:52 -0700)] 
sched/cache: Track LLC-preferred tasks per runqueue

For each runqueue, track the number of tasks with an LLC preference
and how many of them are running on their preferred LLC. This mirrors
nr_numa_running and nr_preferred_running for NUMA balancing, and will
be used by cache-aware load balancing in later patches.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/459a37102f3d74a4e09ea58401d2094ac731d044.1775065312.git.tim.c.chen@linux.intel.com
3 months agosched/cache: Assign preferred LLC ID to processes
Tim Chen [Wed, 1 Apr 2026 21:52:18 +0000 (14:52 -0700)] 
sched/cache: Assign preferred LLC ID to processes

With cache-aware scheduling enabled, each task is assigned a
preferred LLC ID. This allows quick identification of the LLC domain
where the task prefers to run, similar to numa_preferred_nid in
NUMA balancing.

Co-developed-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/f2ceecba5858680349ad4ce9303a2121f0bb7272.1775065312.git.tim.c.chen@linux.intel.com