| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The copy-key is not present on all device variants, so move it to
the individual boards that have this key.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260104191448.2693309-4-heiko@sntech.de
|
|
The common used SATA controller on all TSx33 devices is actually SATA2.
So move the SATA controller + combophy enablement to their correct
position between shared dtsi and board devicetrees.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260104191448.2693309-3-heiko@sntech.de
|
|
The TS133 while mostly similar, is based around the RK3566 variant, so
needs a different SoC include.
By moving the SoC include to the board devicetrees, we can still keep
the shared common setup, while supporting the different base SoCs.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260104191448.2693309-2-heiko@sntech.de
|
|
In order to prepare having multiple pv_ops arrays, specify the array in the
paravirt macros.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105110520.21356-21-jgross@suse.com
|
|
For consistency with __vdso_clock_gettime64() there should also be a
64-bit variant of clock_getres(). This will allow the extension of
CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit
time types from the kernel and UAPI.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-9-97ea7a06a543@linutronix.de
|
|
For consistency with __vdso_clock_gettime64() there should also be a
64-bit variant of clock_getres(). This will allow the extension of
CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit
time types from the kernel and UAPI.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-8-97ea7a06a543@linutronix.de
|
|
For consistency with __vdso_clock_gettime64() there should also be a
64-bit variant of clock_getres(). This will allow the extension of
CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit
time types from the kernel and UAPI.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-7-97ea7a06a543@linutronix.de
|
|
The vDSO code hides symbols which are non-functional.
__vdso_clock_getres() was not added to this list when it got introduced.
Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de
|
|
For consistency with __vdso_clock_gettime64() there should also be a
64-bit variant of clock_getres(). This will allow the extension of
CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit
time types from the kernel and UAPI.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-5-97ea7a06a543@linutronix.de
|
|
In order to prepare for defining paravirt functions outside of paravirt.h,
don't #undef the paravirt call macros.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105110520.21356-20-jgross@suse.com
|
|
Stop definining these privately and instead move them to the uapi
errno.h so that they become canonical instead of copy pasta.
Cc: linux-api@vger.kernel.org
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Link: https://patch.msgid.link/176826402587.3490369.17659117524205214600.stgit@frogsfrogsfrogs
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
Move the assignment of the CPU clocks and the CPU OPP table(s) from
board.dts to SoC.dtsi to reduce the code duplication.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260109210217.828961-1-martin.blumenstingl@googlemail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Janne Grunau <j@jannau.net> says:
Now that all dependencies for USB 2.0 and 3.x support are either merged
(tipd changes in v6.18, dwc3-apple in v6.19-rc1) or in linux-next (Apple
Type-C PHY) prepare device tree changes to expose the ports.
Each port on Apple silicon devices is driven by a separate collection of
hardware blocks. For USB 2.0 and 3.x the collection consists of:
- Apple Type-C PHY, combo PHY for USB 2.0, USB 3.x, USB4/Thunderbolt and
DisplayPort
- Synopsys Designware dwc3 USB controller
- two DART iommu instances for dwc3
- CD321x USB PD controller (similar to Ti's TPS6598x series)
The CD321x nodes are already present so this series add the remaining
devices nodes, typec connector nodes and connections between all
components.
The devices expose except for a few exceptions noted below all ports. M1
and M2 have two ports, M1 and M2 Pro and Max have four ports and
M1 and M2 Ultra have eight ports.
The Pro and Max based Macbook Pros use only three ports. The fourth port
is used as DisplayPort PHY to drive a HDMI output via an integrated
DP to HDMI converter.
The Ultra based Mac studio devices only use six ports. The third and
fourth port on the second die is completely fused off.
The changes for t600x and t602x are in a single commit since the devices
share .dtsi files across SoC generations due to their similarity.
Depends on commit c1538b87caef ("dt-bindings: phy: Add Apple Type-C
PHY") in linux-phy's [1] next branch for `make dtbs_check` to pass.
checkpatch warns about the undocumented DT compatible strings
"apple,t8112-atcphy", "apple,t6000-atcphy" and "apple,t6020-atcphy" but
not about "apple,t8103-atcphy". I don't under why it doesn't warn about
the last. "apple,t8103-atcphy" is only found in the added devicetree
files and nowhere else in v6.19-rc1.
Tested on top of next-20260106 on M1, M2, M1 Max and M2 Pro Mac mini /
Mac studio and a few fixes for dwc3-apple and atc [2, 3, 4, 5].
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-0-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated Type-C ports of M1 and M2 Pro, Max and Ultra based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
M1 and M2 Max based Mac Studio device have two additional USB Type-C
ports on the front which are driven by an AsMedia PCIe USB controller
and integrated USB hub. These ports are not covered by this change.
The port labels use Apple's established naming scheme for the ports.
Co-developed-by: R <rqou@berkeley.edu>
Signed-off-by: R <rqou@berkeley.edu>
Co-developed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-3-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated USBi Type-C ports of M2-based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
The port labels use Apple's established naming scheme for the ports.
Signed-off-by: Hector Martin <marcan@marcan.st>
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-2-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add device nodes and connections to support USB 3.x on the SoC's
integrated USB-C ports of M1-based devices.
Each Type-C port has an Apple Type-C PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort, a Synopsys Designware USB 3.x
controller, two DART iommu instances and a CD321x USB PD controller.
The iMac variant with four USB-C ports has two SoC integrated USB-C
ports and two additional USB-C ports driven by an AsMedia PCIe USB
controller. The latter ports are not covered by this change.
The port labels use Apple's established naming scheme for the ports.
Signed-off-by: Hector Martin <marcan@marcan.st>
Co-developed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Janne Grunau <j@jannau.net>
Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air
Reviewed-by: Sven Peter <sven@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://patch.msgid.link/20260109-apple-dt-usb-c-atc-dwc3-v1-1-ce0e92c1a016@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
AGX appears to have a hidden communication channel to pmp, a power
management related co-processor already brought up by Apple's
bootloader. As there is not driver for this co-processor its
power-domain gets shut down after the initial boot.
This crashes the firmware running on AGX immediately.
Until there is a pmp driver and the dependency between AGX and pmp is
understood keep "ps_pmp" as dependency of "ps_gfx".
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-3-cfdce629c0a8@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Shutting these down breaks dwc3 init done by the firmware. We probably
never want to do this anyway. "always-on" is a plausible interpretation
of the "aon" suffix.
The t8112, t600x and t602x "ps_atc?_usb_aon" power-controller nodes are
have already "apple,always-on" properties.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-2-cfdce629c0a8@jannau.net
[sven: removed stale comment about PHY from commit message]
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Add the display controller and DPTX phy power-domains to the framebuffer
node to keep the framebuffer and display out working after device probing
finished.
The OS has more control about the display pipeline used for the HDMI
output on M2 based devices. The HDMI output is driven by an integrated
DisplayPort to HDMI converter (Parade PS190). The DPTX phy is now
controlled by the OS and no longer by firmware running on the display
co-processor. This allows using the second display controller on the
second USB type-c port or tunneling 2 DisplayPort connections over
USB4/Thunderbolt.
The m1n1 bootloader uses the second display controller to drive the HDMI
output. Adjust for this difference compared to the notebooks as well.
Fixes: 2d5ce3fbef32 ("arm64: dts: apple: t8112: Initial t8112 (M2) device trees")
Cc: stable@vger.kernel.org
Signed-off-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260108-apple-dt-pmgr-fixes-v1-1-cfdce629c0a8@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Apple iMac (M1, 2021) are all-in-one devices with an integrated display.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-4-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
The tower and rack mount Mac Pro variants share the same .dts file and
are identical except for the chassis. There doesn't appear to be a
property in Apple's device tree to distinguish these two devices so use
"server" as chassis type which describes both if one doesn't look too
carefully.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-3-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Apple's Mac mini and Studio are desktop devices. The SMBIOS has chassis
types which might be more accurate like "low profile desktop" or "mini
pc" but without clear definition what those are use plain "desktop" as
chassis-type in the root node.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-2-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
All Macbook Air and Pro devices are laptops so annotate this as
chassis-tpe in the root node.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Link: https://patch.msgid.link/20260109-apple-dt-chassis-type-v1-1-c215503734c5@jannau.net
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
Instead of having a pre-filled array xen_mmu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-18-jgross@suse.com
|
|
Move the aes_encrypt_zvkned() and aes_decrypt_zvkned() assembly
functions into lib/crypto/, wire them up to the AES library API, and
remove the "aes-riscv64-zvkned" crypto_cipher algorithm.
To make this possible, change the prototypes of these functions to
take (rndkeys, key_len) instead of a pointer to crypto_aes_ctx, and
change the RISC-V AES-XTS code to implement tweak encryption using the
AES library instead of directly calling aes_encrypt_zvkned().
The result is that both the AES library and crypto_cipher APIs use
RISC-V's AES instructions, whereas previously only crypto_cipher did
(and it wasn't enabled by default, which this commit fixes as well).
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-15-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Move the POWER8 AES assembly code into lib/crypto/, wire the key
expansion and single-block en/decryption functions up to the AES library
API, and remove the superseded "p8_aes" crypto_cipher algorithm.
The result is that both the AES library and crypto_cipher APIs are now
optimized for POWER8, whereas previously only crypto_cipher was (and
optimizations weren't enabled by default, which this commit fixes too).
Note that many of the functions in the POWER8 assembly code are still
used by the AES mode implementations in arch/powerpc/crypto/. For now,
just export these functions. These exports will go away once the AES
modes are migrated to the library as well. (Trying to split up the
assembly file seemed like much more trouble than it would be worth.)
Another challenge with this code is that the POWER8 assembly code uses a
custom format for the expanded AES key. Since that code is imported
from OpenSSL and is also targeted to POWER8 (rather than POWER9 which
has better data movement and byteswap instructions), that is not easily
changed. For now I've just kept the custom format. To maintain full
correctness, this requires executing some slow fallback code in the case
where the usability of VSX changes between key expansion and use. This
should be tolerable, as this case shouldn't happen in practice.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-14-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Move the PowerPC SPE AES assembly code into lib/crypto/, wire the key
expansion and single-block en/decryption functions up to the AES library
API, and remove the superseded "aes-ppc-spe" crypto_cipher algorithm.
The result is that both the AES library and crypto_cipher APIs are now
optimized with SPE, whereas previously only crypto_cipher was (and
optimizations weren't enabled by default, which this commit fixes too).
Note that many of the functions in the PowerPC SPE assembly code are
still used by the AES mode implementations in arch/powerpc/crypto/. For
now, just export these functions. These exports will go away once the
AES modes are migrated to the library as well. (Trying to split up the
assembly files seemed like much more trouble than it would be worth.)
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-13-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Move the ARM64 optimized AES key expansion and single-block AES
en/decryption code into lib/crypto/, wire it up to the AES library API,
and remove the superseded crypto_cipher algorithms.
The result is that both the AES library and crypto_cipher APIs are now
optimized for ARM64, whereas previously only crypto_cipher was (and the
optimizations weren't enabled by default, which this fixes as well).
Note: to see the diff from arch/arm64/crypto/aes-ce-glue.c to
lib/crypto/arm64/aes.h, view this commit with 'git show -M10'.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-12-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Move the ARM optimized single-block AES en/decryption code into
lib/crypto/, wire it up to the AES library API, and remove the
superseded "aes-arm" crypto_cipher algorithm.
The result is that both the AES library and crypto_cipher APIs are now
optimized for ARM, whereas previously only crypto_cipher was (and the
optimizations weren't enabled by default, which this fixes as well).
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-11-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Now that the AES library's performance has been improved, replace
aes_generic.c with a new file aes.c which wraps the AES library.
In preparation for making the AES library actually utilize the kernel's
existing architecture-optimized AES code including AES instructions, set
the driver name to "aes-lib" instead of "aes-generic". This mirrors
what's been done for the hash algorithms. Update testmgr.c accordingly.
Since this removes the crypto_aes_set_key() helper function, add
temporary replacements for it to arch/arm/crypto/aes-cipher-glue.c and
arch/arm64/crypto/aes-cipher-glue.c. This is temporary, as that code
will be migrated into lib/crypto/ in later commits.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-10-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Remove aes-fixed-time, i.e. CONFIG_CRYPTO_AES_TI. This was a wrapper
around the 256-byte-table-based AES implementation in lib/crypto/aes.c,
with extra code to enable and disable IRQs for constant-time hardening.
While nice in theory, in practice this had the following issues:
- For bulk en/decryption it was 2-4 times slower than aes-generic. This
resulted in aes-generic still being needed, creating fragmentation.
- Having both aes-generic and aes-fixed-time punted an AES
implementation decision to distros and users who are generally
unprepared to handle it. In practice, whether aes-fixed-time gets
used tends to be incidental and not match an explicit distro or user
intent. (While aes-fixed-time has a higher priority than aes-generic,
whether it actually gets enabled, loaded, and used depends on the
kconfig and whether a modprobe of "aes" happens to be done. It also
has a lower priority than aes-arm and aes-arm64.)
- My changes to the generic AES code (in other commits) significantly
close the gap with aes-fixed-time anyway. The table size is reduced
from 8192 bytes to 1024 bytes, and prefetching is added.
- While AES code *should* be constant-time, the real solutions for that
are AES instructions (which most CPUs have now) or bit-slicing. arm
and arm64 already have bit-sliced AES code for many modes; generic
bit-sliced code could be written but would be very slow for single
blocks. Overall, I suggest that trying to write constant-time
table-based AES code is a bit futile anyway, and in the rare cases
where a proper AES implementation is still unavailable it's reasonable
to compromise with an implementation that simply prefetches the table.
Thus, this commit removes aes-fixed-time and CONFIG_CRYPTO_AES_TI. The
replacement is just the existing CONFIG_CRYPTO_AES, which for now maps
to the existing aes-generic code, but I'll soon be changing to use the
improved AES library code instead.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-9-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
The call to sha256() occurs in code that is built when either
CRYPTO_AES_ARM64_CE_BLK or CRYPTO_AES_ARM64_NEON_BLK. The option
CRYPTO_AES_ARM64 is unrelated, notwithstanding its documentation. I'll
be removing CRYPTO_AES_ARM64 soon anyway, but before doing that, fix
where CRYPTO_LIB_SHA256 is selected from.
Fixes: 01834444d972 ("crypto: arm64/aes - use SHA-256 library instead of crypto_shash")
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of crypto_ft_tab and crypto_it_tab from aes_generic.c, use
aes_enc_tab and aes_dec_tab from lib/crypto/aes.c. These contain the
same data in the first 1024 bytes (which is the part that this code
uses), so the result is the same. This will allow aes_generic.c to
eventually be removed.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of crypto_ft_tab and crypto_it_tab from aes_generic.c, use
aes_enc_tab and aes_dec_tab from lib/crypto/aes.c. These contain the
same data in the first 1024 bytes (which is the part that this code
uses), so the result is the same. This will allow aes_generic.c to
eventually be removed.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
aes-neonbs-glue.c calls __aes_arm_encrypt() and __aes_arm_decrypt() to
en/decrypt single blocks for CBC encryption, XTS tweak encryption, and
XTS ciphertext stealing. In preparation for making the AES library use
this same ARM-optimized single-block AES en/decryption code and making
it an internal implementation detail of the AES library, replace the
calls to these functions with calls to the AES library.
Note that this reduces the size of the aesbs_cbc_ctx and aesbs_xts_ctx
structs, since unnecessary decryption round keys are no longer included.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Rename struct aes_key in aesp8-ppc.h and aes-gcm-p10-glue.c to
p8_aes_key and p10_aes_key, respectively. This frees up the name to use
in the library API in <crypto/aes.h>.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Migrate the x86_64 implementations of NH into lib/crypto/. This makes
the nh() function be optimized on x86_64 kernels.
Note: this temporarily makes the adiantum template not utilize the
x86_64 optimized NH code. This is resolved in a later commit that
converts the adiantum template to use nh() instead of "nhpoly1305".
Link: https://lore.kernel.org/r/20251211011846.8179-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Migrate the arm64 NEON implementation of NH into lib/crypto/. This
makes the nh() function be optimized on arm64 kernels.
Note: this temporarily makes the adiantum template not utilize the arm64
optimized NH code. This is resolved in a later commit that converts the
adiantum template to use nh() instead of "nhpoly1305".
Link: https://lore.kernel.org/r/20251211011846.8179-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Migrate the arm32 NEON implementation of NH into lib/crypto/. This
makes the nh() function be optimized on arm32 kernels.
Note: this temporarily makes the adiantum template not utilize the arm32
optimized NH code. This is resolved in a later commit that converts the
adiantum template to use nh() instead of "nhpoly1305".
Link: https://lore.kernel.org/r/20251211011846.8179-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of having a pre-filled array xen_cpu_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-17-jgross@suse.com
|
|
Instead of having a pre-filled array xen_irq_ops for Xen PV paravirt
functions, drop the array and assign each element individually.
This is in preparation of reducing the paravirt include hell by
splitting paravirt.h into multiple more fine grained header files,
which will in turn require to split up the pv_ops vector as well.
Dropping the pre-filled array makes life easier for objtool to
detect missing initializers in multiple pv_ops_ arrays.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://patch.msgid.link/20260105110520.21356-16-jgross@suse.com
|
|
The only reason the pv_native_*() prototypes are needed is the complete
definition of those functions via an asm() statement, which makes it
impossible to have those functions as static ones.
Move the prototypes from paravirt_types.h into paravirt.c, which is the
only source referencing the functions.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105110520.21356-15-jgross@suse.com
|
|
Move the pv_info related definitions and the declarations of the global
paravirt function primitives into a new header file paravirt-base.h.
Use that header instead of paravirt_types.h in ptrace.h.
Additionally, this is a preparation to reduce the include hell with paravirt
enabled.
[ bp: Massage commit message. ]
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260105110520.21356-14-jgross@suse.com
|
|
The only user of paravirt_sched_clock() is in tsc.c, so move the code
from paravirt.c and paravirt.h to tsc.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260105110520.21356-13-jgross@suse.com
|
|
Enumerate KVM_IRQCHIP_KERNEL if and only if support for an in-kernel I/O
APIC is enabled, as all usage is likewise guarded by CONFIG_KVM_IOAPIC=y.
Link: https://patch.msgid.link/20251206004311.479939-10-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Now that almost everything in ioapic.h is used only by code guarded by
CONFIG_KVM_IOAPIC=y, bury (almost) the entire thing behind the Kconfig.
Link: https://patch.msgid.link/20251206004311.479939-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop "struct dest_map" and fold its members into its one and only user,
"struct rtc_status". Tracking "pending" EOIs and associated vCPUs is very
much a hack for legacy RTC behavior, and should never be needed for other
IRQ delivery. In addition to making it more obvious why KVM tracks target
vCPUs, this will allow burying the "struct rtc_status" definition behind
CONFIG_KVM_IOAPIC=y, which in turn will make it even harder for KVM to
misuse the structure.
No functional change intended.
Link: https://patch.msgid.link/20251206004311.479939-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Turn kvm_irq_delivery_to_apic() into a wrapper that passes NULL for the
@dest_map param, as only the ugly I/O APIC RTC hackery needs to know which
vCPUs received the IRQ.
No functional change intended.
Link: https://patch.msgid.link/20251206004311.479939-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Directly use KVM_MAX_IRQ_ROUTES when checking the number of routes being
defined by userspace when creating a split IRQCHIP. The restriction has
nothing to do with the I/O APIC, e.g. most modern userspace usage is for
routing MSIs. Breaking the unnecessary dependency on the I/O APIC will
allow burying all of ioapic.h behind CONFIG_KVM_IOAPIC=y.
No functional change intended.
Link: https://patch.msgid.link/20251206004311.479939-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop the asserts on the guest-controlled address being 16-byte aligned
when emulating I/O APIC accesses, as the ASSERT()s are guest-triggerable
and ultimately pointless since KVM requires exact register matches, i.e.
will ultimately ignore unaligned accesses anyways.
Drop the ASSERT() definition itself now that all users are gone.
For all intents and purposes, no functional change intended.
Link: https://patch.msgid.link/20251206004311.479939-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
