Current code gets the APIC IDs for CPUs numbered 255 and lower.
This code assumes cpu_possible_mask is dense, which is not true in
the general case per [1]. If cpu_possible_mask contains holes,
num_possible_cpus() is less than nr_cpu_ids, so some CPUs might get
skipped. Furthermore, getting the APIC ID of a CPU that isn't in
cpu_possible_mask is invalid.
However, the configurations that Hyper-V provides to guest VMs on x86
hardware, in combination with how x86 code assigns Linux CPU numbers,
*does* always produce a dense cpu_possible_mask. So the dense assumption
is not currently causing failures. But for robustness against future
changes in how cpu_possible_mask is populated, update the code to no
longer assume dense.
The correct approach is to determine the range to scan based on
nr_cpu_ids, and skip any CPUs that are not in the cpu_possible_mask.
[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20241003035333.49261-4-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241003035333.49261-4-mhklinux@outlook.com>
Current code allocates the hv_vp_index array with size
num_possible_cpus(). This code assumes cpu_possible_mask is dense,
which is not true in the general case per [1]. If cpu_possible_mask
is sparse, the array might be indexed by a value beyond the size of
the array.
However, the configurations that Hyper-V provides to guest VMs on x86
and ARM64 hardware, in combination with how architecture specific code
assigns Linux CPU numbers, *does* always produce a dense cpu_possible_mask.
So the dense assumption is not currently causing failures. But for
robustness against future changes in how cpu_possible_mask is populated,
update the code to no longer assume dense.
The correct approach is to allocate and initialize the array using size
"nr_cpu_ids". While this leaves unused array entries corresponding to
holes in cpu_possible_mask, the holes are assumed to be minimal and hence
the amount of memory wasted by unused entries is minimal.
Using nr_cpu_ids also reduces initialization time, in that the loop to
initialize the array currently rescans cpu_possible_mask on each
iteration. This is n-squared in the number of CPUs, which could be
significant for large CPU counts.
[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20241003035333.49261-3-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241003035333.49261-3-mhklinux@outlook.com>
Current code allocates the hv_vp_assist_page array with size
num_possible_cpus(). This code assumes cpu_possible_mask is dense,
which is not true in the general case per [1]. If cpu_possible_mask
is sparse, the array might be indexed by a value beyond the size of
the array.
However, the configurations that Hyper-V provides to guest VMs on x86
hardware, in combination with how x86 code assigns Linux CPU numbers,
*does* always produce a dense cpu_possible_mask. So the dense assumption
is not currently causing failures. But for robustness against future
changes in how cpu_possible_mask is populated, update the code to no
longer assume dense.
The correct approach is to allocate the array with size "nr_cpu_ids".
While this leaves unused array entries corresponding to holes in
cpu_possible_mask, the holes are assumed to be minimal and hence the
amount of memory wasted by unused entries is minimal.
[1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20241003035333.49261-2-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241003035333.49261-2-mhklinux@outlook.com>
Remove all hyperv-tlfs.h files. These are no longer included
anywhere. hyperv/hvhdk.h serves the same role, but with an easier
path for adding new definitions.
Remove the relevant lines in MAINTAINERS.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Link: https://lore.kernel.org/r/1732577084-2122-6-git-send-email-nunodasneves@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1732577084-2122-6-git-send-email-nunodasneves@linux.microsoft.com>
Switch to using hvhdk.h everywhere in the kernel. This header
includes all the new Hyper-V headers in include/hyperv, which form a
superset of the definitions found in hyperv-tlfs.h.
This makes it easier to add new Hyper-V interfaces without being
restricted to those in the TLFS doc (reflected in hyperv-tlfs.h).
To be more consistent with the original Hyper-V code, the names of
some definitions are changed slightly. Update those where needed.
Update comments in mshyperv.h files to point to include/hyperv for
adding new definitions.
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Link: https://lore.kernel.org/r/1732577084-2122-5-git-send-email-nunodasneves@linux.microsoft.com
Link: https://lore.kernel.org/r/20250108222138.1623703-3-romank@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
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>
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: 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>
Commit a189d0350f ("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>
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: 6212dd2968 ("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>
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>
The code that changes hdmi->ref_clk was accidentally copied from
downstream code that sets a different clock. We don't actually
want to set any clock here at all.
Setting this clock incorrectly leads to incorrect timings for
DDC, CEC, and HDCP signal generation.
No Fixes listed, as the theoretical timing error in DDC appears to
still be within tolerances and harmless - and HDCP and CEC are not
yet supported.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217201708.3320673-1-derek.foreman@collabora.com
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>
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>
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>
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>
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>
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>
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: 8298da72e7/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>
Other x1e machines use _dtbs.elf for these firmwares, which matches the
filenames shipped by Windows.
Fixes: 09d77be560 ("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>
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>
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>
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>
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>
- 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)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmd9flgACgkQ+mJfZA7r
E8qSKAf9FoiRZD5dJVQ60wNEszj3Ub647+32sl2jA7jb5twoUve3ZreJvTCKUMfd
jtd+FIJtB9JLX9LwK9v8TBkkq20kAKFKvXNwLPLBsMIuQJ+1C3tkvQ6PugY/zzg0
6UGcgehlhf20lTtzqclYipophRCTl26nu7y2PkanPxRzfO62p7ygfcM38ZgqkrfK
b+GFXTB951k4aVsfNFmqbZrdpaY2E7Ybhx208cU6SfMhYvZYE6SpRc3f8zuj/w3P
ub3NFepdwg+Q2bVZuSwxX0OuWmoq06cAaAbODKzwNgjFaLxq3jXOVnZZnm7G8TVn
W85BC8RTlIStcd09Jp+tassKU+cMNA==
=r7tD
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2025-01-07' of 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
Remove misplaced colon in stm32_firewall_get_firewall()
which results in a syntax error when the code is compiled
without CONFIG_STM32_FIREWALL.
Fixes: 5c9668cfc6 ("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>
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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmd3UBEVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FYPMP/RAdO4vAnJ034xLLOp0R/hpAFVew
/WOZf4WgHwjmC89VEp95zabxMB3oWn6Wdk7mKN/+NTcKHs7cMLQ/d8aVX67mlomG
i0q757Wzgm2GSioHbeKQ9me/rNOCRgpx8ZUZEjC64FraE/1s8Be2zTLqyX2xfUoz
PMpPEUlI51IPk6vUv/aU4U1uqqTZBQINIZ7hmMei8B0FwVs9cDx/uUsGccz2AgWA
i776PHKmBg8EhaJJxaXKuXl84qH7B3XrlzOTWmx2eLIUVAiId3kscsCxkJLxHlPp
jWiN0TBB8sRa7q8wDVfjKOg0rBjtpTFVrdcVGTU7/Ub8aHI3YGpD4LnqBx91YqXF
wa7ZhdTVdsroCSJvLG0c2cgmRm6ZfaPpOtw4x2KgrZkhPGpVInftEmHVm5uSSwhx
M+D2RoGESj1mQhcJ72Kuqmrd1C8UQtF4JkDAY+5vOHf+ixt0QjAtd6URh0n9WlEl
GYZvVSzHqv+fwpzkRJljiNrVK3c6/1TtEWIdm+c/jeSo02D2m/AAHJwb/nSlI875
6aOKFeVGf1IT2k5cu4cMhtpJpnkwNKz1uJfc8O5gOjYTGvLzFKFYv0nekfvCMbOS
fPheUn4RAtCohSkAUB8OVFkF04iH2J/o6npiM1GPbaC61rrL/3ylhVRqzIw5Hmkz
G8XTFXyiABPXFls2
=MuLc
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeARa0ACgkQYKtH/8kJ
UieF2g//WDchFn0Wk4WjeQh93kDP7JIlkmEXmCq+hfVF6fX+4ONRRhJTtH2Eacrf
mhmf+tkbc9Yy3xLuvcoZafhhq2pXvtUYa/iR86XB0oYXhYuvbcE0cICNGod8V92G
ZHEj5KBnU/U3vyD8d3iy5aliy44bqH9Powl63YfD8XdAbLXh8CrXeILsIZsV04WU
8fWz0/NYyst3Jtjc/HEK7CrZi4jO4mU4AncnSZn6qh7R9FPK8i5NyEpak0+ZnOcl
FIJM0EfGJbESLxCOHUkkrcBiKTzBAKh8ej1xiYpfBoNOF7DtS7XlF0pXPFuyrguW
MjKJl5JXppLRSEurv76iHFwUAVgtwVJ3o0dcaPCfiErcO+68JWm0+J4v5irAzBG/
s6FSePdZZI/p1ghQPs8ZAe1H9BB5jK5KNfrsE3vgKhwFf7in5/afgdestg+YYnJc
fRSwU8FkrZ7pQ0QXPyjr4CRjCugnuBnIU+v5Ad9BRY26BGSnyQwVbO6K/4b6MH/p
n1dSyl+2DvpAFBA+/9ZkRbfF/xBN97TvF0RN+mPwNB5v1OhNhi83lnk96EQ+WSJp
QuSN0GmTQuzxg4yiA+VZDrUncJaGVdwBAuO2tQgpc+LXXon2n/dMiDDirhEgj8e3
/oQSPyg63CB+nfgWuvu/Kc4mJTbXuhsTBQ/2dP2RTyiQ09TbZQY=
=rNWN
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.13' of 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>
I won't be able to use intel account, so this switches address to my
gmail account.
Cc: Zhi Wang <zhi.wang.linux@gmail.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Cc: James Wu <james.y.wu@intel.com>
Cc: Zhenyu Wang <zhenyuw.linux@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Zhi Wang <zhiwang@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241113063700.4460-1-zhenyuw@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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>
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>
Per queue reset should be bypassed when gpu recovery is disabled
with module parameter.
Fixes: ee0a469cf9 ("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>
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>
Tear down ttm range manager for doorbell in function amdgpu_ttm_fini(),
to avoid memory leakage.
Fixes: 792b84fb90 ("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>
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>
