The correct operating mode for the fan is inversed (1). The previous pwm
driver implementation had a bug and the polarity information was propagated
incorrectly to the kernel. The normal (0) polarity specified in the device
tree was incorrectly clearing the polarity bit in the counter control
register. After the bug fix, setting the polarity to inversed (1) in the
device tree will clear the polarity bit.
Also provide label for custom description based on this SOM.
Signed-off-by: Vishal Patel <vishal.patel@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e6dc9ce1e0b97c9d9b073c323cc94a5d7a88b94a.1752835502.git.michal.simek@amd.com
Add "cap-mmc-hw-reset" property to the eMMC DT node to perform the
eMMC device hardware reset.
Also, add "no-sd", "no-sdio" properties to eMMC DT node to skip
unwanted sd, sdio related commands during initialization for eMMC
device as this may lead to unnecessary register dump.
Signed-off-by: Paul Alvin <alvin.paulp@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/10132834c0509539b0d01ff5097591cd2e3ae125.1752835501.git.michal.simek@amd.com
As per the design specification
"The 16-bit Seconds Calibration Value represents the number of
Oscillator Ticks that are required to measure the largest time period
that is less than or equal to 1 second.
For an oscillator that is 32.768kHz, this value will be 0x7FFF."
Signed-off-by: Harini T <harini.t@amd.com>
Link: https://lore.kernel.org/r/20250710061309.25601-1-harini.t@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
gpuvm:
- fix some typos
xe:
- Fix user-fence race issue
- Couple xe_vm fixes
- Don't trigger rebind on initial dma-buf validation
- Fix a build issue related to basename() posix vs gnu discrepancy
amdgpu:
- pin buffers while vmapping
- UserQ fixes
- Revert CSA fix
- SR-IOV fix
nouveau:
- fix linear modifier
- remove some dead code
msm:
- Core/GPU:
- fix comment doc warning in gpuvm
- fix build with KMS disabled
- fix pgtable setup/teardown race
- global fault counter fix
- various error path fixes
- GPU devcoredump snapshot fixes
- handle in-place VM_BIND remaps to solve turnip vm update race
- skip re-emitting IBs for unusable VMs
- Don't use %pK through printk
- moved display snapshot init earlier, fixing a crash
- DPU:
- Fixed crash in virtual plane checking code
- Fixed mode comparison in virtual plane checking code
- DSI:
- Adjusted width of resulution-related registers
- Fixed locking issue on 14nm PLLs
- UBWC (per Bjorn's ack)
- Added UBWC configuration for several missing platforms (fixing
regression)
mediatek:
- Add error handling for old state CRTC in atomic_disable
- Fix DSI host and panel bridge pre-enable order
- Fix device/node reference count leaks in mtk_drm_get_all_drm_priv
- mtk_hdmi: Fix inverted parameters in some regmap_update_bits calls
tegra:
- revert dma-buf change
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmixFPQACgkQDHTzWXnE
hr4d4Q/+Lf/meDiKrjUHiNwW+kZPeZhwrKEEbG2Opc9uZZdQpx44ZhOKM668dUx1
YWAC2hcQFKWe0tz4Qsg2drPBGmoobhxmVScwXpY7xz1XN4taINssuZRwERp3bLmx
l63tcQleGJOYvbCcg0SCfDeR4fd7a7iVf+PelFU04mbn/qorJBdYuy/XPTZlCond
lf1MtaPH8f2M80WHmwb4g5K3mIdIa0HCt6Z9Z73mLRmF0b6KfcWF8159OLz03tiS
voHDmFR4VsoZihDC4H+fAAitbQG+5vZN6YtX2CC4OtQLxeGkpkOniGwfjD/beKne
edGHvWpzBchmK0Z6o64+7rzJa7RYEkpgryvAD/jEljG9kk0RzlGAYvXFV3aeLFLn
+WJX8ZOw/SqkGX5/DDA0CpDb3Ty8QxEmS/MEHn/kAUNmBp0Uw2ad6b/4b3NqkDh9
ftgWSobFubZJ8oSf8amPwpW7KjSsccogQzASiuDlV/XCCdlKvuxkn/ZX9XjHq0rr
O0CX+4vLhl20grRstD4oIVsmrLYQXg97uqpOeaoMrzflKfyEzJ7bxDSBd78ZbfVf
dlHSULx3cgusNe8HNWRnsnC0XeC1MBTXCbpTjrZYkqu1arLZN+r8LXOGRZrKBCPu
PtlmU21JJKygKUTWeXzX1P2eBdBoTloOKJGkLWthR9KxFDqfppM=
=QtCr
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2025-08-29' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly fixes, feels a bit big.
The major piece is msm fixes, then the usual amdgpu/xe along with some
mediatek and nouveau fixes and a tegra revert.
gpuvm:
- fix some typos
xe:
- Fix user-fence race issue
- Couple xe_vm fixes
- Don't trigger rebind on initial dma-buf validation
- Fix a build issue related to basename() posix vs gnu discrepancy
amdgpu:
- pin buffers while vmapping
- UserQ fixes
- Revert CSA fix
- SR-IOV fix
nouveau:
- fix linear modifier
- remove some dead code
msm:
- Core/GPU:
- fix comment doc warning in gpuvm
- fix build with KMS disabled
- fix pgtable setup/teardown race
- global fault counter fix
- various error path fixes
- GPU devcoredump snapshot fixes
- handle in-place VM_BIND remaps to solve turnip vm update race
- skip re-emitting IBs for unusable VMs
- Don't use %pK through printk
- moved display snapshot init earlier, fixing a crash
- DPU:
- Fixed crash in virtual plane checking code
- Fixed mode comparison in virtual plane checking code
- DSI:
- Adjusted width of resulution-related registers
- Fixed locking issue on 14nm PLLs
- UBWC (per Bjorn's ack)
- Added UBWC configuration for several missing platforms (fixing
regression)
mediatek:
- Add error handling for old state CRTC in atomic_disable
- Fix DSI host and panel bridge pre-enable order
- Fix device/node reference count leaks in mtk_drm_get_all_drm_priv
- mtk_hdmi: Fix inverted parameters in some regmap_update_bits calls
tegra:
- revert dma-buf change"
* tag 'drm-fixes-2025-08-29' of https://gitlab.freedesktop.org/drm/kernel: (56 commits)
drm/mediatek: mtk_hdmi: Fix inverted parameters in some regmap_update_bits calls
drm/amdgpu/userq: fix error handling of invalid doorbell
drm/amdgpu: update firmware version checks for user queue support
drm/amd/amdgpu: disable hwmon power1_cap* for gfx 11.0.3 on vf mode
Revert "drm/amdgpu: fix incorrect vm flags to map bo"
drm/amdgpu/gfx12: set MQD as appriopriate for queue types
drm/amdgpu/gfx11: set MQD as appriopriate for queue types
drm/xe: switch to local xbasename() helper
drm/xe: Don't trigger rebind on initial dma-buf validation
drm/xe/vm: Clear the scratch_pt pointer on error
drm/xe/vm: Don't pin the vm_resv during validation
drm/xe/xe_sync: avoid race during ufence signaling
Revert "drm/tegra: Use dma_buf from GEM object instance"
soc: qcom: use no-UBWC config for MSM8956/76
soc: qcom: add configuration for MSM8929
soc: qcom: ubwc: add more missing platforms
soc: qcom: ubwc: use no-uwbc config for MSM8917
drm/msm/dpu: Add a null ptr check for dpu_encoder_needs_modeset
dt-bindings: display/msm: qcom,mdp5: drop lut clock
drm/gpuvm: fix various typos in .c and .h gpuvm file
...
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmiwwhkQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpnooD/92QqpW1IOn0hs0WGOiKl7se5JgBuLV9bd0
j7M8EpGyFK63zeDgAO0/Qu2arEva9tlDaW9S/e78kt1PwQ7it82RSlPC47nKWEv+
Xn5npn2SOEkyY/5/a+iVkOsSD++RIM/DnHNBe9vmU6wePR7AthG5Nhl6kOEi5cyw
e1eLbwB/0eJZzhHYCaowLwdtnMCcwQAEh/FFYz7tSyrgOsDpovKid6D7s2Sv9sGA
+lOzwimgszr3RF5bOMudU12RtP35gAvyF56iDVMQylHXybuaYYzzVAmxRLD5vrOf
vC4HSzRxwUCZnIW62TTP29dAB9mik3va069e1xV1le94vdEsgj2HmuV4tpCzs3LN
4a1q8oEC83QI+cixzsjxf00DaJSkk9msUNsqE+6rcEK0M6z0tRz3mbLXYiCo7V4Y
eLD7eMsxXkJUSpTwWOIVYiXuM+OvSmFxIEoz4lGnQESKyV0dA86RT5TpOiUCrkW1
G9nTccxVPZG3i8FKJXmgZLPmpviw+wwzdpjlVShqSGA++/bBXKwAnjAQPSsaVDIS
HaqhG1IngL9sCcnAy8ZBTEy2TYibasUL48vfCeRhP2u2RZa21zRSOPNFRV9cVvRE
/wOWQikOqC9ys7zvbLG0OfLQAlejGn1k+k6oEOI6P9x2a0vbjq/UZxIQSkdYEhXG
x73gWYk28g==
=/1eG
-----END PGP SIGNATURE-----
Merge tag 'block-6.17-20250828' of git://git.kernel.dk/linux
Pull block fixes from Jens Axboe:
- Fix a lockdep spotted issue on recursive locking for zoned writes, in
case of errors
- Update bcache MAINTAINERS entry address for Coly
- Fix for a ublk release issue, with selftests
- Fix for a regression introduced in this cycle, where it assumed
q->rq_qos was always set if the bio flag indicated that
- Fix for a regression introduced in this cycle, where loop retrieving
block device sizes got broken
* tag 'block-6.17-20250828' of git://git.kernel.dk/linux:
bcache: change maintainer's email address
ublk selftests: add --no_ublk_fixed_fd for not using registered ublk char device
ublk: avoid ublk_io_release() called after ublk char dev is closed
block: validate QoS before calling __rq_qos_done_bio()
blk-zoned: Fix a lockdep complaint about recursive locking
loop: fix zero sized loop for block special file
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmiwwi8QHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpvBdD/4lwnluUoyPn7pm6QMNG7oGn4ix7drP797P
TfOFgQHSepBq8VqEKE+B3dA4n+rCMFy601psaG9pQW9R0pDWHN3FG+TkaQl6ixdS
t18q/JXbzIiD4aTD9Dz/dkkY6EczIPFqVwg+Lc4K89P3vNri70lHXXmDTlbumB3P
PIkxU7PvueO6dZf79QjdczxDw6I5lUJJv6iAn6H6EMy5gJVF01rZqbSl3i08kSVQ
6i26rEw0QkzC30SzU2m5H5qrdD8OewG6Fr5zwiNbCuqLdZBgvzqPR25WeSNRHV5F
CF23QImuQwBnrHloDPI7Uvz0yC6W3jNIW+nF6X5SV1U51BMZ1ED5hQZczRoJpmco
1Vhz7tanPa1qNrNeu7E7vfHuQ/gIKnjgXptLRTL+4HRk65TZpXcS5b2vJsAZf32x
nYIaYjxUmGCayQgAE8tqXvfsmzLQ0BbvZMr45lm32uVbesDZh9Vp9q10BetsmQEk
f17qjJz6weYUnO1fktRWLUtHZVbNeuf5VLalRod/FOBVo9J84XC4JebjN/X4FGWY
+2GIepX5LnrI/2xSaAbJURIj0TL6wSnmu/H3RoGLDvAvMC7atqHSt9TMBNIdYhNY
u6ez5Jd/tYM/bW3WUtFLRqtjVJ8uxtAAEeiGxtyuscS7EL0KgRBnygls0om7plUa
hCQbB/lnOA==
=KXyz
-----END PGP SIGNATURE-----
Merge tag 'io_uring-6.17-20250828' of git://git.kernel.dk/linux
Pull io_uring fixes from Jens Axboe:
- Use the proper type for min_t() in getting the min of the leftover
bytes and the buffer length.
- As good practice, use READ_ONCE() consistently for reading ring
provided buffer lengths. Additionally, stop looping for incremental
commits if a zero sized buffer is hit, as no further progress can be
made at that point.
* tag 'io_uring-6.17-20250828' of git://git.kernel.dk/linux:
io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths
io_uring/kbuf: fix signedness in this_len calculation
In __blk_mq_update_nr_hw_queues() the return value of
blk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctx
fails, later changing the number of hw_queues or removing disk will
trigger the following warning:
kernfs: can not remove 'nr_tags', no directory
WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160
Call Trace:
remove_files.isra.1+0x38/0xb0
sysfs_remove_group+0x4d/0x100
sysfs_remove_groups+0x31/0x60
__kobject_del+0x23/0xf0
kobject_del+0x17/0x40
blk_mq_unregister_hctx+0x5d/0x80
blk_mq_sysfs_unregister_hctxs+0x94/0xd0
blk_mq_update_nr_hw_queues+0x124/0x760
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
nullb_device_submit_queues_store+0x92/0x120 [null_blk]
kobjct_del() was called unconditionally even if sysfs creation failed.
Fix it by checkig the kobject creation statusbefore deleting it.
Fixes: 477e19dedc ("blk-mq: adjust debugfs and sysfs register when updating nr_hw_queues")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250826084854.1030545-1-linan666@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
1. Add error handling for old state CRTC in atomic_disable
2. Fix DSI host and panel bridge pre-enable order
3. Fix device/node reference count leaks in mtk_drm_get_all_drm_priv
4. mtk_hdmi: Fix inverted parameters in some regmap_update_bits calls
-----BEGIN PGP SIGNATURE-----
iQJMBAABCgA2FiEEACwLKSDmq+9RDv5P4cpzo8lZTiQFAmiw5k4YHGNodW5rdWFu
Zy5odUBrZXJuZWwub3JnAAoJEOHKc6PJWU4klDcP+wXMw/9gEBq7JTaFs9dvtvf7
yXZdoSAmTVgjYT3gArC98kXBA6mbRvKkG4s6M2uJuczVml+6mxarwsLkfFIiRiSB
Nk9lhV84WKdqvSRcVyYuI47Pkp1QR3yPX7UD9OCm9iq+VjQeHNhIxR5GLZ0Rt8wR
5OST60KoNHBH9jWMn9GbWh1FYtqtdvcOWr90ZtKvsyPXyHVXfqsoDy8PJ9X+vwJq
sbgdO2BRd7jEJ8+tcI4ZOJl1x6+Q3RXosYzcxvIXtrDr39ETKLFiloL9o7H27rSU
z6G1xyGo1dOMQ3LGMYQMr0QziqVPVPBDmrd2cv/Nf1yeCCy1E+msqpm0u6vcOJ2x
Soq/zaPUMut5VaHKfIpFOCiKiIKhcxlP5krYg3g4rg4JzxHzCUCfawblQrleNDJx
FUUmHxjELPfuUDbPdAWoq33UVbuUNYpDseSbrGbskKA+gzcYQtwNElae8283fC5H
47W8y1UmwOutbnoTcVW7RRl2RAbjXjjID6tRtbVGHWS5ST5NnxFbcRX1uwzDoC+3
T2UCDYXDhJuhUKeahFfDjwMcvy8BcGqIqo3oqptcpr4hRvGPXaLVL7smWXOJNpgF
qRmN8bbNZjgQlHHdBYN7a9XKRK7nRNmRFtnE9FUQVOmbU7y5q90uOiy4qwZIMw1Q
nmXAMvjQVfjCbemvU6ad
=j/Jq
-----END PGP SIGNATURE-----
Merge tag 'mediatek-drm-fixes-20250829' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes
Mediatek DRM Fixes - 20250829
1. Add error handling for old state CRTC in atomic_disable
2. Fix DSI host and panel bridge pre-enable order
3. Fix device/node reference count leaks in mtk_drm_get_all_drm_priv
4. mtk_hdmi: Fix inverted parameters in some regmap_update_bits calls
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://lore.kernel.org/r/20250828234116.4960-1-chunkuang.hu@kernel.org
Tony Nguyen says:
====================
ice: split ice_virtchnl.c git-blame friendly way
Przemek Kitszel says:
Split ice_virtchnl.c into two more files (+headers), in a way
that git-blame works better.
Then move virtchnl files into a new subdir.
No logic changes.
I have developed (or discovered ;)) how to split a file in a way that
both old and new are nice in terms of git-blame
There was not much discussion on [RFC], so I would like to propose
to go forward with this approach.
There are more commits needed to have it nice, so it forms a git-log vs
git-blame tradeoff, but (after the brief moment that this is on the top)
we spend orders of magnitude more time looking at the blame output (and
commit messages linked from that) - so I find it much better to see
actual logic changes instead of "move xx to yy" stuff (typical for
"squashed/single-commit splits").
Cherry-picks/rebases work the same with this method as with simple
"squashed/single-commit" approach (literally all commits squashed into
one (to have better git-log, but shitty git-blame output).
Rationale for the split itself is, as usual, "file is big and we want to
extend it".
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
ice: finish virtchnl.c split into rss.c
ice: extract virt/rss.c: cleanup - p2
ice: extract virt/rss.c: cleanup - p1
ice: split RSS stuff out of virtchnl.c - copy back
ice: split RSS stuff out of virtchnl.c - tmp rename
ice: finish virtchnl.c split into queues.c
ice: extract virt/queues.c: cleanup - p3
ice: extract virt/queues.c: cleanup - p2
ice: extract virt/queues.c: cleanup - p1
ice: split queue stuff out of virtchnl.c - copy back
ice: split queue stuff out of virtchnl.c - tmp rename
ice: add virt/ and move ice_virtchnl* files there
====================
Link: https://patch.msgid.link/20250827224641.415806-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
s390 and x86 have required LLVM 15 since
30d17fac6a ("scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390")
7861640aac ("x86/build: Raise the minimum LLVM version to 15.0.0")
respectively. This series bumps the rest of the kernel to 15.0.0 to
match, which allows for a decent number of clean ups.
On the distros front, we will only leave behind Debian Bookworm and
Ubuntu Jammy. In both of those cases, builders / developers can either
use the kernel.org toolchains or https://apt.llvm.org to get newer
versions that will run on those distributions, if they cannot upgrade.
archlinux:latest clang version 20.1.8
debian:oldoldstable-slim Debian clang version 11.0.1-2
debian:oldstable-slim Debian clang version 14.0.6
debian:stable-slim Debian clang version 19.1.7 (3+b1)
debian:testing-slim Debian clang version 19.1.7 (3+b1)
debian:unstable-slim Debian clang version 19.1.7 (3+b2)
fedora:41 clang version 19.1.7 (Fedora 19.1.7-4.fc41)
fedora:latest clang version 20.1.8 (Fedora 20.1.8-3.fc42)
fedora:rawhide clang version 20.1.8 (Fedora 20.1.8-3.fc43)
opensuse/leap:latest clang version 17.0.6
opensuse/tumbleweed:latest clang version 20.1.8
ubuntu:focal clang version 10.0.0-4ubuntu1
ubuntu:jammy Ubuntu clang version 14.0.0-1ubuntu1.1
ubuntu:noble Ubuntu clang version 18.1.3 (1ubuntu1)
ubuntu:latest Ubuntu clang version 18.1.3 (1ubuntu1)
ubuntu:rolling Ubuntu clang version 20.1.2 (0ubuntu1)
ubuntu:devel Ubuntu clang version 20.1.8 (0ubuntu1)
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-0-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, two KMSAN checks can be cleaned up.
CONFIG_HAVE_KMSAN_COMPILER will always be true when using clang so
remove the cc-option test and use a simple check for CONFIG_CC_IS_CLANG.
CONFIG_HAVE_KMSAN_PARAM_RETVAL will always be true so it can be removed
outright.
Acked-by: Marco Elver <elver@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-12-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, __no_kcsan will always ensure that the thread
sanitizer functions are not generated, so remove the check for tsan
functions in is_profiling_func() and the always true depends and
unnecessary select lines in KCSAN_WEAK_MEMORY.
Acked-by: Marco Elver <elver@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infraded.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-11-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, the CLANG_VERSION check for older than 14.0.0
is always false, so remove it.
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-10-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, several ld.lld version checks become
tautological, as they are always true. Replace them with a simple
CONFIG_LD_IS_LLD check.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-9-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, CONFIG_RISCV_USE_LINKER_RELAXATION will
always be enabled, so it can be removed.
Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-8-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, there is no need to check the LLD version
before selecting ARCH_SUPPORTS_LTO_CLANG{,_THIN} because it will always
be true.
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-7-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, the zero initializations of val and suffix
added by commit 0d76914a4c ("powerpc/inst: Optimise
copy_inst_from_kernel_nofault()") to avoid a bogus case of
-Wuninitialized can be dropped because the preprocessor condition is
always false.
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-6-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, the selection of
ARCH_HAS_CURRENT_STACK_POINTER can be made unconditional since it is
always true.
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-5-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, two sets of always true conditions can be
safely removed in the arm64 Kconfig file.
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-4-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, the first depends line of
ARM_HAS_GROUP_RELOCS is always true, so it can be safely removed.
Combine the !COMPILE_TEST dependency into the 'def_bool' line and update
the comment as well.
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-3-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 15.0.0, the second depends line in
RANDOMIZE_KSTACK_OFFSET is always true, so it can be removed.
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-2-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
s390 and x86 have required LLVM 15 since
30d17fac6a ("scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390")
7861640aac ("x86/build: Raise the minimum LLVM version to 15.0.0")
respectively but most other architectures allow LLVM 13.0.1 or newer. In
accordance with the recent minimum supported version of GCC bump that
happened in
118c40b7b5 ("kbuild: require gcc-8 and binutils-2.30")
do the same for LLVM to 15.0.0.
Of the supported releases of Arch Linux, Debian, Fedora, and OpenSUSE
surveyed in evaluating this bump, this only leaves behind Debian
Bookworm (14.0.6) and Ubuntu Jammy (14.0.0). Debian Trixie has 19.1.7
and Ubuntu Noble has 18.1.3 (so there are viable upgrade paths) or users
can use apt.llvm.org, which provides even newer packages for those
distributions.
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Schier <nsc@kernel.org>
Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-1-635f3294e5f0@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
mlx5 has a Kconfig co-dependency on VXLAN, even tho it doesn't
call any VXLAN function (unlike mlxsw). Perhaps this dates back
to very old days when tunnel ports were fetched directly from
VXLAN.
Remove the dependency to allow MLX5=y + VXLAN=m kernel configs.
But still avoid compiling in the lib/vxlan code if VXLAN=n.
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://patch.msgid.link/20250827234319.3504852-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The C45 accessors were setting the GR (register number) field twice,
once with the 16-bit register address truncated to five bits, and
then overwritten with the C45 devad. This is harmless since the field
was being cleared prior to being updated with the C45 devad, except
for the extra work.
Remove the redundant code.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/E1urGBn-00000000DCH-3swS@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
net_sched: extend RCU use in dump() methods (II)
Second series adding RCU dump() to three actions
First patch removes BH blocking on modules done in the first series.
====================
Link: https://patch.msgid.link/20250827125349.3505302-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Also storing tcf_action into struct tcf_skbmod_params
makes sure there is no discrepancy in tcf_skbmod_act().
No longer block BH in tcf_skbmod_init() when acquiring tcf_lock.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250827125349.3505302-5-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Also storing tcf_action into struct tcf_tunnel_key_params
makes sure there is no discrepancy in tunnel_key_act().
No longer block BH in tunnel_key_init() when acquiring tcf_lock.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250827125349.3505302-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Also storing tcf_action into struct tcf_vlan_params
makes sure there is no discrepancy in tcf_vlan_act().
No longer block BH in tcf_vlan_init() when acquiring tcf_lock.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250827125349.3505302-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Followup of f45b45cbfa ("Merge branch
'net_sched-act-extend-rcu-use-in-dump-methods'")
We never grab tcf_lock from BH context in these modules:
act_connmark
act_csum
act_ct
act_ctinfo
act_mpls
act_nat
act_pedit
act_skbedit
No longer block BH when acquiring tcf_lock from init functions.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250827125349.3505302-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
stmmac_bus_clks_config() doesn't need to repeatedly on dereference
priv->plat as this remains the same throughout this function. Not only
does this detract from the function's readability, but it could cause
the value to be reloaded each time. Use a local variable.
Also, the final return can simply return zero, and we can dispense
with the initialiser for 'ret'.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/E1urBvf-000000002ii-37Ce@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdev_priv() is an inline function, taking a struct net_device
pointer. When passing in the MII bus->priv, which is a void pointer,
there is no need to go via a local ndev variable to type it first.
Thus, instead of:
struct net_device *ndev = bus->priv;
struct stmmac_priv *priv;
...
priv = netdev_priv(ndev);
we can simply do:
struct stmmac_priv *priv = netdev_priv(bus->priv);
which simplifies the code.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
Link: https://patch.msgid.link/E1urBj2-000000002as-0pod@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add LED support for MT7988's built-in 2.5Gphy. LED hardware has almost
the same design with MT7981's/MT7988's built-in GbE. So hook the same
helper function here.
Before mtk_phy_leds_state_init(), set correct default values of LED0
and LED1.
Signed-off-by: Sky Huang <skylake.huang@mediatek.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250827044755.3256991-1-SkyLake.Huang@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add missing locking annotations to two recently introduced
list_for_each_entry_rcu() loops in the core device suspend/resume
code (Johannes Berg)
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmiws2ESHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1hSIIAI8UeQnihDtPYR0bklyzENW/g17Du/4M
UZPxd50YB4xSofLhHDZCf214Yg5vihV3Hdj51XkDn+Wyd2HTYC5GW/qLcUL9gpLj
MflA6O0ZtYpAE3bByK+XI4Wwas05h/LuF63ty8i+2zrS7NV7EaFa1+3Hj7wgQ7wZ
QGsaTdet3kxgJa/KbLOkzXayrLiAk4OtrFpABu+8cjzHi1wDg8on00+zW1FN5b9U
f14jsdds+as1usw6Gf8lSSUgtLNQ/kQ41Btg2naG4B6TD9N9WpVwkx1TCrXcDj2E
Wff/dTSfBU8As8D9ZPr4HOk9tmFmdwcFareT4wRBljbys6ixgYvxGX8=
=9Avh
-----END PGP SIGNATURE-----
Merge tag 'pm-6.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Add missing locking annotations to two recently introduced
list_for_each_entry_rcu() loops in the core device suspend/resume
code (Johannes Berg)"
* tag 'pm-6.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
PM: sleep: annotate RCU list iterations
In mtk_hdmi driver, a recent change replaced custom register access
function calls by regmap ones, but two replacements by regmap_update_bits
were done incorrectly, because original offset and mask parameters were
inverted, so fix them.
Fixes: d6e25b3590 ("drm/mediatek: hdmi: Use regmap instead of iomem for main registers")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/dri-devel/patch/20250818-mt8173-fix-hdmi-issue-v1-1-55aff9b0295d@collabora.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Commit 0d6ccfe6b3 ("selftests: drv-net: rss_ctx: check for all-zero keys")
added a skip exception if NIC has fewer than 3 queues enabled,
but it's just constructing the object, it's not actually rising
this exception.
Before:
# Exception| net.lib.py.utils.CmdExitFailure: Command failed: ethtool -X enp1s0 equal 3 hkey d1:cc:77:47:9d:ea:15:f2:b9:6c:ef:68:62:c0:45:d5:b0:99:7d:cf:29:53:40:06:3d:8e:b9:bc:d4:70:89:b8:8d:59:04:ea:a9:c2:21:b3:55:b8:ab:6b:d9:48:b4:bd:4c:ff:a5:f0:a8:c2
not ok 1 rss_ctx.test_rss_key_indir
After:
ok 1 rss_ctx.test_rss_key_indir # SKIP Device has fewer than 3 queues (or doesn't support queue stats)
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250827173558.3259072-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Dragos Tatulea says:
====================
devmem/io_uring: allow more flexibility for ZC DMA devices
For TCP zerocopy rx (io_uring, devmem), there is an assumption that the
parent device can do DMA. However that is not always the case:
- Scalable Function netdevs [1] have the DMA device in the grandparent.
- For Multi-PF netdevs [2] queues can be associated to different DMA
devices.
The series adds an API for getting the DMA device for a netdev queue.
Drivers that have special requirements can implement the newly added
queue management op. Otherwise the parent will still be used as before.
This series continues with switching to this API for io_uring zcrx and
devmem and adds a ndo_queue_dma_dev op for mlx5.
The last part of the series changes devmem rx bind to get the DMA device
per queue and blocks the case when multiple queues use different DMA
devices. The tx bind is left as is.
[1] Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
[2] Documentation/networking/multi-pf-netdev.rst
====================
Link: https://patch.msgid.link/20250827144017.1529208-2-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Multi-PF netdevs have queues belonging to different PFs which also means
different DMA devices. This means that the binding on the DMA buffer can
be done to the incorrect device.
This change allows devmem binding to multiple queues only when the
queues have the same DMA device. Otherwise an error is returned.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Link: https://patch.msgid.link/20250827144017.1529208-9-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Instead of reading the requested rx queues after binding the buffer,
read the rx queues in advance in a bitmap and iterate over them when
needed.
This is a preparation for fetching the DMA device for each queue.
This patch has no functional changes besides adding an extra
rq index bounds check.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20250827144017.1529208-8-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fetch the DMA device before calling net_devmem_bind_dmabuf()
and pass it on as a parameter.
This is needed for an upcoming change which will read the
DMA device per queue.
This patch has no functional changes.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20250827144017.1529208-7-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For zero-copy (devmem, io_uring), the netdev DMA device used
is the parent device of the net device. However that is not
always accurate for mlx5 devices:
- SFs: The parent device is an auxdev.
- Multi-PF netdevs: The DMA device should be determined by
the queue.
This change implements the DMA device queue API that returns the DMA
device appropriately for all cases.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20250827144017.1529208-6-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Switch to the new API for fetching DMA devices for a netdev. The API is
called with queue index 0 for now which is equivalent with the previous
behavior.
This patch will allow devmem to work with devices where the DMA device
is not stored in the parent device. mlx5 SFs are an example of such a
device.
Multi-PF netdevs are still problematic (as they were before this
change). Upcoming patches will address this for the rx binding.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20250827144017.1529208-5-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use the new API for getting a DMA device for a specific netdev queue.
This patch will allow io_uring zero-copy rx to work with devices
where the DMA device is not stored in the parent device. mlx5 SFs
are an example of such a device.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/20250827144017.1529208-4-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For zerocopy (io_uring, devmem), there is an assumption that the
parent device can do DMA. However that is not always the case:
- Scalable Function netdevs [1] have the DMA device in the grandparent.
- For Multi-PF netdevs [2] queues can be associated to different DMA
devices.
This patch introduces the a queue based interface for allowing drivers
to expose a different DMA device for zerocopy.
[1] Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
[2] Documentation/networking/multi-pf-netdev.rst
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20250827144017.1529208-3-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- another small fix relevant to arm64 systems with memory encryption
(Shanker Donthineni)
- fix relevant to arm32 systems with non-standard CMA configuration
(Oreoluwa Babatunde)
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSrngzkoBtlA8uaaJ+Jp1EFxbsSRAUCaLAK7gAKCRCJp1EFxbsS
REDxAQC+5hLiyzc/1rR5EQb1D6Xr1f/0VN3IFz3creHp3juFBAEApi1iFMdmahO7
0YKG4KkzHpcNkGrxaXKP0VNtQsDLwww=
=fVrB
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-6.17-2025-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux
Pull dma-mapping fixes from Marek Szyprowski:
- another small fix for arm64 systems with memory encryption (Shanker
Donthineni)
- fix for arm32 systems with non-standard CMA configuration (Oreoluwa
Babatunde)
* tag 'dma-mapping-6.17-2025-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted
of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
