From: Eric Biggers
Follow best practices by changing the length parameters to size_t and
explicitly specifying the length of the output digest arrays.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
---
include/crypto/internal/sha2.h | 2 +-
include/crypto/sha2.h | 8
From: Eric Biggers
sha256_base.h is no longer used, so remove it.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
---
include/crypto/sha256_base.h | 151 ---
1 file changed, 151 deletions(-)
delete mode 100644 include/crypto/sha256_base.h
diff --git a/i
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Since arch/sparc/crypto/opcodes.h is now needed outside the
arch/sparc/crypto/ directory, move it into arch/sparc/include/asm/ so
that it can be included as .
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
---
arch/sparc/crypto/aes_asm.S | 3 +--
arc
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Since kernel-mode NEON sections are now preemptible on arm64, there is
no longer any need to limit the length of them.
Signed-off-by: Eric Biggers
Reviewed-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
---
arch/arm64/crypto/sha256-glue.c | 19 ++-
1 file cha
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
As has been done for various other algorithms, rework the design of the
SHA-256 library to support arch-optimized implementations, and make
crypto/sha256.c expose both generic and arch-optimized shash algorithms
that wrap the library functions.
This allows users of the SHA-256
Changes in v3:
- Add shash sha256-lib/sha224-lib to provide test coverage for libsha256.
This is based on
https://patchwork.kernel.org/project/linux-crypto/list/?series=957558
Original description:
Following the example of several other algorithms (e.g. CRC32, ChaCha,
Poly1305, BLAKE2s)
On 2025-04-21 09:19, Ritesh Harjani wrote:
Looks like the issue is happening on 6.15-rc2. Did git bisect revealed
a
faulty commit?
Looks like zsmalloc new object mapping API being called, which was
merged in rc1? But let's first confirm from git bisect, unless someone
from linux-mm who knows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull couple of powerpc fixes for 6.15:
The following changes since commit 8ffd015db85fea3e15a77027fda6c02ced4d2444:
Linux 6.15-rc2 (2025-04-13 11:54:49 -0700)
are available in the git repository at:
https://git.kernel.org/pu
On Sun, Apr 27, 2025 at 06:11:38AM -0700, Eric Biggers wrote:
>
> By the way, as I mentioned in my cover letter:
>
> For now the SHA-256 library is well-covered by the crypto_shash
> self-tests, but I plan to add a test for the library directly later.
>
> But due to your gratuitous change
On Sun, Apr 27, 2025 at 05:56:43AM -0700, Eric Biggers wrote:
> On Sun, Apr 27, 2025 at 08:41:38PM +0800, Herbert Xu wrote:
> > On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
> > >
> > > Well, barely a day and you've already ruined my patch series. Now
> > > instead of a
> > > clea
On Sun, Apr 27, 2025 at 08:41:38PM +0800, Herbert Xu wrote:
> On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
> >
> > Well, barely a day and you've already ruined my patch series. Now instead
> > of a
> > clean design where the crypto_shash API is built on top of the normal
> > lib
On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
>
> Well, barely a day and you've already ruined my patch series. Now instead of
> a
> clean design where the crypto_shash API is built on top of the normal library
> API (sha256_update() etc.), there's now a special low-level API
> "s
On Sun, Apr 27, 2025 at 02:30:41PM +0800, Herbert Xu wrote:
> Changes in v2:
> - Rebase on top of lib partial block helper series.
> - Restore the block-only shash implementation of sha256.
> - Move the SIMD hardirq test out of the block functions so that
> it is only done for the lib/crypto inte
From: Sven Peter
The hardware (supposedly) has a 25ms timeout for clock stretching
and the driver uses 100ms which should be plenty.
The interrupt path however misses handling for errors while waiting for
the completion and the polling path uses an open-coded readx_poll_timeout.
Note that we drop
From: Hector Martin
Add handling for all the missing error condition, and better recovery in
pasemi_smb_clear().
Reviewed-by: Alyssa Rosenzweig
Reviewed-by: Neal Gompa
Signed-off-by: Hector Martin
Co-developed-by: Sven Peter
Signed-off-by: Sven Peter
---
drivers/i2c/busses/i2c-pasemi-core.
From: Hector Martin
The I2C bus can get stuck under some conditions (desync between
controller and device). The pasemi controllers include an unjam feature
that is enabled on reset, but was being disabled by the driver. Keep it
enabled by explicitly setting the UJM bit in the CTL register. This
s
From: Hector Martin
This ensures we get all information we need to debug issues when users
forward us their logs.
Signed-off-by: Hector Martin
Reviewed-by: Neal Gompa
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Sven Peter
---
drivers/i2c/busses/i2c-pasemi-core.c | 9 +++--
1 file chan
Hi,
This series adds a few fixes/improvements to the error recovery for
Apple/PASemi i2c controllers.
The patches have been in our downstream tree and were originally used
to debug a rare glitch caused by clock strechting but are useful in
general. We haven't seen the controller misbehave since ad
Hi,
On Thu, Apr 17, 2025, at 15:07, Andi Shyti wrote:
> Hi Sven, Hector,
>
> ...
>
>> +/*
>> + * The hardware (supposedly) has a 25ms timeout for clock stretching, thus
>> + * use 100ms here which should be plenty.
>> + */
>> +#define TRANSFER_TIMEOUT_MS 100
>
> Please use the PASEMI prefix here.
27 matches
Mail list logo
