summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-10hyperv: Add new Hyper-V headers in include/hypervNuno Das Neves
These headers contain definitions for regular Hyper-V guests (as in hyperv-tlfs.h), as well as interfaces for more privileged guests like the root partition (aka Dom0). These files are derived from headers exported from Hyper-V, rather than being derived from the TLFS document. (Although, to preserve compatibility with existing Linux code, some definitions are copied directly from hyperv-tlfs.h too). The new files follow a naming convention according to their original use: - hdk "host development kit" - gdk "guest development kit" With postfix "_mini" implying userspace-only headers, and "_ext" for extended hypercalls. The use of multiple files and their original names is primarily to keep the provenance of exactly where they came from in Hyper-V code, which is helpful for manual maintenance and extension of these definitions. Microsoft maintainers importing new definitions should take care to put them in the right file. However, Linux kernel code that uses any of the definitions need not be aware of the multiple files or assign any meaning to the new names. Linux kernel code should always just include hvhdk.h Note the new headers contain both arm64 and x86_64 definitions. Some are guarded by #ifdefs, and some are instead prefixed with the architecture, e.g. hv_x64_*. These conventions are kept from Hyper-V code as another tactic to simplify the process of importing and maintaining the definitions, rather than splitting them up into their own files in arch/x86/ and arch/arm64/. These headers are a step toward importing headers directly from Hyper-V in the future, similar to Xen public files in include/xen/interface/. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Roman Kisel <romank@linux.microsoft.com> Link: https://lore.kernel.org/r/1732577084-2122-4-git-send-email-nunodasneves@linux.microsoft.com Link: https://lore.kernel.org/r/20250108222138.1623703-2-romank@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2025-01-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.13-rc7). Conflicts: a42d71e322a8 ("net_sched: sch_cake: Add drop reasons") 737d4d91d35b ("sched: sch_cake: add bounds checks to host bulk flow fairness counts") Adjacent changes: drivers/net/ethernet/meta/fbnic/fbnic.h 3a856ab34726 ("eth: fbnic: add IRQ reuse support") 95978931d55f ("eth: fbnic: Revert "eth: fbnic: Add hardware monitoring support via HWMON interface"") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10rust: use host dylib naming convention to support macOSTamir Duberstein
Because the `macros` crate exposes procedural macros, it must be compiled as a dynamic library (so it can be loaded by the compiler at compile-time). Before this change the resulting artifact was always named `libmacros.so`, which works on hosts where this matches the naming convention for dynamic libraries. However the proper name on macOS would be `libmacros.dylib`. This turns out to matter even when the dependency is passed with a path (`--extern macros=path/to/libmacros.so` rather than `--extern macros`) because rustc uses the file name to infer the type of the library (see link). This is because there's no way to specify both the path to and the type of the external library via CLI flags. The compiler could speculatively parse the file to determine its type, but it does not do so today. This means that libraries that match neither rustc's naming convention for static libraries nor the platform's naming convention for dynamic libraries are *rejected*. The only solution I've found is to follow the host platform's naming convention. This patch does that by querying the compiler to determine the appropriate name for the artifact. This allows the kernel to build with CONFIG_RUST=y on macOS. Link: https://github.com/rust-lang/rust/blob/d829780/compiler/rustc_metadata/src/locator.rs#L728-L752 Tested-by: Daniel Gomez <da.gomez@samsung.com> Co-developed-by: Fiona Behrens <me@kloenk.dev> Signed-off-by: Fiona Behrens <me@kloenk.dev> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241216-b4-dylib-host-macos-v7-1-cfc507681447@gmail.com [ Added `MAKEFLAGS=`s to avoid jobserver warnings. Removed space. Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10tracing/kprobes: Simplify __trace_kprobe_create() by removing gotosMasami Hiramatsu (Google)
Simplify __trace_kprobe_create() by removing gotos. Link: https://lore.kernel.org/all/173643301102.1514810.6149004416601259466.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-01-10tracing: Use __free() for kprobe events to cleanupMasami Hiramatsu (Google)
Use __free() in trace_kprobe.c to cleanup code. Link: https://lore.kernel.org/all/173643299989.1514810.2924926552980462072.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-01-10tracing: Use __free() in trace_probe for cleanupMasami Hiramatsu (Google)
Use __free() in trace_probe to cleanup some gotos. Link: https://lore.kernel.org/all/173643298860.1514810.7267350121047606213.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-01-10kprobes: Remove remaining gotosMasami Hiramatsu (Google)
Remove remaining gotos from kprobes.c to clean up the code. This does not use cleanup macros, but changes code flow for avoiding gotos. Link: https://lore.kernel.org/all/173371212474.480397.5684523564137819115.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10kprobes: Remove unneeded gotoMasami Hiramatsu (Google)
Remove unneeded gotos. Since the labels referred by these gotos have only one reference for each, we can replace those gotos with the referred code. Link: https://lore.kernel.org/all/173371211203.480397.13988907319659165160.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10kprobes: Use guard for rcu_read_lockMasami Hiramatsu (Google)
Use guard(rcu) for rcu_read_lock so that it can remove unneeded gotos and make it more structured. Link: https://lore.kernel.org/all/173371209846.480397.3852648910271029695.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10kprobes: Use guard() for external locksMasami Hiramatsu (Google)
Use guard() for text_mutex, cpu_read_lock, and jump_label_lock in the kprobes. Link: https://lore.kernel.org/all/173371208663.480397.7535769878667655223.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10jump_label: Define guard() for jump_label_lockMasami Hiramatsu (Google)
Link: https://lore.kernel.org/all/173371207108.480397.12818384744149153972.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10tracing/eprobe: Adopt guard() and scoped_guard()Masami Hiramatsu (Google)
Use guard() or scoped_guard() in eprobe events for critical sections rather than discrete lock/unlock pairs. Link: https://lore.kernel.org/all/173289890996.73724.17421347964110362029.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10tracing/uprobe: Adopt guard() and scoped_guard()Masami Hiramatsu (Google)
Use guard() or scoped_guard() in uprobe events for critical sections rather than discrete lock/unlock pairs. Link: https://lore.kernel.org/all/173289889911.73724.12457932738419630525.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10tracing/kprobe: Adopt guard() and scoped_guard()Masami Hiramatsu (Google)
Use guard() or scoped_guard() in kprobe events for critical sections rather than discrete lock/unlock pairs. Link: https://lore.kernel.org/all/173289888883.73724.6586200652276577583.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10kprobes: Adopt guard() and scoped_guard()Masami Hiramatsu (Google)
Use guard() or scoped_guard() for critical sections rather than discrete lock/unlock pairs. Link: https://lore.kernel.org/all/173289887835.73724.608223217359025939.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10kprobes: Reduce preempt disable scope in check_kprobe_access_safe()Thomas Weißschuh
Commit a189d0350f387 ("kprobes: disable preempt for module_text_address() and kernel_text_address()") introduced a preempt_disable() region to protect against concurrent module unloading. However this region also includes the call to jump_label_text_reserved() which takes a long time; up to 400us, iterating over approx 6000 jump tables. The scope protected by preempt_disable() is largen than necessary. core_kernel_text() does not need to be protected as it does not interact with module code at all. Only the scope from __module_text_address() to try_module_get() needs to be protected. By limiting the critical section to __module_text_address() and try_module_get() the function responsible for the latency spike remains preemptible. This works fine even when !CONFIG_MODULES as in that case try_module_get() will always return true and that block can be optimized away. Limit the critical section to __module_text_address() and try_module_get(). Use guard(preempt)() for easier error handling. While at it also remove a spurious *probed_mod = NULL in an error path. On errors the output parameter is never inspected by the caller. Some error paths were clearing the parameters, some didn't. Align them for clarity. Link: https://lore.kernel.org/all/20241121-kprobes-preempt-v1-1-fd581ee7fcbb@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-01-10tracing/kprobes: Fix to free objects when failed to copy a symbolMasami Hiramatsu (Google)
In __trace_kprobe_create(), if something fails it must goto error block to free objects. But when strdup() a symbol, it returns without that. Fix it to goto the error block to free objects correctly. Link: https://lore.kernel.org/all/173643297743.1514810.2408159540454241947.stgit@devnote2/ Fixes: 6212dd29683e ("tracing/kprobes: Use dyn_event framework for kprobe events") Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-01-09hwmon: (dell-smm) Add Dell XPS 9370 to fan control whitelistPovilas Kanapickas
Add the Dell XPS 9370 to the fan control whitelist to allow for manual fan control. Signed-off-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/6e6b7a47-d0e3-4c5a-8be2-dfc58852da8e@radix.lt Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-01-10arm64: defconfig: Enable Rockchip extensions for Synopsys DW HDMI QPCristian Ciocaltea
Enable Rockchip specific extensions for Synopsys DesignWare HDMI Quad-Pixel (QP) driver. This is needed to provide HDMI output support for the boards based on RK3588 SoC. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20241202-dw-hdmi-qp-rk-defconfig-v1-1-38757fc053d0@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-10arm64: defconfig: Enable RFKILL GPIONicolas Dufresne
Enable as a module the RFKILL GPIO driver. This is needed to power WiFi and Bluetooth radio on various RK3588 board. Without this module, rfkill will report the switch has hard blocked, which prevents using the WiFi or Bluetooth feature. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Link: https://lore.kernel.org/r/20241218-rk3588-rfkill-gpio-config-v1-1-dfdf464f97d4@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-10rust: add `build_error!` to the preludeMiguel Ojeda
The sibling `build_assert!` is already in the prelude, it makes sense that a "core"/"language" facility like this is part of the prelude and users should not be defining their own one (thus there should be no risk of future name collisions and we would want to be aware of them anyway). Thus add `build_error!` into the prelude. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123222849.350287-3-ojeda@kernel.org [ Applied the change to the new miscdevice cases. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10rust: kernel: move `build_error` hidden function to prevent mistakesMiguel Ojeda
Users were using the hidden exported `kernel::build_error` function instead of the intended `kernel::build_error!` macro, e.g. see the previous commit. To force to use the macro, move it into the `build_assert` module, thus making it a compilation error and avoiding a collision in the same "namespace". Using the function now would require typing the module name (which is hidden), not just a single character. Now attempting to use the function will trigger this error with the right suggestion by the compiler: error[E0423]: expected function, found macro `kernel::build_error` --> samples/rust/rust_minimal.rs:29:9 | 29 | kernel::build_error(); | ^^^^^^^^^^^^^^^^^^^ not a function | help: use `!` to invoke the macro | 29 | kernel::build_error!(); | + An alternative would be using an alias, but it would be more complex and moving it into the module seems right since it belongs there and reduces the amount of code at the crate root. Keep the `#[doc(hidden)]` inside `build_assert` in case the module is not hidden in the future. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123222849.350287-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10rust: use the `build_error!` macro, not the hidden functionMiguel Ojeda
Code and some examples were using the function, rather than the macro. The macro is what is documented. Thus move users to the macro. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123222849.350287-1-ojeda@kernel.org [ Applied the change to the new miscdevice cases. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10rust: kbuild: run Clippy for `rusttest` codeMiguel Ojeda
Running Clippy for `rusttest` code is useful to catch issues there too, even if the code is not as critical. In the future, this code may also run in kernelspace and could be copy-pasted. Thus it is useful to keep it under the same standards. For instance, it will now make us add `// SAFETY` comments. It also makes everything more consistent. Thus clean the few issues spotted by Clippy and start running it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123180639.260191-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10rust: give Clippy the minimum supported Rust versionMiguel Ojeda
Clippy's lints may avoid emitting a suggestion to use a language or library feature that is not supported by the minimum supported version, if given by the `msrv` field in the configuration file. For instance, Clippy should not suggest using `let ... else` in a lint if the MSRV did not implement that syntax. If the MSRV is not provided, Clippy will assume all features are available. Thus enable it with the minimum Rust version the kernel supports. Note that there is currently a small disadvantage in doing so: since we still use unstable features that nevertheless work in the range of versions we support (e.g. `#[expect(...)]`), we lose suggestions for those. However, over time we will stop using unstable features (especially language and library ones) as it is our goal, thus, in the end, we will want to have the `msrv` set. Rust is also considering adding a similar feature in `rustc` too, which we should probably enable if it becomes available [2]. Link: https://github.com/rust-lang/rust-clippy/blob/8298da72e7b81fa30c515631b40fc4c0845948cb/clippy_utils/src/msrvs.rs#L20 [1] Link: https://github.com/rust-lang/compiler-team/issues/772 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123222345.346976-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-10rust: document `bindgen` 0.71.0 regressionMiguel Ojeda
`bindgen` 0.71.0 regressed [1] on the "`--version` requires header" issue which appeared in 0.69.0 first [2] and was fixed in 0.69.1. It has been fixed again in 0.71.1 [3]. Thus document it so that, when we upgrade the minimum past 0.69.0 in the future, we do not forget that we cannot remove the workaround until we arrive at 0.71.1 at least. Link: https://github.com/rust-lang/rust-bindgen/issues/3039 [1] Link: https://github.com/rust-lang/rust-bindgen/issues/2677 [2] Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#v0711-2024-12-09 [3] Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241209212544.1977065-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-09arm64: dts: qcom: x1e80100-romulus: Update firmware nodesJoel Stanley
Other x1e machines use _dtbs.elf for these firmwares, which matches the filenames shipped by Windows. Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250108124500.44011-1-joel@jms.id.au Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-10arm64: dts: rockchip: add DTs for Firefly ITX-3588J and its Core-3588J SoMShimrra Shai
Add the device tree and Makefile update. Signed-off-by: Shimrra Shai <shimrrashai@gmail.com> Link: https://lore.kernel.org/r/20241216214152.58387-3-shimrrashai@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-10dt-bindings: arm: rockchip: Add Firefly ITX-3588J boardShimrra Shai
Document board compatible bindings. Signed-off-by: Shimrra Shai <shimrrashai@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241216214152.58387-2-shimrrashai@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09dt-bindings: opp: h6: Add A100 operating pointsCody Eksal
The A100, similar to the H6 and H616, use an NVMEM value to determine speed binnings. The method used is similar to that of the H6. However, the information is stored at a slightly different bit offset. Add a new compatible for the A100. Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20241031070232.1793078-12-masterr3c0rd@epochal.quest Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-09arm64: dts: rockchip: Add Orange Pi 5 Max boardJimmy Hon
The RK3588 Single Board Computer includes - eMMC - microSD - UART - 2 PWM LEDs - RTC - RTL8125 network controller on PCIe 2.0x1. - M.2 M-key connector routed to PCIe 3.0x4 - PWM controlled heat sink fan. - 2 USB2 ports - lower USB3 port - upper USB3 port with OTG capability - Mali GPU - SPI NOR flash - Mask Rom button - Analog audio using es8388 codec via the headset jack and onboard mic - HDMI0 - HDMI1 the vcc5v0_usb30 regulator shares the same enable gpio pin as the vcc5v0_usb20 regulator. The Orange Pi 5 Max and Orange Pi 5 Ultra are both credit-card sized boards with similar layout, so these boards will share a common dtsi. The 5 Max has an extra HDMI0 while the 5 Ultra has a HDMI IN instead. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250109051619.1825-4-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09dt-bindings: arm: rockchip: Add Xunlong Orange Pi 5 MaxJimmy Hon
Add devicetree binding for the Xunlong Orange Pi 5 Max board. The Orange Pi 5 Max is a single board computer powered by the Rockchip RK3588 similar to the Orange Pi 5 Plus. Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250109051619.1825-3-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09arm64: dts: rockchip: refactor common rk3588-orangepi-5.dtsiJimmy Hon
Orange Pi now has multiple SBCs using the RK3588. Refactor the common parts of the Orange Pi 5 Plus DTS so it can be shared with the 5 Max and the 5 Ultra. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250109051619.1825-2-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-10Merge tag 'drm-intel-next-2025-01-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: - Some DG2 refactor to fix DG2 bugs when operating with certain CPUs (Raag) - Use hw support for min/interim ddb allocation for async flip (Vinod) - More general code refactor to allow full display separation (Jani) - Expose dsc sink max slice count via debugfs (Swati) - Fix C10 pll programming sequence (Suraj) - Fix DG1 power gate sequence (Rodrigo) - Use preemption timeout on selftest cleanup (Janusz) - DP DSC related fixes (Ankit) - Fix HDCP compliance test (Suraj) - Clean and Optimise mtl_ddi_prepare_link_retrain (Suraj) - Adjust Added Wake Time with PKG_C_LATENCY (Animesh) - Enabling uncompressed 128b/132b UHBR SST (Jani) - Handle hdmi connector init failures, and no HDMI/DP cases (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z31_WPbBoHkwgEA9@intel.com
2025-01-09firewall: remove misplaced semicolon from stm32_firewall_get_firewallguanjing
Remove misplaced colon in stm32_firewall_get_firewall() which results in a syntax error when the code is compiled without CONFIG_STM32_FIREWALL. Fixes: 5c9668cfc6d7 ("firewall: introduce stm32_firewall framework") Signed-off-by: guanjing <guanjing@cmss.chinamobile.com> Reviewed-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-09Merge tag 'imx-fixes-6.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.13: - Add fallback for i.MX8QM ESAI compatible to fix a dt-schema warning caused by bindings update - Fix uSDHC1 clock for i.MX RT1050 - Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to fix a regression caused by an i.MX6 SPDIF sound card change in DT - Fix address length of i.MX95 netcmix_blk_ctrl * tag 'imx-fixes-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imxrt1050: Fix clocks for mmc ARM: imx_v6_v7_defconfig: enable SND_SOC_SPDIF arm64: dts: imx95: correct the address length of netcmix_blk_ctrl arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai Link: https://lore.kernel.org/r/Z3Jf9zbv/xH3YzuB@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-09Merge tag 'qcom-arm64-fixes-for-6.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm Arm64 DeviceTree fixes for v6.13 Revert the enablement of OTG support on primary and secondary USB Type-C controllers of X1 Elite, for now, as this broke support for USB hotplug. Disable the TPDM DCC device on SA8775P, as this is inaccessible per current firmware configuration. Also correct the PCIe "addr_space" region to enable larger BAR sizes. Also fix the address space of PCIe6a found in X1 Elite. * tag 'qcom-arm64-fixes-for-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: sa8775p: fix the secure device bootup issue Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers" Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports" arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports" arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions Link: https://lore.kernel.org/r/20250103024945.4649-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-09drm/amdgpu: fill the ucode bo during psp resume for SRIOVVictor Zhao
refill the ucode bo during psp resume for SRIOV, otherwise ucode load will fail after VM hibernation and fb clean. Signed-off-by: Victor Zhao <Victor.Zhao@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/gfx10: Enable cleaner shader for GFX10.3.2/10.3.4/10.3.5 GPUsSrinivasan Shanmugam
Enable the cleaner shader for GFX10.3.2/10.3.4/10.3.5 GPUs to provide data isolation between GPU workloads. The cleaner shader is responsible for clearing the Local Data Store (LDS), Vector General Purpose Registers (VGPRs), and Scalar General Purpose Registers (SGPRs), which helps prevent data leakage and ensures accurate computation results. This update extends cleaner shader support to GFX10.3.2/10.3.4/10.3.5 GPUs, previously available for GFX10.3.0. It enhances security by clearing GPU memory between processes and maintains a consistent GPU state across KGD and KFD workloads. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: fix gpu recovery disable with per queue resetJonathan Kim
Per queue reset should be bypassed when gpu recovery is disabled with module parameter. Fixes: ee0a469cf917 ("drm/amdkfd: support per-queue reset on gfx9") Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: wrong array index to get ip block for PSPJiang Liu
The adev->ip_blocks array is not indexed by AMD_IP_BLOCK_TYPE_xxx, instead we should call amdgpu_device_ip_get_ip_block() to get the corresponding IP block oject. Fix some checkpatch issues (Alex) Signed-off-by: Jiang Liu <gerry@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: tear down ttm range manager for doorbell in amdgpu_ttm_fini()Jiang Liu
Tear down ttm range manager for doorbell in function amdgpu_ttm_fini(), to avoid memory leakage. Fixes: 792b84fb9038 ("drm/amdgpu: initialize ttm for doorbells") Signed-off-by: Jiang Liu <gerry@linux.alibaba.com> Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: fix incorrect number of active RBs for gfx12Tim Huang
The RB bitmap should be global active RB bitmap & active RB bitmap based on active SA. Signed-off-by: Tim Huang <tim.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: fix incorrect active RB bitmap in setup RBsTim Huang
The RB bitmap width per SA may be 0x1 for some ASICs. Use the actual bitmap of SA instead of 0x3 to determine the active RB bitmap. Signed-off-by: Tim Huang <tim.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdkfd: Move gfx12 trap handler to separate fileJay Cornwall
gfx12 derivatives will have substantially different trap handler implementations from gfx10/gfx11. Add a separate source file for gfx12+ and remove unneeded conditional code. No functional change. v2: Revert copyright date to 2018, minor comment fixes Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Lancelot Six <lancelot.six@amd.com> Cc: Jonathan Kim <jonathan.kim@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: Fix shift type in amdgpu_debugfs_sdma_sched_mask_set()Dan Carpenter
The "mask" and "val" variables are type u64. The problem is that the BIT() macros are type unsigned long which is just 32 bits on 32bit systems. It's unlikely that people will be using this driver on 32bit kernels and even if they did we only use the lower AMDGPU_MAX_SDMA_INSTANCES (16) bits. So this bug does not affect anything in real life. Still, for correctness sake, u64 bit masks should use BIT_ULL(). Fixes: d2e3961ae371 ("drm/amdgpu: add amdgpu_sdma_sched_mask debugfs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/d39a9325-87a4-4543-b6ec-1c61fca3a6fc@stanley.mountain Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu: enable gfx12 queue reset flagJesse Zhang
Enable the kgq and kcq queue reset flag Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amd/display: Increase sanitizer frame larger than limit when compile ↵Nathan Chancellor
testing with clang Commit 24909d9ec7c3 ("drm/amd/display: Overwriting dualDPP UBF values before usage") added a new warning in dml2/display_mode_core.c when building allmodconfig with clang: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6268:13: error: stack frame size (3128) exceeds limit (3072) in 'dml_prefetch_check' [-Werror,-Wframe-larger-than] 6268 | static void dml_prefetch_check(struct display_mode_lib_st *mode_lib) | ^ Commit be4e3509314a ("drm/amd/display: DML21 Reintegration For Various Fixes") introduced one in dml2_core/dml2_core_dcn4_calcs.c with the same configuration: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:7236:13: error: stack frame size (3256) exceeds limit (3072) in 'dml_core_mode_support' [-Werror,-Wframe-larger-than] 7236 | static bool dml_core_mode_support(struct dml2_core_calcs_mode_support_ex *in_out_params) | ^ In the case of the first warning, the stack usage was already at the limit at the parent change, so the offending change was rather innocuous. In the case of the second warning, there was a rather dramatic increase in stack usage compared to the parent: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:7032:13: error: stack frame size (2696) exceeds limit (2048) in 'dml_core_mode_support' [-Werror,-Wframe-larger-than] 7032 | static bool dml_core_mode_support(struct dml2_core_calcs_mode_support_ex *in_out_params) | ^ This is an unfortunate interaction between an issue with stack slot reuse in LLVM that gets exacerbated by sanitization (which gets enabled with all{mod,yes}config) and function calls using a much higher number of parameters than is typical in the kernel, necessitating passing most of these values on the stack. While it is possible that there should be source code changes to address these warnings, this code is difficult to modify for various reasons, as has been noted in other changes that have occurred for similar reasons, such as commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml2"). Increase the frame larger than limit when compile testing with clang and the sanitizers enabled to avoid this breakage in all{mod,yes}config, as they are commonly used and valuable testing targets. While it is not the best to hide this issue, it is not really relevant when compile testing, as the sanitizers are commonly stressful on optimizations and they are only truly useful at runtime, which COMPILE_TEST states will not occur with the current build. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412121748.chuX4sap-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/pm: Implement SDMA queue reset for different asicJesse Zhang
Implement sdma queue reset by SMU_MSG_ResetSDMA2 Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Suggested-by: Tim Huang <tim.huang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-01-09drm/amdgpu/pm: add definition PPSMC_MSG_ResetSDMA2Jesse Zhang
add the PPSMC_MSG_ResetSDMA2 definition for smu 13.0.6 Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Reviewed-by: Tim Huang <tim.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-10-03 01:49:28 +0000