linux.git, branch v6.15.5

Linux 6.15.5

2025-07-06T09:04:26+00:00

Link: https://lore.kernel.org/r/20250703144004.276210867@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Florian Fainelli 
Tested-by: Christian Heusel 
Tested-by: Salvatore Bonaccorso 
Tested-by: Hardik Garg 
Tested-by: Shuah Khan 
Tested-by: Ron Economos 
Tested-by: Pascal Ernster 
Tested-By: Achill Gilgenast 
Tested-by: Takeshi Ogasawara 
Tested-by: Luna Jernberg 
Tested-by: Jon Hunter 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Mark Brown 
Tested-by: Markus Reichelt 
Tested-by: Miguel Ojeda 
Link: https://lore.kernel.org/r/20250704125604.759558342@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Mark Brown 
Tested-by: Markus Reichelt 
Tested-by: Miguel Ojeda 
Tested-by: Takeshi Ogasawara 
Tested-by: Peter Schneider 
Tested-by: Luna Jernberg 
Tested-by: Florian Fainelli 
Tested-By: Achill Gilgenast 
Tested-by: Pascal Ernster 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix AMDGPU_MAX_BL_LEVEL value

2025-07-06T09:04:26+00:00

commit 66abb996999de0d440a02583a6e70c2c24deab45 upstream.

[Why]
commit 16dc8bc27c2a ("drm/amd/display: Export full brightness range to
userspace") adjusted the brightness range to scale to larger values, but
missed updating AMDGPU_MAX_BL_LEVEL which is needed to make sure that
scaling works properly with custom brightness curves.

[How]
As the change for max brightness of 0xFFFF only applies to devices
supporting DC, use existing DC define MAX_BACKLIGHT_LEVEL.

Fixes: 16dc8bc27c2a ("drm/amd/display: Export full brightness range to userspace")
Acked-by: Alex Deucher 
Link: https://lore.kernel.org/r/20250623171114.1156451-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Deucher 
(cherry picked from commit 5b852044eb0d3e1f1c946d32e05fcb068e0a20a0)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Export full brightness range to userspace

2025-07-06T09:04:26+00:00

commit 16dc8bc27c2aa3c93905d3e885e27f1e3535f09a upstream.

[WHY]
Userspace currently is offered a range from 0-0xFF but the PWM is
programmed from 0-0xFFFF.  This can be limiting to some software
that wants to apply greater granularity.

[HOW]
Convert internally to firmware values only when mapping custom
brightness curves because these are in 0-0xFF range. Advertise full
PWM range to userspace.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Reviewed-by: Roman Li 
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 8dbd72cb790058ce52279af38a43c2b302fdd3e5)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Optimize custom brightness curve

2025-07-06T09:04:26+00:00

commit 03b979e1025fba1d47cae005022fcdbba140f043 upstream.

[Why]
When BIOS includes a lot of custom brightness data points, walking
the entire list can be time consuming.  This is most noticed when
dragging a power slider.  The "higher" values are "slower" to drag
around.

[How]
Move custom brightness calculation loop into a static function. Before
starting the loop check the "half way" data point to see how it compares
to the input.  If greater than the half way data point use that as the
starting point instead.

Reviewed-by: Alex Hung 
Signed-off-by: Mario Limonciello 
Signed-off-by: Roman Li 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Only read ACPI backlight caps once

2025-07-06T09:04:26+00:00

commit ffcaed1d7ecef31198000dfbbea791f30f7ca437 upstream.

[WHY]
Backlight caps are read already in amdgpu_dm_update_backlight_caps().
They may be updated by update_connector_ext_caps(). Reading again when
registering backlight device may cause wrong values to be used.

[HOW]
Use backlight caps already registered to the dm.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Reviewed-by: Roman Li 
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Hung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
(cherry picked from commit 148144f6d2f14b02eaaa39b86bbe023cbff350bd)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix default DC and AC levels

2025-07-06T09:04:26+00:00

commit 8b5f3a229a70d242322b78c8e13744ca00212def upstream.

[Why]
DC and AC levels are advertised in a percentage, not a luminance.

[How]
Scale DC and AC levels to supported values.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4221
Reviewed-by: Alex Hung 
Signed-off-by: Mario Limonciello 
Signed-off-by: Wayne Lin 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add debugging message for brightness caps

2025-07-06T09:04:25+00:00

commit 4b61b8a390511a1864f26cc42bab72881e93468d upstream.

[Why]
Default BIOS brightness caps are buried in ACPI.

[How]
Add extra dynamic debug that can show default brightness caps.

Reviewed-by: Alex Hung 
Signed-off-by: Mario Limonciello 
Signed-off-by: Wayne Lin 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

riscv: uaccess: Only restore the CSR_STATUS SUM bit

2025-07-06T09:04:25+00:00

commit 265d6aba165c500389c80d394ac247460c443ef5 upstream.

During switch to csrs will OR the value of the register into the
corresponding csr. In this case we're only interested in restoring the
SUM bit not the entire register.

Signed-off-by: Cyril Bur 
Link: https://lore.kernel.org/r/20250522160954.429333-1-cyrilbur@tenstorrent.com
Co-developed-by: Alexandre Ghiti 
Signed-off-by: Alexandre Ghiti 
Fixes: 788aa64c01f1 ("riscv: save the SR_SUM status over switches")
Link: https://lore.kernel.org/r/20250602121543.1544278-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Greg Kroah-Hartman

io_uring: gate REQ_F_ISREG on !S_ANON_INODE as well

2025-07-06T09:04:25+00:00

commit 6f11adcc6f36ffd8f33dbdf5f5ce073368975bc3 upstream.

io_uring marks a request as dealing with a regular file on S_ISREG. This
drives things like retries on short reads or writes, which is generally
not expected on a regular file (or bdev). Applications tend to not
expect that, so io_uring tries hard to ensure it doesn't deliver short
IO on regular files.

However, a recent commit added S_IFREG to anonymous inodes. When
io_uring is used to read from various things that are backed by anon
inodes, like eventfd, timerfd, etc, then it'll now all of a sudden wait
for more data when rather than deliver what was read or written in a
single operation. This breaks applications that issue reads on anon
inodes, if they ask for more data than a single read delivers.

Add a check for !S_ANON_INODE as well before setting REQ_F_ISREG to
prevent that.

Cc: Christian Brauner 
Cc: stable@vger.kernel.org
Link: https://github.com/ghostty-org/ghostty/discussions/7720
Fixes: cfd86ef7e8e7 ("anon_inode: use a proper mode internally")
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

io_uring/kbuf: flag partial buffer mappings

2025-07-06T09:04:25+00:00

Commit 178b8ff66ff827c41b4fa105e9aabb99a0b5c537 upstream.

A previous commit aborted mapping more for a non-incremental ring for
bundle peeking, but depending on where in the process this peeking
happened, it would not necessarily prevent a retry by the user. That can
create gaps in the received/read data.

Add struct buf_sel_arg->partial_map, which can pass this information
back. The networking side can then map that to internal state and use it
to gate retry as well.

Since this necessitates a new flag, change io_sr_msg->retry to a
retry_flags member, and store both the retry and partial map condition
in there.

Cc: stable@vger.kernel.org
Fixes: 26ec15e4b0c1 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks")
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman