| #
ec496f77
|
| 09-Feb-2026 |
Jiri Kosina <jkosina@suse.com> |
Merge branch 'for-6.20/sony' into for-linus
- Support for Rock band 4 PS4 and PS5 guitars (Rosalie Wanders)
|
| #
cc4adab1
|
| 20-Jan-2026 |
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> |
Merge tag 'v6.19-rc1' into msm-next
Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC config database defining UBWC_6).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.q
Merge tag 'v6.19-rc1' into msm-next
Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC config database defining UBWC_6).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
show more ...
|
| #
5add3c3c
|
| 19-Dec-2025 |
Thomas Hellström <thomas.hellstrom@linux.intel.com> |
Merge drm/drm-next into drm-xe-next
Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
| #
b8304863
|
| 15-Dec-2025 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
Merge drm/drm-next into drm-intel-next
Sync-up some display code needed for Async flips refactor.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
| #
7f790dd2
|
| 15-Dec-2025 |
Maxime Ripard <mripard@kernel.org> |
Merge drm/drm-next into drm-misc-next
Let's kickstart the v6.20 (7.0?) release cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
| #
ec439c38
|
| 17-Dec-2025 |
Alexei Starovoitov <ast@kernel.org> |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after 6.19-rc1
Cross-merge BPF and other fixes after downstream PR.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
| #
24f171c7
|
| 21-Dec-2025 |
Takashi Iwai <tiwai@suse.de> |
Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.19
We've been quite busy with fixes since the merge window, though
Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.19
We've been quite busy with fixes since the merge window, though not in any particularly exciting ways - the standout thing is the fix for _SX controls which were broken by a change to how we do clamping, otherwise it's all fairly run of the mill fixes and quirks.
show more ...
|
| #
84318277
|
| 15-Dec-2025 |
Maarten Lankhorst <dev@lankhorst.se> |
Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes
Pull in rc1 to include all changes since the merge window closed, and grab all fixes and changes from drm/drm-next.
Signed-off-by: M
Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes
Pull in rc1 to include all changes since the merge window closed, and grab all fixes and changes from drm/drm-next.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
show more ...
|
| #
187d0801
|
| 12-Dec-2025 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fixes from Eric Biggers: "Fixes for some recent regressions as well as some
Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fixes from Eric Biggers: "Fixes for some recent regressions as well as some longstanding issues:
- Fix incorrect output from the arm64 NEON implementation of GHASH
- Merge the ksimd scopes in the arm64 XTS code to reduce stack usage
- Roll up the BLAKE2b round loop on 32-bit kernels to greatly reduce code size and stack usage
- Add missing RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS dependency
- Fix chacha-riscv64-zvkb.S to not use frame pointer for data"
* tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: crypto: arm64/ghash - Fix incorrect output from ghash-neon crypto/arm64: sm4/xts - Merge ksimd scopes to reduce stack bloat crypto/arm64: aes/xts - Use single ksimd scope to reduce stack bloat lib/crypto: blake2s: Replace manual unrolling with unrolled_full lib/crypto: blake2b: Roll up BLAKE2b round loop on 32-bit lib/crypto: riscv: Depend on RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS lib/crypto: riscv/chacha: Avoid s0/fp register
show more ...
|
| #
2e8f7b17
|
| 05-Dec-2025 |
Eric Biggers <ebiggers@kernel.org> |
lib/crypto: blake2b: Roll up BLAKE2b round loop on 32-bit
BLAKE2b has a state of 16 64-bit words. Add the message data in and there are 32 64-bit words. With the current code where all the rounds
lib/crypto: blake2b: Roll up BLAKE2b round loop on 32-bit
BLAKE2b has a state of 16 64-bit words. Add the message data in and there are 32 64-bit words. With the current code where all the rounds are unrolled to enable constant-folding of the blake2b_sigma values, this results in a very large code size on 32-bit kernels, including a recurring issue where gcc uses a large amount of stack.
There's just not much benefit to this unrolling when the code is already so large. Let's roll up the rounds when !CONFIG_64BIT.
To avoid having to duplicate the code, just write the code once using a loop, and conditionally use 'unrolled_full' from <linux/unroll.h>.
Then, fold the now-unneeded ROUND() macro into the loop. Finally, also remove the now-unneeded override of the stack frame size warning.
Code size improvements for blake2b_compress_generic():
Size before (bytes) Size after (bytes) ------------------- ------------------ i386, gcc 27584 3632 i386, clang 18208 3248 arm32, gcc 19912 2860 arm32, clang 21336 3344
Running the BLAKE2b benchmark on a !CONFIG_64BIT kernel on an x86_64 processor shows a 16384B throughput change of 351 => 340 MB/s (gcc) or 442 MB/s => 375 MB/s (clang). So clearly not much of a slowdown either. But also that microbenchmark also effectively disregards cache usage, which is important in practice and is far better in the smaller code.
Note: If we rolled up the loop on x86_64 too, the change would be 7024 bytes => 1584 bytes and 1960 MB/s => 1396 MB/s (gcc), or 6848 bytes => 1696 bytes and 1920 MB/s => 1263 MB/s (clang). Maybe still worth it, though not quite as clearly beneficial.
Fixes: 91d689337fe8 ("crypto: blake2b - add blake2b generic implementation") Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20251205050330.89704-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
show more ...
|
| #
5abe8d8e
|
| 03-Dec-2025 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library updates from Eric Biggers: "This is the main crypto library pull request
Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library updates from Eric Biggers: "This is the main crypto library pull request for 6.19. It includes:
- Add SHA-3 support to lib/crypto/, including support for both the hash functions and the extendable-output functions. Reimplement the existing SHA-3 crypto_shash support on top of the library.
This is motivated mainly by the upcoming support for the ML-DSA signature algorithm, which needs the SHAKE128 and SHAKE256 functions. But even on its own it's a useful cleanup.
This also fixes the longstanding issue where the architecture-optimized SHA-3 code was disabled by default.
- Add BLAKE2b support to lib/crypto/, and reimplement the existing BLAKE2b crypto_shash support on top of the library.
This is motivated mainly by btrfs, which supports BLAKE2b checksums. With this change, all btrfs checksum algorithms now have library APIs. btrfs is planned to start just using the library directly.
This refactor also improves consistency between the BLAKE2b code and BLAKE2s code. And as usual, it also fixes the issue where the architecture-optimized BLAKE2b code was disabled by default.
- Add POLYVAL support to lib/crypto/, replacing the existing POLYVAL support in crypto_shash. Reimplement HCTR2 on top of the library.
This simplifies the code and improves HCTR2 performance. As usual, it also makes the architecture-optimized code be enabled by default. The generic implementation of POLYVAL is greatly improved as well.
- Clean up the BLAKE2s code
- Add FIPS self-tests for SHA-1, SHA-2, and SHA-3"
* tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (37 commits) fscrypt: Drop obsolete recommendation to enable optimized POLYVAL crypto: polyval - Remove the polyval crypto_shash crypto: hctr2 - Convert to use POLYVAL library lib/crypto: x86/polyval: Migrate optimized code into library lib/crypto: arm64/polyval: Migrate optimized code into library lib/crypto: polyval: Add POLYVAL library crypto: polyval - Rename conflicting functions lib/crypto: x86/blake2s: Use vpternlogd for 3-input XORs lib/crypto: x86/blake2s: Avoid writing back unchanged 'f' value lib/crypto: x86/blake2s: Improve readability lib/crypto: x86/blake2s: Use local labels for data lib/crypto: x86/blake2s: Drop check for nblocks == 0 lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit lib/crypto: arm, arm64: Drop filenames from file comments lib/crypto: arm/blake2s: Fix some comments crypto: s390/sha3 - Remove superseded SHA-3 code crypto: sha3 - Reimplement using library API crypto: jitterentropy - Use default sha3 implementation lib/crypto: s390/sha3: Add optimized one-shot SHA-3 digest functions lib/crypto: sha3: Support arch overrides of one-shot digest functions ...
show more ...
|
| #
23a16c95
|
| 18-Oct-2025 |
Eric Biggers <ebiggers@kernel.org> |
lib/crypto: blake2b: Add BLAKE2b library functions
Add a library API for BLAKE2b, closely modeled after the BLAKE2s API.
This will allow in-kernel users such as btrfs to use BLAKE2b without going t
lib/crypto: blake2b: Add BLAKE2b library functions
Add a library API for BLAKE2b, closely modeled after the BLAKE2s API.
This will allow in-kernel users such as btrfs to use BLAKE2b without going through the generic crypto layer. In addition, as usual the BLAKE2b crypto_shash algorithms will be reimplemented on top of this.
Note: to create lib/crypto/blake2b.c I made a copy of lib/crypto/blake2s.c and made the updates from BLAKE2s => BLAKE2b. This way, the BLAKE2s and BLAKE2b code is kept consistent. Therefore, it borrows the SPDX-License-Identifier and Copyright from lib/crypto/blake2s.c rather than crypto/blake2b_generic.c.
The library API uses 'struct blake2b_ctx', consistent with other lib/crypto/ APIs. The existing 'struct blake2b_state' will be removed once the blake2b crypto_shash algorithms are updated to stop using it.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20251018043106.375964-7-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
show more ...
|