summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-04drm/xe: Fix GT "for each engine" workaroundsTvrtko Ursulin
Any rules using engine matching are currently broken due RTP processing happening too in early init, before the list of hardware engines has been initialised. Fix this by moving workaround processing to later in the driver probe sequence, to just before the processed list is used for the first time. Looking at the debugfs gt0/workarounds on ADL-P we notice 14011060649 should be present while we see, before: GT Workarounds 14011059788 14015795083 And with the patch: GT Workarounds 14011060649 14011059788 14015795083 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v6.11+ Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-2-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 25d434cef791e03cf40680f5441b576c639bfa84) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/xe/userptr: properly setup pfn_flags_maskMatthew Auld
Currently we just leave it uninitialised, which at first looks harmless, however we also don't zero out the pfn array, and with pfn_flags_mask the idea is to be able set individual flags for a given range of pfn or completely ignore them, outside of default_flags. So here we end up with pfn[i] & pfn_flags_mask, and if both are uninitialised we might get back an unexpected flags value, like asking for read only with default_flags, but getting back write on top, leading to potentially bogus behaviour. To fix this ensure we zero the pfn_flags_mask, such that hmm only considers the default_flags and not also the initial pfn[i] value. v2 (Thomas): - Prefer proper initializer. Fixes: 81e058a3e7fd ("drm/xe: Introduce helper to populate userptr") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226174748.294285-2-matthew.auld@intel.com (cherry picked from commit dd8c01e42f4c5c1eaf02f003d7d588ba6706aa71) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/i915/mst: update max stream count to match number of pipesJani Nikula
We create the stream encoders and attach connectors for each pipe we have. As the number of pipes has increased, we've failed to update the topology manager maximum number of payloads to match that. Bump up the max stream count to match number of pipes, enabling the fourth stream on platforms that support four pipes. Cc: stable@vger.kernel.org Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226135626.1956012-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 15bccbfb78d63a2a621b30caff8b9424160c6c89) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/xe: Remove double pageflipMaarten Lankhorst
This is already handled below in the code by fixup_initial_plane_config. Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of ggtt") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-3-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit 2218704997979fbf11765281ef752f07c5cf25bb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-05docs: Kconfig: fix defconfig descriptionSatoru Takeuchi
Commit 2a86f6612164 ("kbuild: use KBUILD_DEFCONFIG as the fallback for DEFCONFIG_LIST") removed arch/$ARCH/defconfig; however, the document has not been updated to reflect this change yet. Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-05kbuild: hdrcheck: fix cross build with clangArnd Bergmann
The headercheck tries to call clang with a mix of compiler arguments that don't include the target architecture. When building e.g. x86 headers on arm64, this produces a warning like clang: warning: unknown platform, assuming -mfloat-abi=soft Add in the KBUILD_CPPFLAGS, which contain the target, in order to make it build properly. See also 1b71c2fb04e7 ("kbuild: userprogs: fix bitsize and target detection on clang"). Reviewed-by: Nathan Chancellor <nathan@kernel.org> Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-04Merge tag 'devicetree-fixes-for-6.14-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fix from Rob Herring: - Revert reserved-memory 'alignment' property to use '#address-cells' instead of '#size-cells'. What's in use trumps the spec. * tag 'devicetree-fixes-for-6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: Revert "of: reserved-memory: Fix using wrong number of cells to get property 'alignment'"
2025-03-05kbuild: userprogs: use correct lld when linking through clangThomas Weißschuh
The userprog infrastructure links objects files through $(CC). Either explicitly by manually calling $(CC) on multiple object files or implicitly by directly compiling a source file to an executable. The documentation at Documentation/kbuild/llvm.rst indicates that ld.lld would be used for linking if LLVM=1 is specified. However clang instead will use either a globally installed cross linker from $PATH called ${target}-ld or fall back to the system linker, which probably does not support crosslinking. For the normal kernel build this is not an issue because the linker is always executed directly, without the compiler being involved. Explicitly pass --ld-path to clang so $(LD) is respected. As clang 13.0.1 is required to build the kernel, this option is available. Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs") Cc: stable@vger.kernel.org # needs wrapping in $(cc-option) for < 6.9 Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-04fs/pipe: Read pipe->{head,tail} atomically outside pipe->mutexLinus Torvalds
pipe_readable(), pipe_writable(), and pipe_poll() can read "pipe->head" and "pipe->tail" outside of "pipe->mutex" critical section. When the head and the tail are read individually in that order, there is a window for interruption between the two reads in which both the head and the tail can be updated by concurrent readers and writers. One of the problematic scenarios observed with hackbench running multiple groups on a large server on a particular pipe inode is as follows: pipe->head = 36 pipe->tail = 36 hackbench-118762 [057] ..... 1029.550548: pipe_write: *wakes up: pipe not full* hackbench-118762 [057] ..... 1029.550548: pipe_write: head: 36 -> 37 [tail: 36] hackbench-118762 [057] ..... 1029.550548: pipe_write: *wake up next reader 118740* hackbench-118762 [057] ..... 1029.550548: pipe_write: *wake up next writer 118768* hackbench-118768 [206] ..... 1029.55055X: pipe_write: *writer wakes up* hackbench-118768 [206] ..... 1029.55055X: pipe_write: head = READ_ONCE(pipe->head) [37] ... CPU 206 interrupted (exact wakeup was not traced but 118768 did read head at 37 in traces) hackbench-118740 [057] ..... 1029.550558: pipe_read: *reader wakes up: pipe is not empty* hackbench-118740 [057] ..... 1029.550558: pipe_read: tail: 36 -> 37 [head = 37] hackbench-118740 [057] ..... 1029.550559: pipe_read: *pipe is empty; wakeup writer 118768* hackbench-118740 [057] ..... 1029.550559: pipe_read: *sleeps* hackbench-118766 [185] ..... 1029.550592: pipe_write: *New writer comes in* hackbench-118766 [185] ..... 1029.550592: pipe_write: head: 37 -> 38 [tail: 37] hackbench-118766 [185] ..... 1029.550592: pipe_write: *wakes up reader 118766* hackbench-118740 [185] ..... 1029.550598: pipe_read: *reader wakes up; pipe not empty* hackbench-118740 [185] ..... 1029.550599: pipe_read: tail: 37 -> 38 [head: 38] hackbench-118740 [185] ..... 1029.550599: pipe_read: *pipe is empty* hackbench-118740 [185] ..... 1029.550599: pipe_read: *reader sleeps; wakeup writer 118768* ... CPU 206 switches back to writer hackbench-118768 [206] ..... 1029.550601: pipe_write: tail = READ_ONCE(pipe->tail) [38] hackbench-118768 [206] ..... 1029.550601: pipe_write: pipe_full()? (u32)(37 - 38) >= 16? Yes hackbench-118768 [206] ..... 1029.550601: pipe_write: *writer goes back to sleep* [ Tasks 118740 and 118768 can then indefinitely wait on each other. ] The unsigned arithmetic in pipe_occupancy() wraps around when "pipe->tail > pipe->head" leading to pipe_full() returning true despite the pipe being empty. The case of genuine wraparound of "pipe->head" is handled since pipe buffer has data allowing readers to make progress until the pipe->tail wraps too after which the reader will wakeup a sleeping writer, however, mistaking the pipe to be full when it is in fact empty can lead to readers and writers waiting on each other indefinitely. This issue became more problematic and surfaced as a hang in hackbench after the optimization in commit aaec5a95d596 ("pipe_read: don't wake up the writer if the pipe is still full") significantly reduced the number of spurious wakeups of writers that had previously helped mask the issue. To avoid missing any updates between the reads of "pipe->head" and "pipe->write", unionize the two with a single unsigned long "pipe->head_tail" member that can be loaded atomically. Using "pipe->head_tail" to read the head and the tail ensures the lockless checks do not miss any updates to the head or the tail and since those two are only updated under "pipe->mutex", it ensures that the head is always ahead of, or equal to the tail resulting in correct calculations. [ prateek: commit log, testing on x86 platforms. ] Reported-and-debugged-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Closes: https://lore.kernel.org/lkml/e813814e-7094-4673-bc69-731af065a0eb@amd.com/ Reported-by: Alexey Gladkov <legion@kernel.org> Closes: https://lore.kernel.org/all/Z8Wn0nTvevLRG_4m@example.org/ Fixes: 8cefc107ca54 ("pipe: Use head and tail pointers for the ring, not cursor and length") Tested-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Alexey Gladkov <legion@kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-03-04KVM: x86: Explicitly zero EAX and EBX when PERFMON_V2 isn't supported by KVMXiaoyao Li
Fix a goof where KVM sets CPUID.0x80000022.EAX to CPUID.0x80000022.EBX instead of zeroing both when PERFMON_V2 isn't supported by KVM. In practice, barring a buggy CPU (or vCPU model when running nested) only the !enable_pmu case is affected, as KVM always supports PERFMON_V2 if it's available in hardware, i.e. CPUID.0x80000022.EBX will be '0' if PERFMON_V2 is unsupported. For the !enable_pmu case, the bug is relatively benign as KVM will refuse to enable PMU capabilities, but a VMM that reflects KVM's supported CPUID into the guest could inadvertently induce #GPs in the guest due to advertising support for MSRs that KVM refuses to emulate. Fixes: 94cdeebd8211 ("KVM: x86/cpuid: Add AMD CPUID ExtPerfMonAndDbg leaf 0x80000022") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250304082314.472202-3-xiaoyao.li@intel.com [sean: massage shortlog and changelog, tag for stable] Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-03-04Merge tag 'wireless-2025-03-04' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== bugfixes for 6.14: * regressions from this cycle: - mac80211: fix sparse warning for monitor - nl80211: disable multi-link reconfiguration (needs fixing) * older issues: - cfg80211: reject badly combined cooked monitor, fix regulatory hint validity checks - mac80211: handle TXQ flush w/o driver per-sta flush, fix debugfs for monitor, fix element inheritance - iwlwifi: fix rfkill, dead firmware handling, rate API version, free A-MSDU handling, avoid large allocations, fix string format - brcmfmac: fix power handling on some boards * tag 'wireless-2025-03-04' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: nl80211: disable multi-link reconfiguration wifi: cfg80211: regulatory: improve invalid hints checking wifi: brcmfmac: keep power during suspend if board requires it wifi: mac80211: Fix sparse warning for monitor_sdata wifi: mac80211: fix vendor-specific inheritance wifi: mac80211: fix MLE non-inheritance parsing wifi: iwlwifi: Fix A-MSDU TSO preparation wifi: iwlwifi: Free pages allocated when failing to build A-MSDU wifi: iwlwifi: limit printed string from FW file wifi: iwlwifi: mvm: use the right version of the rate API wifi: iwlwifi: mvm: don't try to talk to a dead firmware wifi: iwlwifi: mvm: don't dump the firmware state upon RFKILL while suspend wifi: iwlwifi: mvm: clean up ROC on failure wifi: iwlwifi: fw: avoid using an uninitialized variable wifi: iwlwifi: fw: allocate chained SG tables for dump wifi: mac80211: remove debugfs dir for virtual monitor wifi: mac80211: Cleanup sta TXQs on flush wifi: nl80211: reject cooked mode if it is set along with other flags ==================== Link: https://patch.msgid.link/20250304124435.126272-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04s390/ftrace: Fix return address recovery of traced functionSumanth Korikkar
When fgraph is enabled the traced function return address is replaced with trampoline return_to_handler(). The original return address of the traced function is saved in per task return stack along with a stack pointer for reliable stack unwinding via function_graph_enter_regs(). During stack unwinding e.g. for livepatching, ftrace_graph_ret_addr() identifies the original return address of the traced function with the saved stack pointer. With a recent change, the stack pointers passed to ftrace_graph_ret_addr() and function_graph_enter_regs() do not match anymore, and therefore the original return address is not found. Pass the correct stack pointer to function_graph_enter_regs() to fix this. Fixes: 7495e179b478 ("s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC") Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2025-03-04selftests/vDSO: Fix GNU hash table entry size for s390xThomas Weißschuh
Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x") changed the type of the ELF hash table entries to 64bit on s390x. However the *GNU* hash tables entries are always 32bit. The "bucket" pointer is shared between both hash algorithms. On s390, this caused the GNU hash algorithm to access its 32-bit entries as if they were 64-bit, triggering compiler warnings (assignment between "Elf64_Xword *" and "Elf64_Word *") and runtime crashes. Introduce a new dedicated "gnu_bucket" pointer which is used by the GNU hash. Fixes: e0746bde6f82 ("selftests/vDSO: support DT_GNU_HASH") Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20250217-selftests-vdso-s390-gnu-hash-v2-1-f6c2532ffe2a@linutronix.de Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2025-03-04s390/traps: Fix test_monitor_call() inline assemblyHeiko Carstens
The test_monitor_call() inline assembly uses the xgr instruction, which also modifies the condition code, to clear a register. However the clobber list of the inline assembly does not specify that the condition code is modified, which may lead to incorrect code generation. Use the lhi instruction instead to clear the register without that the condition code is modified. Furthermore this limits clearing to the lower 32 bits of val, since its type is int. Fixes: 17248ea03674 ("s390: fix __EMIT_BUG() macro") Cc: stable@vger.kernel.org Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2025-03-04ALSA: hda: realtek: fix incorrect IS_REACHABLE() usageArnd Bergmann
The alternative path leads to a build error after a recent change: sound/pci/hda/patch_realtek.c: In function 'alc233_fixup_lenovo_low_en_micmute_led': include/linux/stddef.h:9:14: error: called object is not a function or function pointer 9 | #define NULL ((void *)0) | ^ sound/pci/hda/patch_realtek.c:5041:49: note: in expansion of macro 'NULL' 5041 | #define alc233_fixup_lenovo_line2_mic_hotkey NULL | ^~~~ sound/pci/hda/patch_realtek.c:5063:9: note: in expansion of macro 'alc233_fixup_lenovo_line2_mic_hotkey' 5063 | alc233_fixup_lenovo_line2_mic_hotkey(codec, fix, action); Using IS_REACHABLE() is somewhat questionable here anyway since it leads to the input code not working when the HDA driver is builtin but input is in a loadable module. Replace this with a hard compile-time dependency on CONFIG_INPUT. In practice this won't chance much other than solve the compiler error because it is rare to require sound output but no input support. Fixes: f603b159231b ("ALSA: hda/realtek - add supported Mic Mute LED for Lenovo platform") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250304142620.582191-1-arnd@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-04docs: iio: ad7380: add adaq4381-4Julien Stephan
adaq4381-4 is the 14 bits version of adaq4380-1 chip. Add it to the documentation. Signed-off-by: Julien Stephan <jstephan@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250226-ad7380-add-adaq4381-4-support-v1-3-f350ab872d37@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04dt-bindings: iio: adc: ad7380: add adaq4381-4 compatible partsJulien Stephan
adaq4381-4 is the 14 bits version of adaq4380-1 chip. Add support for it. Signed-off-by: Julien Stephan <jstephan@baylibre.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250226-ad7380-add-adaq4381-4-support-v1-2-f350ab872d37@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: ad7380: add adaq4381-4 supportJulien Stephan
adaq4381-4 is the 14 bits version of adaq4380-1 chip. Add support for it. Signed-off-by: Julien Stephan <jstephan@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250226-ad7380-add-adaq4381-4-support-v1-1-f350ab872d37@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: rockchip_saradc: add rk3562Simon Xue
rk3562 is using v2 saradc with 8 channels. Signed-off-by: Simon Xue <xxm@rock-chips.com> Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Link: https://patch.msgid.link/20250227110343.2342017-2-kever.yang@rock-chips.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04dt-bindings: iio: adc: Add rockchip,rk3562-saradc stringKever Yang
Add rockchip,rk3562-saradc compatible string. The saradc on rk3562 is v2 controller, with 10bit width which is different with rk3588. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250227110343.2342017-1-kever.yang@rock-chips.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: ad4030: fix error pointer dereference in probe()Dan Carpenter
The intention here was obviously to return an error if devm_regmap_init() fails, but the return statement was accidentally left out. This leads to an error pointer dereference when we call: ret = ad4030_detect_chip_info(st); Add the return statement. Fixes: ec25cf6f1ee3 ("iio: adc: ad4030: add support for ad4632-16 and ad4632-24") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/cc67cee7-9c65-46d2-aae3-f860fc3cc461@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: light: Fix spelling mistake "regist" -> "register"Colin Ian King
There are spelling mistakes in dev_err messages. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20250228090228.679535-1-colin.i.king@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: buffer-dma: Fix docstringsFolker Schwesinger
Fix a typo in the docstring of iio_dma_buffer_read() and fix what looks like a copy-and-paste error in the iio_dma_buffer_write() docstring. Signed-off-by: Folker Schwesinger <dev@folker-schwesinger.de> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/D83IPSTKYWNB.1PUBV1530XI86@folker-schwesinger.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: rockchip_saradc: Add support for RK3528Jonas Karlman
The Successive Approximation ADC (SARADC) in RK3528 uses the v2 controller and support: - 10-bit resolution - Up to 1MS/s sampling rate - 4 single-ended input channels - Current consumption: 0.5mA @ 1MS/s Add support for the 4 channels of 10-bit resolution supported by SARADC in RK3528. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20250227184058.2964204-3-jonas@kwiboo.se Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04dt-bindings: iio: adc: Add rockchip,rk3528-saradc variantJonas Karlman
The Successive Approximation ADC (SARADC) in RK3528 uses the v2 controller and support: - 10-bit resolution - Up to 1MS/s sampling rate - 4 single-ended input channels - Current consumption: 0.5mA @ 1MS/s Add a rockchip,rk3562-saradc compatible string for the 4 channels of 10-bit resolution supported by SARADC in RK3528. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20250227184058.2964204-2-jonas@kwiboo.se Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04MAINTAINERS: remove adi,ad7606.yaml from SEPS525David Lechner
Remove Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml from STAGING - SEPS525 LCD CONTROLLER DRIVERS. This was likley a copy/paste mistake. There is no bindings file for SEPS525 since it is only in staging. The removed file matches Documentation/devicetree/bindings/iio/*/adi,* under ANALOG DEVICES INC IIO DRIVERS already so wasn't just misplaced. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250303-maintainers-remove-adi-ad7606-yaml-from-seps525-lcd-controller-v1-1-a4e4f1b824ab@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: imu: adis: fix uninitialized symbol warningsunliming
Fix below kernel warning: smatch warnings: drivers/iio/imu/adis.c:319 __adis_check_status() error: uninitialized symbol 'status_16'. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: sunliming <sunliming@kylinos.cn> Link: https://patch.msgid.link/20250304060518.1834910-1-sunliming@linux.dev Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04usb: xhci: Fix host controllers "dying" after suspend and resumeMichal Pecio
A recent cleanup went a bit too far and dropped clearing the cycle bit of link TRBs, so it stays different from the rest of the ring half of the time. Then a race occurs: if the xHC reaches such link TRB before more commands are queued, the link's cycle bit unintentionally matches the xHC's cycle so it follows the link and waits for further commands. If more commands are queued before the xHC gets there, inc_enq() flips the bit so the xHC later sees a mismatch and stops executing commands. This function is called before suspend and 50% of times after resuming the xHC is doomed to get stuck sooner or later. Then some Stop Endpoint command fails to complete in 5 seconds and this shows up xhci_hcd 0000:00:10.0: xHCI host not responding to stop endpoint command xhci_hcd 0000:00:10.0: xHCI host controller not responding, assume dead xhci_hcd 0000:00:10.0: HC died; cleaning up followed by loss of all USB decives on the affected bus. That's if you are lucky, because if Set Deq gets stuck instead, the failure is silent. Likely responsible for kernel bug 219824. I found this while searching for possible causes of that regression and reproduced it locally before hearing back from the reporter. To repro, simply wait for link cycle to become set (debugfs), then suspend, resume and wait. To accelerate the failure I used a script which repeatedly starts and stops a UVC camera. Some HCs get fully reinitialized on resume and they are not affected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219824 Fixes: 36b972d4b7ce ("usb: xhci: improve xhci_clear_command_ring()") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250304113147.3322584-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-04iio: adc: ad4851: Fix signedness bug in ad4851_calibrate()Dan Carpenter
The "c" variable is used to store error codes from ad4851_find_opt() so it has to be signed for the error handling to work. Change it to type int. Fixes: 6250803fe2ec ("iio: adc: ad4851: add ad485x driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/f5e260e9-d7a8-4dae-b7ea-f1bbb1760e60@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: accel: adxl345: reorganize irq handlerLothar Rubusch
Reorganize the IRQ handler. Move the overrun handling to the bottom. Overrun leads to reset the interrupt register. This also happens at evaluation of a particular interrupt event. First evaluate an event if possible, then fall back to overrun handling. Additionally simplify fetching the interrupt status function. Both is in preparation to build interrupt handling up for the handling of different detected events, implemented in follow up patches. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250220104234.40958-4-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: accel: adxl345: add debug register accessLothar Rubusch
Add the possibility to verify the content of the configuration registers of the sensor in preparation for upcomming feature implementations. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250220104234.40958-3-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: accel: adxl345: reorganize measurement enableLothar Rubusch
Move the measurement enable function up in order to have it generically available. This is a preparation for upcomming patches. Particular features need to have measuring off while changing settings, and turned on again afterwards. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250220104234.40958-2-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: imu: bmi270: add support for data ready interrupt triggerGustavo Silva
The BMI270 sensor provides two interrupt pins that can be used for different interrupt sources, including a data ready signal. Add support for configuring one the pins as a trigger source. The interrupt pin can be configured with various options: active high or low, push-pull or open-drain, and latched or non-latched. Acked-by: Alex Lanzano <lanzano.alex@gmail.com> Signed-off-by: Gustavo Silva <gustavograzs@gmail.com> Link: https://patch.msgid.link/20250228-bmi270-irq-v2-3-3f97a4e8f551@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: imu: bmi270: rename variable bmi270_device to dataGustavo Silva
Rename all instances of 'struct bmi270_data' to 'data', to ensure consistency across the driver. Also rename bmi270_data::data to bmi270_data::buffer to avoid naming conflicts. Acked-by: Alex Lanzano <lanzano.alex@gmail.com> Signed-off-by: Gustavo Silva <gustavograzs@gmail.com> Link: https://patch.msgid.link/20250228-bmi270-irq-v2-2-3f97a4e8f551@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04Documentation: iio: Add ADC documentationMarcelo Schmitt
ADC inputs can be classified into a few different types according to how they measure the input signal, how restrained the signal is, and number of input pins. Even though datasheets tend to provide many details about their inputs and measurement procedures, it may not always be clear how to model those inputs into IIO channels. For example, some differential ADCs can have their inputs configured into pseudo-differential channels. In that configuration, only one input connects to the signal of interest as opposed to using two inputs of a differential input configuration. Datasheets sometimes also refer to pseudo-differential inputs as single-ended inputs even though they have distinct physical configuration and measurement procedure. Document consolidated ADC input types and how they are usually described and supported in device tree and IIO, respectively. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/e6ac2a595f06ba2d5ff0eb86e5895479c9dd797f.1739998491.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: Include cleanup.h when using guard()Matti Vaittinen
Directly include the cleanup.h for the guard() instead of relying it to be included via other files. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/5b352ce7241e5904a317dd26950c7cd4daa59fc0.1740748394.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: imu: bmi270: move private struct declaration to source fileGustavo Silva
The device's private data struct is currently declared in the header file, but it does not need to be exposed there. Move it to the driver's core source file to avoid unnecessary #include directives or forward declarations in the header. Signed-off-by: Gustavo Silva <gustavograzs@gmail.com> Acked-by: Alex Lanzano <lanzano.alex@gmail.com> Link: https://patch.msgid.link/20250219-bmi270-irq-v1-1-145d02bbca3b@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: dac: adi-axi-dac: add io_mode checkAngelo Dureghello
Add safe check to the high bound of the enum values, Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Link: https://patch.msgid.link/20250219-wip-bl-axi-dac-add-enum-check-v1-1-8de9db0b3b1b@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: gyro: bmg160_i2c: add BMI088 to of_match_tableJun Yan
BMI088 is missing from the of_match_table. Let's complete it. Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Link: https://patch.msgid.link/20250220165001.273325-3-jerrysteve1101@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04docs: iio: fix wrong driver name in documentationLothar Rubusch
The ADXL380/382 documentation uses in one place a wrong driver name. Adds no functional change. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250221194658.41358-1-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: ad4695: simplify getting oversampling_ratioDavid Lechner
We already have a local variable that holds a pointer to st->channels_cfg[chan->scan_index]. Use that to simplify the code. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250218-iio-adc-ad4695-fix-out-of-bounds-array-access-v1-2-57fef8c7a3fd@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: ad4695: fix out of bounds array accessDavid Lechner
Fix some out of bounds array access of st->channels_cfg in the ad4695 driver. This array only has elements for voltage channels, but it was also being accessed for the temperature channel in a few cases causing reading past the end of the array. In some cases, this was harmless because the value was read but not used. However, the in_temp_sampling_frequency attribute shares code with the in_voltageY_sampling_frequency attributes and was trying to read the oversampling ratio from the st->channels_cfg array. This resulted in a garbage value being used in the calculation and the resulting in_temp_sampling_frequency value was incorrect. To fix, make sure we always check that we are dealing with a voltage channel before accessing the st->channels_cfg array and use an oversampling ratio of 1 for the temperature channel (multiplicative identity value) since that channel doesn't support oversampling. Fixes: 67d63185db79 ("iio: adc: ad4695: add offload-based oversampling support") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250218-iio-adc-ad4695-fix-out-of-bounds-array-access-v1-1-57fef8c7a3fd@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: adi-axi-adc: replace of.h with mod_devicetable.hNuno Sá
Don't use of.h in order to include mod_devicetable.h. Use it directly as there no direct dependency on OF. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250218-dev-axi-adc-fix-headers-v1-1-5ddc79221d8c@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: core: make use of simple_write_to_buffer()Nuno Sá
Instead of open coding (kind of) simple_write_to_buffer(), use it. While at it, use ascii representation to terminate the string as that is the more common way of doing it. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250218-dev-iio-misc-v1-2-bf72b20a1eb8@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: backend: make sure to NULL terminate stack bufferNuno Sá
Make sure to NULL terminate the buffer in iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a stack variable so we should not assume it will 0 initialized. Fixes: cdf01e0809a4 ("iio: backend: add debugFs interface") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250218-dev-iio-misc-v1-1-bf72b20a1eb8@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: Switch to sparse friendly iio_device_claim/release_direct()Jonathan Cameron
Single patch for all the relatively simple cases. These new functions allow sparse to find failures to release direct mode reducing chances of bugs over the claim_direct_mode() functions that are deprecated. Cc: Olivier Moysan <olivier.moysan@foss.st.com> Cc: Phil Reid <preid@electromag.com.au> Reviewed-by: Mike Looijmans <mike.looijmans@topic.nl> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250217141630.897334-30-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: max11410: Switch to sparse friendly iio_device_claim/release_direct()Jonathan Cameron
These new functions allow sparse to find failures to release direct mode reducing chances of bugs over the claim_direct_mode() functions that are deprecated. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250217141630.897334-27-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: max11410: Factor out writing of sampling frequency to simplify ↵Jonathan Cameron
errro paths. Introduce __max11410_write_samp_freq() helper and use guard() to avoid need for manual unlock of the mutex. This allows direct returns and simplifies the resulting error handling. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250217141630.897334-26-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: max1027: Switch to sparse friendly iio_device_claim/release_direct()Jonathan Cameron
These new functions allow sparse to find failures to release direct mode reducing chances of bugs over the claim_direct_mode() functions that are deprecated. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20250217141630.897334-25-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-03-04iio: adc: max1027: Move claim of direct mode up one level and use guard()Jonathan Cameron
Move iio_device_claim_direct_mode() into the read_raw() callback and use guard() to release a mutex. This enables simpler error handling via direct returns. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20250217141630.897334-24-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit (git 2.34.1) at 2025-09-22 01:14:57 +0000