* [PATCH v2] crypto: atmel-tdes - use scatterlist length before DMA mapping
From: Thorsten Blum @ 2026-06-11 10:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Nicolas Royer, Eric Bénard
Cc: Thorsten Blum, stable, linux-crypto, linux-arm-kernel,
linux-kernel
Using sg_dma_len() is only valid after mapping the scatterlist with
dma_map_sg(). However, atmel_tdes_crypt_start() uses it before mapping
to compare input/output lengths and to compute the transfer count.
Use the original scatterlist lengths before DMA mapping to avoid reading
stale or uninitialized DMA lengths when CONFIG_NEED_SG_DMA_LENGTH=y.
Drop the output scatterlist length in the fast path since it is equal to
->in_sg->length and does not change the transfer count.
Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver")
Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Drop ->out_sg->length in the fast path (Herbert)
- v1: https://lore.kernel.org/lkml/20260531204115.689052-3-thorsten.blum@linux.dev/
---
drivers/crypto/atmel-tdes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 643e507f9c02..d380f6741a2c 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -463,14 +463,13 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
IS_ALIGNED(dd->out_sg->length, dd->ctx->block_size);
fast = in && out;
- if (sg_dma_len(dd->in_sg) != sg_dma_len(dd->out_sg))
+ if (dd->in_sg->length != dd->out_sg->length)
fast = 0;
}
if (fast) {
- count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
- count = min_t(size_t, count, sg_dma_len(dd->out_sg));
+ count = min_t(size_t, dd->total, dd->in_sg->length);
err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
if (!err) {
^ permalink raw reply related
* Re: [PATCH 2/2] crypto: qce: Fix CTR-AES for partial block requests
From: Kuldeep Singh @ 2026-06-11 9:49 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610184610.GC1158828@google.com>
> This fix isn't Cc'ed to stable, so stable kernels will remain vulnerable
> to this bug.
Sure, I'll Cc stable tag in v2 with any other feedback/comments on these
patches.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 0/2] Fix Qualcomm Crypto engine self tests failures
From: Kuldeep Singh @ 2026-06-11 9:47 UTC (permalink / raw)
To: Eric Biggers, Bartosz Golaszewski
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610184205.GB1158828@google.com>
On 11-06-2026 00:12, Eric Biggers wrote:
> On Wed, Jun 10, 2026 at 11:24:03AM +0530, Kuldeep Singh wrote:
>> Steps followed:
>> - Enable EXPERT and CRYPTO_SEFLTESTS config.
>
> So the full tests (CRYPTO_SELFTESTS_FULL) still haven't been run?
Crypto_selftests was only run as there's some discussion ongoing with
Bartosz on removal of deprecated/unsafe algos.
Seems Bartosz will be sending patches for algorithm removal changes.
The rest relevant selftests issues we'll fix accordingly.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Herbert Xu @ 2026-06-11 9:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <20260611050731-mutt-send-email-mst@kernel.org>
On Thu, Jun 11, 2026 at 05:10:32AM -0400, Michael S. Tsirkin wrote:
>
> data_avail is under hypervisor control
>
> avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
> if (vi->data_idx >= avail) {
> vi->data_idx = 0;
>
> and maybe this can speculate past the if?
>
> I agree, this is all speculation )
Either it is vulnerable to Spectre, or it isn't. Adding nospec
markers when you're not sure is cargo cult programming.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 9:10 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aipvZhfvdtRxOQm0@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 04:18:46PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 03:58:17AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 11, 2026 at 03:46:58PM +0800, Herbert Xu wrote:
> > > On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > > > > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > > > > >
> > > > > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > > > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > > > > + memcpy(buf, vi->data + idx, size);
> > > >
> > > > All the "malicious device" things are confusing. Spectre things -
> > > > doubly so.
> > > >
> > > > So if an access is speculated then CPU might speculate feeding a kernel
> > > > secret into RNG. And then the speculated RNG value maybe can be also
> > > > speculatively be used by some kernel code as an index
> > > > to trigger a cache access, finally leaking the secret?
> > > >
> > > > Maybe?
> > >
> > > The way Spectre works is if you have an actual instruction using
> > > idx directly. I don't see how that translates to memcpy.
> >
> > I am not sure it has to be direct:
> >
> > if (malicious_idx > SIZE)
> > return;
> > src += malicious_idx;
>
> Wait but vi->data_idx isn't even under the hypervisor's control.
>
> It's an index maintained by our own driver. So how can it be
> malicious?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
data_avail is under hypervisor control
avail = min_t(unsigned int, vi->data_avail, sizeof(vi->data));
if (vi->data_idx >= avail) {
vi->data_idx = 0;
and maybe this can speculate past the if?
I agree, this is all speculation )
--
MST
^ permalink raw reply
* Re: [PATCH] crypto: tegra: fix refcount leak in tegra_se_host1x_submit()
From: Herbert Xu @ 2026-06-11 8:55 UTC (permalink / raw)
To: Wentao Liang
Cc: akhilrajeev, davem, thierry.reding, jonathanh, linux-crypto,
linux-tegra, linux-kernel, stable
In-Reply-To: <20260604102706.3787771-1-vulab@iscas.ac.cn>
On Thu, Jun 04, 2026 at 10:27:06AM +0000, Wentao Liang wrote:
> The timeout error path in tegra_se_host1x_submit() returns without
> calling host1x_job_put(), while all other paths (success, submit
> error, pin error) properly release the job reference through the
> job_put label. Since host1x_job_alloc() initializes the reference
> count and host1x_job_put() is required to drop it, omitting it on
> timeout causes a permanent refcount leak.
>
> Fix this by redirecting the timeout return to the existing job_put
> label, ensuring the job reference and any associated syncpt
> references are consistently released.
>
> Cc: stable@vger.kernel.org
> Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/crypto/tegra/tegra-se-main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - allow authenc(hmac(sha{256,384}),cts(cbc(aes))) in FIPS mode
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Ilya Dryomov; +Cc: David Howells, linux-crypto, ceph-devel, linux-kernel
In-Reply-To: <20260603155008.736872-1-idryomov@gmail.com>
On Wed, Jun 03, 2026 at 05:50:04PM +0200, Ilya Dryomov wrote:
> hmac(sha256), hmac(sha384) and cts(cbc(aes)) algorithms have been
> marked as FIPS allowed for years. Mark the respective authenc()
> constructions per RFC 8009 ("AES Encryption with HMAC-SHA2 for
> Kerberos 5") as such as well.
>
> SP 800-57 Part 3 Rev. 1 from Jan 2015 [1] links the draft of what
> became RFC 8009 in Oct 2016 as approved in section 6.3 Procurement
> Guidance (item/recommendation 3).
>
> [1] https://csrc.nist.gov/pubs/sp/800/57/pt3/r1/final
>
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
> crypto/testmgr.c | 2 ++
> 1 file changed, 2 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: jh7110: fix refcount leak in starfive_trng_read()
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Wentao Liang; +Cc: jiajie.ho, olivia, linux-crypto, linux-kernel, stable
In-Reply-To: <20260603110327.3750514-1-vulab@iscas.ac.cn>
On Wed, Jun 03, 2026 at 11:03:27AM +0000, Wentao Liang wrote:
> The starfive_trng_read() function acquires a runtime PM reference
> via pm_runtime_get_sync() but fails to release it on two error
> paths. If starfive_trng_wait_idle() or starfive_trng_cmd() returns
> an error, the function exits without calling
> pm_runtime_put_sync_autosuspend(), leaving the runtime PM usage
> counter permanently elevated and preventing the device from entering
> runtime suspend.
>
> Refactor the function to use a unified error path that calls
> pm_runtime_put_sync_autosuspend() before returning.
>
> Cc: stable@vger.kernel.org
> Fixes: c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/char/hw_random/jh7110-trng.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - drop dead code in atmel_ecdh_max_size
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260602222517.1071850-3-thorsten.blum@linux.dev>
On Wed, Jun 03, 2026 at 12:25:19AM +0200, Thorsten Blum wrote:
> atmel_ecdh_init_tfm() always allocates ctx->fallback, so it is never
> NULL in atmel_ecdh_max_size(). Remove the dead code and return
> crypto_kpp_maxsize() directly.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-ecc.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: cavium/cpt - fix DMA cleanup using wrong loop index
From: Herbert Xu @ 2026-06-11 8:54 UTC (permalink / raw)
To: Felix Gu
Cc: George Cherian, David S. Miller, David Daney, George Cherian,
linux-crypto, linux-kernel
In-Reply-To: <20260602-cptvf-v1-1-d68e58e59173@gmail.com>
On Tue, Jun 02, 2026 at 10:55:35PM +0800, Felix Gu wrote:
> The sg_cleanup error path used list[i] instead of list[j] when unmapping
> DMA buffers, leaking successfully mapped entries and repeatedly unmapping
> the failed one.
>
> Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: marvell/octeontx - fix DMA cleanup using wrong loop index
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Felix Gu
Cc: Srujana Challa, Bharat Bhushan, David S. Miller, Lukasz Bartosik,
linux-crypto, linux-kernel
In-Reply-To: <20260602-otx-v1-1-e0c9ec50cb04@gmail.com>
On Tue, Jun 02, 2026 at 10:38:26PM +0800, Felix Gu wrote:
> The sg_cleanup path used list[i] instead of list[j] when unmapping DMA
> buffers, leaking successfully mapped entries and repeatedly unmapping
> the failed one.
>
> Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: make myself the maintainer of the Qualcomm QCE driver
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Demi Marie Obenour, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, Eric Biggers, Ard Biesheuvel, Kuldeep Singh,
linux-crypto, linux-arm-msm, linux-kernel, brgl
In-Reply-To: <20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com>
On Tue, Jun 02, 2026 at 02:46:56PM +0200, Bartosz Golaszewski wrote:
> Qualcomm wants to keep supporting and extending the crypto engine driver.
> Thara has not been active for many months, so change the maintainer to
> myself and upgrade the driver to Supported.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> I've considered also marking the driver as BROKEN but decided not to.
> Next week I plan to address the failing self tests as well as go through
> all the ciphers it provides and remove ones that are known to be weak or
> deprecated.
>
> Regarding the series that proposed to remove this[1], let this be the
> official objection. Qualcomm's clients use this IP, we have support for
> new features planned and intend to refactor it significantly.
>
> [1] https://lore.kernel.org/all/20260523-delete-qce-v1-0-86105cd7f406@gmail.com/
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: amcc - convert irq_of_parse_and_map to platform_get_irq
From: Herbert Xu @ 2026-06-11 8:53 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-crypto, David S. Miller, open list
In-Reply-To: <20260602014645.522137-1-rosenp@gmail.com>
On Mon, Jun 01, 2026 at 06:46:45PM -0700, Rosen Penev wrote:
> Replace the deprecated irq_of_parse_and_map() call with the modern
> platform_get_irq() in the probe function. This also improves error
> handling: platform_get_irq() returns a negative errno on failure,
> whereas irq_of_parse_and_map() returned 0.
>
> Change the irq field in struct crypto4xx_core_device from u32 to int
> to match the return type of platform_get_irq().
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/crypto/amcc/crypto4xx_core.c | 6 +++++-
> drivers/crypto/amcc/crypto4xx_core.h | 2 +-
> 2 files changed, 6 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: sun4i-ss - Remove insecure and unused rng_alg
From: Herbert Xu @ 2026-06-11 8:50 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-sunxi, linux-arm-kernel, linux-kernel,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Corentin Labbe,
stable, Tianchu Chen
In-Reply-To: <20260601160757.79645-1-ebiggers@kernel.org>
On Mon, Jun 01, 2026 at 04:07:57PM +0000, Eric Biggers wrote:
> Remove sun4i_ss_rng, as it is insecure and unused:
>
> - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing
> locking and has a buffer overflow. sun4i_ss_prng_generate() fails to
> fill the entire buffer with cryptographic random bytes, because it
> rounds the destination length down and also doesn't actually wait for
> the hardware to be ready before pulling bytes from it.
>
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
>
> The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen
> and discovered by Atuin - Automated Vulnerability Discovery Engine
>
> There's no point in fixing all these vulnerabilities individually when
> this is unused code, so let's just remove it.
>
> Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG")
> Cc: stable@vger.kernel.org
> Reported-by: Tianchu Chen <flynnnchen@tencent.com>
> Closes: https://lore.kernel.org/r/af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev/
> Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is targeting crypto/master
>
> v2: rebased onto crypto/master, and added Acked-by and Reported-by
>
> arch/arm/configs/sunxi_defconfig | 1 -
> drivers/crypto/allwinner/Kconfig | 8 ---
> drivers/crypto/allwinner/sun4i-ss/Makefile | 1 -
> .../crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 36 ----------
> .../crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 69 -------------------
> drivers/crypto/allwinner/sun4i-ss/sun4i-ss.h | 20 ------
> 6 files changed, 135 deletions(-)
> delete mode 100644 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] Xilinx TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:49 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Mounika Botcha, Harsh Jain,
Olivia Mackall, Michal Simek, linux-arm-kernel
In-Reply-To: <20260531191738.55843-1-ebiggers@kernel.org>
On Sun, May 31, 2026 at 12:17:34PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the Xilinx TRNG driver by:
>
> - Removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> - Replacing the really complicated AES based entropy extraction
> algorithm with a much simpler one.
>
> Note that this mirrors similar changes in other drivers.
>
> Eric Biggers (4):
> crypto: xilinx-trng - Remove crypto_rng interface
> crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
> crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
> hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> crypto/Kconfig | 5 -
> crypto/Makefile | 2 -
> crypto/df_sp80090a.c | 222 ------------------
> drivers/char/hw_random/Kconfig | 11 +
> drivers/char/hw_random/Makefile | 1 +
> .../xilinx => char/hw_random}/xilinx-trng.c | 134 ++---------
> drivers/crypto/Kconfig | 13 -
> drivers/crypto/xilinx/Makefile | 1 -
> include/crypto/df_sp80090a.h | 53 -----
> 11 files changed, 37 insertions(+), 409 deletions(-)
> delete mode 100644 crypto/df_sp80090a.c
> rename drivers/{crypto/xilinx => char/hw_random}/xilinx-trng.c (75%)
> delete mode 100644 include/crypto/df_sp80090a.h
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: exynos-rng - Remove exynos-rng driver
From: Herbert Xu @ 2026-06-11 8:49 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-samsung-soc, Krzysztof Kozlowski, Alim Akhtar,
linux-kernel
In-Reply-To: <20260531175932.32171-1-ebiggers@kernel.org>
On Sun, May 31, 2026 at 10:59:31AM -0700, Eric Biggers wrote:
> This driver has no purpose. It doesn't feed into the Linux RNG, nor
> does it implement the hwrng interface. It is accessible only via the
> "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
> uses either the Linux RNG, or rarely /dev/hwrng.
>
> Moreover, this is a PRNG whose only source of entropy is the 160-bit
> seed the user passes in. So this can be used only by a user who already
> has a source of cryptographically secure random numbers, such as
> /dev/random. Which they can, and do, just use in the first place.
>
> Just remove this driver. There's no need to keep useless code around.
>
> Note that the other crypto_rng drivers in drivers/crypto/ are similarly
> unused and are being removed too. This commit just handles exynos-rng.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> MAINTAINERS | 8 -
> arch/arm/configs/exynos_defconfig | 1 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> drivers/crypto/Kconfig | 18 --
> drivers/crypto/Makefile | 1 -
> drivers/crypto/exynos-rng.c | 399 ----------------------------
> 6 files changed, 428 deletions(-)
> delete mode 100644 drivers/crypto/exynos-rng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/2] HiSilicon TRNG fix and simplification
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Olivia Mackall, Weili Qian, Wei Xu, Longfang Liu,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260530202624.20768-1-ebiggers@kernel.org>
On Sat, May 30, 2026 at 01:26:22PM -0700, Eric Biggers wrote:
> This series fixes and greatly simplifies the HiSilicon TRNG driver by
> removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> Note that this mirrors similar changes in other drivers such as qcom-rng
> (https://lore.kernel.org/r/20260530020332.143058-1-ebiggers@kernel.org)
>
> Eric Biggers (2):
> crypto: hisi-trng - Remove crypto_rng interface
> hwrng: hisi-trng - Move hisi-trng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> drivers/char/hw_random/Kconfig | 10 +
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/hisi-trng-v2.c | 98 +++++++
> drivers/crypto/hisilicon/Kconfig | 8 -
> drivers/crypto/hisilicon/Makefile | 1 -
> drivers/crypto/hisilicon/trng/Makefile | 2 -
> drivers/crypto/hisilicon/trng/trng.c | 390 -------------------------
> 9 files changed, 111 insertions(+), 403 deletions(-)
> create mode 100644 drivers/char/hw_random/hisi-trng-v2.c
> delete mode 100644 drivers/crypto/hisilicon/trng/Makefile
> delete mode 100644 drivers/crypto/hisilicon/trng/trng.c
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: loongson - Remove broken and unused loongson-rng
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, loongarch, Qunqin Zhao, Huacai Chen,
Yinggang Gu, Lee Jones, stable
In-Reply-To: <20260529233208.8703-1-ebiggers@kernel.org>
On Fri, May 29, 2026 at 04:32:08PM -0700, Eric Biggers wrote:
> The loongson-rng rng_alg has several vulnerabilities, including not
> providing forward security, and a use-after-free bug due to the use of
> wait_for_completion_interruptible().
>
> Meanwhile, the rng_alg framework doesn't really have any purpose in the
> first place other than to access the software algorithms crypto/drbg.c
> and crypto/jitterentropy.c. Hardware-specific rng_algs have no
> in-kernel user, and unlike hwrng there's no feed into the actual Linux
> RNG. As such, there's really no point to this code. There are of
> course other rng_alg drivers that are similarly unused, but they're
> similarly in the process of being phased out, e.g.
> https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
> https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org
>
> Given that, there's no point in fixing forward these vulnerabilities,
> and it makes much more sense to simply roll back the addition of this
> driver. If this platform provides TRNG (not PRNG) functionality, it
> could make sense to add a hwrng driver, but it would be quite different.
>
> Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/
> Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> MAINTAINERS | 1 -
> arch/loongarch/configs/loongson32_defconfig | 1 -
> arch/loongarch/configs/loongson64_defconfig | 1 -
> drivers/crypto/Kconfig | 1 -
> drivers/crypto/Makefile | 1 -
> drivers/crypto/loongson/Kconfig | 6 -
> drivers/crypto/loongson/Makefile | 1 -
> drivers/crypto/loongson/loongson-rng.c | 209 --------------------
> 8 files changed, 221 deletions(-)
> delete mode 100644 drivers/crypto/loongson/Kconfig
> delete mode 100644 drivers/crypto/loongson/Makefile
> delete mode 100644 drivers/crypto/loongson/loongson-rng.c
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Herbert Xu @ 2026-06-11 8:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Christian Lamparter, linuxppc-dev, linux-kernel,
stable
In-Reply-To: <20260529220430.34135-1-ebiggers@kernel.org>
On Fri, May 29, 2026 at 03:04:30PM -0700, Eric Biggers wrote:
> Remove crypto4xx_rng, as it is insecure and unused:
>
> - It has only a 64-bit security strength, which is highly inadequate.
> This can be seen by the fact that crypto4xx_hw_init() seeds it with
> only 64 bits of entropy, and the fact that the original commit
> mentions that it implements ANSI X9.17 Annex C.
>
> Another issue was that this driver didn't implement the crypto_rng API
> correctly, as crypto4xx_prng_generate() didn't return 0 on success.
>
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
>
> Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> drivers/crypto/Kconfig | 1 -
> drivers/crypto/amcc/crypto4xx_core.c | 88 -------------------------
> drivers/crypto/amcc/crypto4xx_core.h | 4 --
> drivers/crypto/amcc/crypto4xx_reg_def.h | 11 ----
> 4 files changed, 104 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - validate RSA CRT component lengths
From: Herbert Xu @ 2026-06-11 8:47 UTC (permalink / raw)
To: Giovanni Cabiddu
Cc: linux-crypto, qat-linux, stable, Ahsan Atta, Laurent M Coquerel
In-Reply-To: <20260528155854.40858-1-giovanni.cabiddu@intel.com>
On Thu, May 28, 2026 at 04:57:44PM +0100, Giovanni Cabiddu wrote:
> The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,
> q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()
> allocates half-size DMA buffers (key_sz / 2) and right-aligns each
> component with:
>
> memcpy(dst + half_key_sz - len, src, len)
>
> When a CRT component is larger than half_key_sz the subtraction
> underflows and memcpy writes past the DMA buffer, causing memory
> corruption.
>
> Add a len > half_key_sz check next to the existing !len check for each
> of the five CRT components so the driver falls back to the non-CRT path
> instead of writing out of bounds.
>
> Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
> Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
> Tested-by: Laurent M Coquerel <laurent.m.coquerel@intel.com>
> ---
> drivers/crypto/intel/qat/qat_common/qat_asym_algs.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Herbert Xu @ 2026-06-11 7:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <20260611025916-mutt-send-email-mst@kernel.org>
On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > >
> > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > + memcpy(buf, vi->data + idx, size);
>
> All the "malicious device" things are confusing. Spectre things -
> doubly so.
>
> So if an access is speculated then CPU might speculate feeding a kernel
> secret into RNG. And then the speculated RNG value maybe can be also
> speculatively be used by some kernel code as an index
> to trigger a cache access, finally leaking the secret?
>
> Maybe?
The way Spectre works is if you have an actual instruction using
idx directly. I don't see how that translates to memcpy.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Herbert Xu @ 2026-06-11 8:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <20260611035035-mutt-send-email-mst@kernel.org>
On Thu, Jun 11, 2026 at 03:58:17AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 11, 2026 at 03:46:58PM +0800, Herbert Xu wrote:
> > On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > > > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > > > >
> > > > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > > > + memcpy(buf, vi->data + idx, size);
> > >
> > > All the "malicious device" things are confusing. Spectre things -
> > > doubly so.
> > >
> > > So if an access is speculated then CPU might speculate feeding a kernel
> > > secret into RNG. And then the speculated RNG value maybe can be also
> > > speculatively be used by some kernel code as an index
> > > to trigger a cache access, finally leaking the secret?
> > >
> > > Maybe?
> >
> > The way Spectre works is if you have an actual instruction using
> > idx directly. I don't see how that translates to memcpy.
>
> I am not sure it has to be direct:
>
> if (malicious_idx > SIZE)
> return;
> src += malicious_idx;
Wait but vi->data_idx isn't even under the hypervisor's control.
It's an index maintained by our own driver. So how can it be
malicious?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 7:58 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aipn8sIAQ6Ai2sax@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 03:46:58PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > > >
> > > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > > + memcpy(buf, vi->data + idx, size);
> >
> > All the "malicious device" things are confusing. Spectre things -
> > doubly so.
> >
> > So if an access is speculated then CPU might speculate feeding a kernel
> > secret into RNG. And then the speculated RNG value maybe can be also
> > speculatively be used by some kernel code as an index
> > to trigger a cache access, finally leaking the secret?
> >
> > Maybe?
>
> The way Spectre works is if you have an actual instruction using
> idx directly. I don't see how that translates to memcpy.
I am not sure it has to be direct:
if (malicious_idx > SIZE)
return;
src += malicious_idx;
memcpy(&value, src, ...)
....
hash = complex_hash_of(value)
....
return p[hash * 512];
is IIUC still a valid spectre v1 gadget leaking a value beyong SIZE, or
did I miss something?
And rng is a kind of a complex hash, but I also think in that "...."
in the kernel is probably large enough to close any transient execution
window.
So sure, we can drop this.
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 19/19] crypto: talitos - Remove TALITOS_DESC_SIZE macro
From: Paul Louvel @ 2026-06-11 7:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Thomas Petazzoni, Herve Codina, Christophe Leroy, linux-crypto,
linux-kernel, Paul Louvel
In-Reply-To: <20260611-7-1-rc1_talitos_cleanup-v2-0-aa4a813ce69b@bootlin.com>
Now that TALITOS_DESC_SIZE is simply sizeof(struct talitos_desc) with no
arithmetic, the macro is useless. Replace all occurrences with the
underlying sizeof expression and remove the macro.
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
drivers/crypto/talitos/talitos.c | 16 ++++++++--------
drivers/crypto/talitos/talitos.h | 2 --
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/talitos/talitos.c b/drivers/crypto/talitos/talitos.c
index 1221eb9497fb..7faf3c2606a9 100644
--- a/drivers/crypto/talitos/talitos.c
+++ b/drivers/crypto/talitos/talitos.c
@@ -166,7 +166,7 @@ static void dma_map_request(struct device *dev, struct talitos_request *request,
if (is_sec1()) {
while (edesc) {
dma_desc = dma_map_single(dev, &edesc->desc.sec1.hdr,
- TALITOS_DESC_SIZE,
+ sizeof(struct talitos_desc),
DMA_BIDIRECTIONAL);
if (!prev_edesc) {
@@ -179,7 +179,7 @@ static void dma_map_request(struct device *dev, struct talitos_request *request,
prev_edesc->desc.sec1.next_desc = cpu_to_be32(dma_desc);
dma_sync_single_for_device(dev, prev_dma_desc,
- TALITOS_DESC_SIZE,
+ sizeof(struct talitos_desc),
DMA_TO_DEVICE);
next:
@@ -188,7 +188,7 @@ static void dma_map_request(struct device *dev, struct talitos_request *request,
edesc = edesc->next_desc;
}
} else {
- request->dma_desc = dma_map_single(dev, desc, TALITOS_DESC_SIZE,
+ request->dma_desc = dma_map_single(dev, desc, sizeof(struct talitos_desc),
DMA_BIDIRECTIONAL);
}
}
@@ -258,7 +258,7 @@ static __be32 get_request_hdr(struct device *dev,
if (!is_sec1()) {
dma_sync_single_for_cpu(dev, request->dma_desc,
- TALITOS_DESC_SIZE, DMA_BIDIRECTIONAL);
+ sizeof(struct talitos_desc), DMA_BIDIRECTIONAL);
return request->desc->sec2.hdr;
}
@@ -270,7 +270,7 @@ static __be32 get_request_hdr(struct device *dev,
edesc = edesc->next_desc;
}
- dma_sync_single_for_cpu(dev, dma_desc, TALITOS_DESC_SIZE,
+ dma_sync_single_for_cpu(dev, dma_desc, sizeof(struct talitos_desc),
DMA_BIDIRECTIONAL);
return edesc->desc.sec1.hdr;
@@ -282,17 +282,17 @@ static void dma_unmap_request(struct device *dev,
struct talitos_edesc *edesc;
if (is_sec1()) {
- dma_unmap_single(dev, request->dma_desc, TALITOS_DESC_SIZE,
+ dma_unmap_single(dev, request->dma_desc, sizeof(struct talitos_desc),
DMA_BIDIRECTIONAL);
edesc = container_of(request->desc, struct talitos_edesc, desc);
while (edesc->next_desc) {
dma_unmap_single(dev,
be32_to_cpu(edesc->desc.sec1.next_desc),
- TALITOS_DESC_SIZE, DMA_BIDIRECTIONAL);
+ sizeof(struct talitos_desc), DMA_BIDIRECTIONAL);
edesc = edesc->next_desc;
}
} else {
- dma_unmap_single(dev, request->dma_desc, TALITOS_DESC_SIZE,
+ dma_unmap_single(dev, request->dma_desc, sizeof(struct talitos_desc),
DMA_BIDIRECTIONAL);
}
}
diff --git a/drivers/crypto/talitos/talitos.h b/drivers/crypto/talitos/talitos.h
index 2e2414ad1e03..6b9ce69daed4 100644
--- a/drivers/crypto/talitos/talitos.h
+++ b/drivers/crypto/talitos/talitos.h
@@ -78,8 +78,6 @@ struct talitos_desc {
};
};
-#define TALITOS_DESC_SIZE (sizeof(struct talitos_desc))
-
/*
* talitos_edesc - s/w-extended descriptor
* @bufsl: scatterlist buffer
--
2.54.0
^ permalink raw reply related
* [PATCH v2 18/19] crypto: talitos - Introduce per-SEC-version descriptor and pointer structures
From: Paul Louvel @ 2026-06-11 7:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Thomas Petazzoni, Herve Codina, Christophe Leroy, linux-crypto,
linux-kernel, Paul Louvel
In-Reply-To: <20260611-7-1-rc1_talitos_cleanup-v2-0-aa4a813ce69b@bootlin.com>
The SEC1 and SEC2 hardware descriptor and pointer formats differ in many
ways:
- SEC1 pointers have a 16-bit reserved field followed by a 16-bit length
and 32-bit address, while SEC2 pointers pack a 16-bit length, 8-bit
jump/extent, 8-bit extended address, and 32-bit address.
- SEC1 descriptors chain through a next_desc field absent from SEC2,
while SEC2 has a hdr_lo field that SEC1 lacks.
In the current code, reading those structures and mapping them to the
documentation is not obvious.
Instead of using anonymous union members, define two separate structures
for hardware descriptor and pointer. The counterpart is that some added
helpers are needed.
Even if the structure is naturally aligned and no padding is added, add
the __packed attribute to hint that these structures are used by the
hardware.
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
drivers/crypto/talitos/talitos-aead.c | 42 +++++-----
drivers/crypto/talitos/talitos-hash.c | 34 ++++----
drivers/crypto/talitos/talitos-skcipher.c | 27 +++---
drivers/crypto/talitos/talitos.c | 20 ++---
drivers/crypto/talitos/talitos.h | 131 +++++++++++++++++++++++-------
5 files changed, 162 insertions(+), 92 deletions(-)
diff --git a/drivers/crypto/talitos/talitos-aead.c b/drivers/crypto/talitos/talitos-aead.c
index d9e27eddfd1d..667b99581702 100644
--- a/drivers/crypto/talitos/talitos-aead.c
+++ b/drivers/crypto/talitos/talitos-aead.c
@@ -94,11 +94,11 @@ static void ipsec_esp_unmap(struct device *dev,
unsigned int ivsize = crypto_aead_ivsize(aead);
unsigned int authsize = crypto_aead_authsize(aead);
unsigned int cryptlen = areq->cryptlen - (encrypt ? 0 : authsize);
- bool is_ipsec_esp = edesc->desc.hdr & DESC_HDR_TYPE_IPSEC_ESP;
- struct talitos_ptr *civ_ptr = &edesc->desc.ptr[is_ipsec_esp ? 2 : 3];
+ bool is_ipsec_esp = from_talitos_desc_hdr(&edesc->desc) & DESC_HDR_TYPE_IPSEC_ESP;
+ struct talitos_ptr *civ_ptr = from_talitos_desc_ptr(&edesc->desc, is_ipsec_esp ? 2 : 3);
if (is_ipsec_esp)
- unmap_single_talitos_ptr(dev, &edesc->desc.ptr[6],
+ unmap_single_talitos_ptr(dev, from_talitos_desc_ptr(&edesc->desc, 6),
DMA_FROM_DEVICE);
unmap_single_talitos_ptr(dev, civ_ptr, DMA_TO_DEVICE);
@@ -179,7 +179,7 @@ static void ipsec_esp_decrypt_hwauth_done(struct device *dev,
ipsec_esp_unmap(dev, edesc, req, false);
/* check ICV auth status */
- if (!err && ((desc->hdr_lo & DESC_HDR_LO_ICCR1_MASK) !=
+ if (!err && ((from_talitos_desc_hdr_lo(desc) & DESC_HDR_LO_ICCR1_MASK) !=
DESC_HDR_LO_ICCR1_PASS))
err = -EBADMSG;
@@ -208,13 +208,13 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
int sg_count, ret;
int elen = 0;
bool sync_needed = false;
- bool is_ipsec_esp = desc->hdr & DESC_HDR_TYPE_IPSEC_ESP;
- struct talitos_ptr *civ_ptr = &desc->ptr[is_ipsec_esp ? 2 : 3];
- struct talitos_ptr *ckey_ptr = &desc->ptr[is_ipsec_esp ? 3 : 2];
+ bool is_ipsec_esp = from_talitos_desc_hdr(desc) & DESC_HDR_TYPE_IPSEC_ESP;
+ struct talitos_ptr *civ_ptr = from_talitos_desc_ptr(desc, is_ipsec_esp ? 2 : 3);
+ struct talitos_ptr *ckey_ptr = from_talitos_desc_ptr(desc, is_ipsec_esp ? 3 : 2);
dma_addr_t dma_icv = edesc->dma_link_tbl + edesc->dma_len - authsize;
/* hmac key */
- to_talitos_ptr(&desc->ptr[0], ctx->dma_key, ctx->authkeylen);
+ to_talitos_ptr(from_talitos_desc_ptr(desc, 0), ctx->dma_key, ctx->authkeylen);
sg_count = edesc->src_nents ?: 1;
if (is_sec1() && sg_count > 1)
@@ -227,7 +227,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
/* hmac data */
ret = talitos_sg_map(dev, areq->src, areq->assoclen, edesc,
- &desc->ptr[1], sg_count, 0, tbl_off);
+ from_talitos_desc_ptr(desc, 1), sg_count, 0, tbl_off);
if (ret > 1) {
tbl_off += ret;
@@ -247,10 +247,10 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
* extent is bytes of HMAC postpended to ciphertext,
* typically 12 for ipsec
*/
- if (is_ipsec_esp && (desc->hdr & DESC_HDR_MODE1_MDEU_CICV))
+ if (is_ipsec_esp && (from_talitos_desc_hdr(desc) & DESC_HDR_MODE1_MDEU_CICV))
elen = authsize;
- ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4],
+ ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, from_talitos_desc_ptr(desc, 4),
sg_count, areq->assoclen, tbl_off, elen,
false, 1);
@@ -270,7 +270,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
elen = authsize;
else
elen = 0;
- ret = talitos_sg_map_ext(dev, areq->dst, cryptlen, edesc, &desc->ptr[5],
+ ret = talitos_sg_map_ext(dev, areq->dst, cryptlen, edesc, from_talitos_desc_ptr(desc, 5),
sg_count, areq->assoclen, tbl_off, elen,
is_ipsec_esp && !encrypt, 1);
tbl_off += ret;
@@ -284,19 +284,19 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
/* icv data follows link tables */
to_talitos_ptr(tbl_ptr, dma_icv, authsize);
- to_talitos_ptr_ext_or(&desc->ptr[5], authsize);
+ to_talitos_ptr_ext_or(from_talitos_desc_ptr(desc, 5), authsize);
sync_needed = true;
} else if (!encrypt) {
- to_talitos_ptr(&desc->ptr[6], dma_icv, authsize);
+ to_talitos_ptr(from_talitos_desc_ptr(desc, 6), dma_icv, authsize);
sync_needed = true;
} else if (!is_ipsec_esp) {
- talitos_sg_map(dev, areq->dst, authsize, edesc, &desc->ptr[6],
+ talitos_sg_map(dev, areq->dst, authsize, edesc, from_talitos_desc_ptr(desc, 6),
sg_count, areq->assoclen + cryptlen, tbl_off);
}
/* iv out */
if (is_ipsec_esp)
- map_single_talitos_ptr(dev, &desc->ptr[6], ivsize, ctx->iv,
+ map_single_talitos_ptr(dev, from_talitos_desc_ptr(desc, 6), ivsize, ctx->iv,
DMA_FROM_DEVICE);
if (sync_needed)
@@ -339,7 +339,7 @@ static int aead_encrypt(struct aead_request *req)
return PTR_ERR(edesc);
/* set encrypt */
- edesc->desc.hdr = ctx->desc_hdr_template | DESC_HDR_MODE0_ENCRYPT;
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template | DESC_HDR_MODE0_ENCRYPT);
return ipsec_esp(edesc, req, true, ipsec_esp_encrypt_done);
}
@@ -358,15 +358,15 @@ static int aead_decrypt(struct aead_request *req)
if (IS_ERR(edesc))
return PTR_ERR(edesc);
- if ((edesc->desc.hdr & DESC_HDR_TYPE_IPSEC_ESP) &&
+ if ((from_talitos_desc_hdr(&edesc->desc) & DESC_HDR_TYPE_IPSEC_ESP) &&
(priv->features & TALITOS_FTR_HW_AUTH_CHECK) &&
((!edesc->src_nents && !edesc->dst_nents) ||
priv->features & TALITOS_FTR_SRC_LINK_TBL_LEN_INCLUDES_EXTENT)) {
/* decrypt and check the ICV */
- edesc->desc.hdr = ctx->desc_hdr_template |
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template |
DESC_HDR_DIR_INBOUND |
- DESC_HDR_MODE1_MDEU_CICV;
+ DESC_HDR_MODE1_MDEU_CICV);
/* reset integrity check result bits */
@@ -375,7 +375,7 @@ static int aead_decrypt(struct aead_request *req)
}
/* Have to check the ICV with software */
- edesc->desc.hdr = ctx->desc_hdr_template | DESC_HDR_DIR_INBOUND;
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template | DESC_HDR_DIR_INBOUND);
/* stash incoming ICV for later cmp with ICV generated by the h/w */
icvdata = edesc->buf + edesc->dma_len;
diff --git a/drivers/crypto/talitos/talitos-hash.c b/drivers/crypto/talitos/talitos-hash.c
index 8778a2ab812d..7682e1058e7e 100644
--- a/drivers/crypto/talitos/talitos-hash.c
+++ b/drivers/crypto/talitos/talitos-hash.c
@@ -43,7 +43,7 @@ static void common_nonsnoop_hash_unmap(struct device *dev,
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
struct talitos_desc *desc = &edesc->desc;
- unmap_single_talitos_ptr(dev, &desc->ptr[5], DMA_FROM_DEVICE);
+ unmap_single_talitos_ptr(dev, from_talitos_desc_ptr(desc, 5), DMA_FROM_DEVICE);
if (edesc->last && req_ctx->last_request)
memcpy(areq->result, req_ctx->hw_context,
@@ -53,8 +53,8 @@ static void common_nonsnoop_hash_unmap(struct device *dev,
talitos_sg_unmap(dev, edesc, edesc->src, NULL, 0, 0);
/* When using hashctx-in, must unmap it. */
- if (from_talitos_ptr_len(&desc->ptr[1]))
- unmap_single_talitos_ptr(dev, &desc->ptr[1],
+ if (from_talitos_ptr_len(from_talitos_desc_ptr(desc, 1)))
+ unmap_single_talitos_ptr(dev, from_talitos_desc_ptr(desc, 1),
DMA_TO_DEVICE);
if (edesc->dma_len)
@@ -129,7 +129,7 @@ static void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
};
pr_err_once("Bug in SEC1, padding ourself\n");
- edesc->desc.hdr &= ~DESC_HDR_MODE0_MDEU_PAD;
+ and_talitos_desc_hdr(&edesc->desc, ~DESC_HDR_MODE0_MDEU_PAD);
map_single_talitos_ptr(ctx->dev, ptr, sizeof(padded_hash),
(char *)padded_hash, DMA_TO_DEVICE);
}
@@ -150,7 +150,7 @@ static void common_nonsnoop_hash(struct talitos_edesc *edesc,
/* hash context in */
if (!edesc->first || !req_ctx->first_request || req_ctx->swinit) {
- map_single_talitos_ptr_nosync(dev, &desc->ptr[1],
+ map_single_talitos_ptr_nosync(dev, from_talitos_desc_ptr(desc, 1),
req_ctx->hw_context_size,
req_ctx->hw_context,
DMA_TO_DEVICE);
@@ -161,7 +161,7 @@ static void common_nonsnoop_hash(struct talitos_edesc *edesc,
/* HMAC key */
if (ctx->keylen)
- to_talitos_ptr(&desc->ptr[2], ctx->dma_key, ctx->keylen);
+ to_talitos_ptr(from_talitos_desc_ptr(desc, 2), ctx->dma_key, ctx->keylen);
sg_count = edesc->src_nents ?: 1;
if (is_sec1() && sg_count > 1)
@@ -172,7 +172,7 @@ static void common_nonsnoop_hash(struct talitos_edesc *edesc,
/*
* data in
*/
- sg_count = talitos_sg_map(dev, edesc->src, length, edesc, &desc->ptr[3],
+ sg_count = talitos_sg_map(dev, edesc->src, length, edesc, from_talitos_desc_ptr(desc, 3),
sg_count, 0, 0);
if (sg_count > 1)
sync_needed = true;
@@ -181,19 +181,19 @@ static void common_nonsnoop_hash(struct talitos_edesc *edesc,
/* hash/HMAC out -or- hash context out */
if (edesc->last && req_ctx->last_request)
- map_single_talitos_ptr(dev, &desc->ptr[5],
+ map_single_talitos_ptr(dev, from_talitos_desc_ptr(desc, 5),
crypto_ahash_digestsize(tfm),
req_ctx->hw_context, DMA_FROM_DEVICE);
else
- map_single_talitos_ptr_nosync(dev, &desc->ptr[5],
+ map_single_talitos_ptr_nosync(dev, from_talitos_desc_ptr(desc, 5),
req_ctx->hw_context_size,
req_ctx->hw_context,
DMA_FROM_DEVICE);
/* last DWORD empty */
- if (is_sec1() && from_talitos_ptr_len(&desc->ptr[3]) == 0)
- talitos_handle_buggy_hash(ctx, edesc, &desc->ptr[3]);
+ if (is_sec1() && from_talitos_ptr_len(from_talitos_desc_ptr(desc, 3)) == 0)
+ talitos_handle_buggy_hash(ctx, edesc, from_talitos_desc_ptr(desc, 3));
if (sync_needed)
dma_sync_single_for_device(dev, edesc->dma_link_tbl,
@@ -240,19 +240,19 @@ ahash_process_req_prepare(struct ahash_request *areq, unsigned int nbytes,
}
edesc->src = scatterwalk_ffwd(edesc->bufsl, areq->src, offset);
- edesc->desc.hdr = ctx->desc_hdr_template;
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template);
edesc->first = offset == 0;
edesc->last = nbytes - to_hash_this_desc == 0;
/* On last one, request SEC to pad; otherwise continue */
if (req_ctx->last_request && edesc->last)
- edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_PAD;
+ or_talitos_desc_hdr(&edesc->desc, DESC_HDR_MODE0_MDEU_PAD);
else
- edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_CONT;
+ or_talitos_desc_hdr(&edesc->desc, DESC_HDR_MODE0_MDEU_CONT);
/* request SEC to INIT hash. */
if (req_ctx->first_request && edesc->first && !req_ctx->swinit)
- edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_INIT;
+ or_talitos_desc_hdr(&edesc->desc, DESC_HDR_MODE0_MDEU_INIT);
/*
* When the tfm context has a keylen, it's an HMAC.
@@ -260,11 +260,11 @@ ahash_process_req_prepare(struct ahash_request *areq, unsigned int nbytes,
*/
if (ctx->keylen && ((req_ctx->first_request && edesc->first) ||
(req_ctx->last_request && edesc->last)))
- edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_HMAC;
+ or_talitos_desc_hdr(&edesc->desc, DESC_HDR_MODE0_MDEU_HMAC);
/* clear the DN bit */
if (is_sec1() && !edesc->last)
- edesc->desc.hdr &= ~DESC_HDR_DONE_NOTIFY;
+ and_talitos_desc_hdr(&edesc->desc, ~DESC_HDR_DONE_NOTIFY);
common_nonsnoop_hash(edesc, areq, to_hash_this_desc);
diff --git a/drivers/crypto/talitos/talitos-skcipher.c b/drivers/crypto/talitos/talitos-skcipher.c
index 2c34e2ffbf7e..79317fb7f47e 100644
--- a/drivers/crypto/talitos/talitos-skcipher.c
+++ b/drivers/crypto/talitos/talitos-skcipher.c
@@ -15,10 +15,10 @@ static void common_nonsnoop_unmap(struct device *dev,
struct talitos_edesc *edesc,
struct skcipher_request *areq)
{
- unmap_single_talitos_ptr(dev, &edesc->desc.ptr[5], DMA_FROM_DEVICE);
+ unmap_single_talitos_ptr(dev, from_talitos_desc_ptr(&edesc->desc, 5), DMA_FROM_DEVICE);
talitos_sg_unmap(dev, edesc, areq->src, areq->dst, areq->cryptlen, 0);
- unmap_single_talitos_ptr(dev, &edesc->desc.ptr[1], DMA_TO_DEVICE);
+ unmap_single_talitos_ptr(dev, from_talitos_desc_ptr(&edesc->desc, 1), DMA_TO_DEVICE);
if (edesc->dma_len)
dma_unmap_single(dev, edesc->dma_link_tbl, edesc->dma_len,
@@ -59,16 +59,18 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
unsigned int ivsize = crypto_skcipher_ivsize(cipher);
int sg_count, ret;
bool sync_needed = false;
- bool is_ctr = (desc->hdr & DESC_HDR_SEL0_MASK) == DESC_HDR_SEL0_AESU &&
- (desc->hdr & DESC_HDR_MODE0_AESU_MASK) == DESC_HDR_MODE0_AESU_CTR;
+ bool is_ctr = (from_talitos_desc_hdr(desc) & DESC_HDR_SEL0_MASK) ==
+ DESC_HDR_SEL0_AESU &&
+ (from_talitos_desc_hdr(desc) &
+ DESC_HDR_MODE0_AESU_MASK) == DESC_HDR_MODE0_AESU_CTR;
/* first DWORD empty */
/* cipher iv */
- to_talitos_ptr(&desc->ptr[1], edesc->iv_dma, ivsize);
+ to_talitos_ptr(from_talitos_desc_ptr(desc, 1), edesc->iv_dma, ivsize);
/* cipher key */
- to_talitos_ptr(&desc->ptr[2], ctx->dma_key, ctx->keylen);
+ to_talitos_ptr(from_talitos_desc_ptr(desc, 2), ctx->dma_key, ctx->keylen);
sg_count = edesc->src_nents ?: 1;
if (is_sec1() && sg_count > 1)
@@ -81,8 +83,9 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/*
* cipher in
*/
- sg_count = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[3],
- sg_count, 0, 0, 0, false, is_ctr ? 16 : 1);
+ sg_count = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc,
+ from_talitos_desc_ptr(desc, 3), sg_count,
+ 0, 0, 0, false, is_ctr ? 16 : 1);
if (sg_count > 1)
sync_needed = true;
@@ -93,13 +96,13 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
dma_map_sg(dev, areq->dst, sg_count, DMA_FROM_DEVICE);
}
- ret = talitos_sg_map(dev, areq->dst, cryptlen, edesc, &desc->ptr[4],
+ ret = talitos_sg_map(dev, areq->dst, cryptlen, edesc, from_talitos_desc_ptr(desc, 4),
sg_count, 0, (edesc->src_nents + 1));
if (ret > 1)
sync_needed = true;
/* iv out */
- map_single_talitos_ptr(dev, &desc->ptr[5], ivsize, ctx->iv,
+ map_single_talitos_ptr(dev, from_talitos_desc_ptr(desc, 5), ivsize, ctx->iv,
DMA_FROM_DEVICE);
/* last DWORD empty */
@@ -189,7 +192,7 @@ static int skcipher_encrypt(struct skcipher_request *areq)
return PTR_ERR(edesc);
/* set encrypt */
- edesc->desc.hdr = ctx->desc_hdr_template | DESC_HDR_MODE0_ENCRYPT;
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template | DESC_HDR_MODE0_ENCRYPT);
return common_nonsnoop(edesc, areq, skcipher_done);
}
@@ -213,7 +216,7 @@ static int skcipher_decrypt(struct skcipher_request *areq)
if (IS_ERR(edesc))
return PTR_ERR(edesc);
- edesc->desc.hdr = ctx->desc_hdr_template | DESC_HDR_DIR_INBOUND;
+ to_talitos_desc_hdr(&edesc->desc, ctx->desc_hdr_template | DESC_HDR_DIR_INBOUND);
return common_nonsnoop(edesc, areq, skcipher_done);
}
diff --git a/drivers/crypto/talitos/talitos.c b/drivers/crypto/talitos/talitos.c
index 8ea26422f449..1221eb9497fb 100644
--- a/drivers/crypto/talitos/talitos.c
+++ b/drivers/crypto/talitos/talitos.c
@@ -165,9 +165,7 @@ static void dma_map_request(struct device *dev, struct talitos_request *request,
if (is_sec1()) {
while (edesc) {
- edesc->desc.hdr1 = edesc->desc.hdr;
-
- dma_desc = dma_map_single(dev, &edesc->desc.hdr1,
+ dma_desc = dma_map_single(dev, &edesc->desc.sec1.hdr,
TALITOS_DESC_SIZE,
DMA_BIDIRECTIONAL);
@@ -178,7 +176,7 @@ static void dma_map_request(struct device *dev, struct talitos_request *request,
/* Chain in any previous descriptors. */
- prev_edesc->desc.next_desc = cpu_to_be32(dma_desc);
+ prev_edesc->desc.sec1.next_desc = cpu_to_be32(dma_desc);
dma_sync_single_for_device(dev, prev_dma_desc,
TALITOS_DESC_SIZE,
@@ -262,20 +260,20 @@ static __be32 get_request_hdr(struct device *dev,
dma_sync_single_for_cpu(dev, request->dma_desc,
TALITOS_DESC_SIZE, DMA_BIDIRECTIONAL);
- return request->desc->hdr;
+ return request->desc->sec2.hdr;
}
edesc = container_of(request->desc, struct talitos_edesc, desc);
dma_desc = request->dma_desc;
while (edesc->next_desc) {
- dma_desc = be32_to_cpu(edesc->desc.next_desc);
+ dma_desc = be32_to_cpu(edesc->desc.sec1.next_desc);
edesc = edesc->next_desc;
}
dma_sync_single_for_cpu(dev, dma_desc, TALITOS_DESC_SIZE,
DMA_BIDIRECTIONAL);
- return edesc->desc.hdr1;
+ return edesc->desc.sec1.hdr;
}
static void dma_unmap_request(struct device *dev,
@@ -289,7 +287,7 @@ static void dma_unmap_request(struct device *dev,
edesc = container_of(request->desc, struct talitos_edesc, desc);
while (edesc->next_desc) {
dma_unmap_single(dev,
- be32_to_cpu(edesc->desc.next_desc),
+ be32_to_cpu(edesc->desc.sec1.next_desc),
TALITOS_DESC_SIZE, DMA_BIDIRECTIONAL);
edesc = edesc->next_desc;
}
@@ -424,12 +422,12 @@ static __be32 search_desc_hdr_in_request(struct talitos_request *request,
struct talitos_edesc *edesc;
if (request->dma_desc == cur_desc) {
- return request->desc->hdr;
+ return from_talitos_desc_hdr(request->desc);
} else if (is_sec1()) {
edesc = container_of(request->desc, struct talitos_edesc, desc);
while (edesc->next_desc) {
- if (edesc->desc.next_desc == cpu_to_be32(cur_desc))
- return edesc->next_desc->desc.hdr1;
+ if (edesc->desc.sec1.next_desc == cpu_to_be32(cur_desc))
+ return edesc->next_desc->desc.sec1.hdr;
edesc = edesc->next_desc;
}
}
diff --git a/drivers/crypto/talitos/talitos.h b/drivers/crypto/talitos/talitos.h
index 9bbdd409da5a..2e2414ad1e03 100644
--- a/drivers/crypto/talitos/talitos.h
+++ b/drivers/crypto/talitos/talitos.h
@@ -36,33 +36,49 @@
#define TALITOS_MAX_IV_LENGTH 16 /* max of AES_BLOCK_SIZE, DES3_EDE_BLOCK_SIZE */
/* descriptor pointer entry */
+
+struct sec1_talitos_ptr {
+ __be16 res;
+ __be16 len;
+ __be32 ptr;
+} __packed;
+
+struct sec2_talitos_ptr {
+ __be16 len;
+ u8 j_extent;
+ u8 eptr;
+ __be32 ptr;
+} __packed;
+
struct talitos_ptr {
union {
- struct { /* SEC2 format */
- __be16 len; /* length */
- u8 j_extent; /* jump to sg link table and/or extent*/
- u8 eptr; /* extended address */
- };
- struct { /* SEC1 format */
- __be16 res;
- __be16 len1; /* length */
- };
+ struct sec1_talitos_ptr sec1;
+ struct sec2_talitos_ptr sec2;
};
- __be32 ptr; /* address */
};
-/* descriptor */
+/* descriptor format */
+
+struct sec1_talitos_desc {
+ __be32 hdr;
+ struct sec1_talitos_ptr ptr[7];
+ __be32 next_desc;
+} __packed;
+
+struct sec2_talitos_desc {
+ __be32 hdr;
+ __be32 hdr_lo;
+ struct sec2_talitos_ptr ptr[7];
+} __packed;
+
struct talitos_desc {
- __be32 hdr; /* header high bits */
union {
- __be32 hdr_lo; /* header low bits */
- __be32 hdr1; /* header for SEC1 */
+ struct sec1_talitos_desc sec1;
+ struct sec2_talitos_desc sec2;
};
- struct talitos_ptr ptr[7]; /* ptr/len pair array */
- __be32 next_desc; /* next descriptor (SEC1) */
};
-#define TALITOS_DESC_SIZE (sizeof(struct talitos_desc) - sizeof(__be32))
+#define TALITOS_DESC_SIZE (sizeof(struct talitos_desc))
/*
* talitos_edesc - s/w-extended descriptor
@@ -488,48 +504,101 @@ static inline void talitos_init_branch(bool sec1)
#define DESC_PTR_LNKTBL_RET 0x02
#define DESC_PTR_LNKTBL_NEXT 0x01
+static inline __be32 from_talitos_ptr(struct talitos_ptr *ptr)
+{
+ if (is_sec1())
+ return ptr->sec1.ptr;
+ return ptr->sec2.ptr;
+}
+
+static inline __be32 from_talitos_desc_hdr(struct talitos_desc *desc)
+{
+ if (is_sec1())
+ return desc->sec1.hdr;
+ return desc->sec2.hdr;
+}
+
+static inline void to_talitos_desc_hdr(struct talitos_desc *desc, __be32 val)
+{
+ if (is_sec1())
+ desc->sec1.hdr = val;
+ else
+ desc->sec2.hdr = val;
+}
+
+static inline void or_talitos_desc_hdr(struct talitos_desc *desc, __be32 val)
+{
+ if (is_sec1())
+ desc->sec1.hdr |= val;
+ else
+ desc->sec2.hdr |= val;
+}
+
+static inline void and_talitos_desc_hdr(struct talitos_desc *desc, __be32 val)
+{
+ if (is_sec1())
+ desc->sec1.hdr &= val;
+ else
+ desc->sec2.hdr &= val;
+}
+
+static inline __be32 from_talitos_desc_hdr_lo(struct talitos_desc *desc)
+{
+ return desc->sec2.hdr_lo;
+}
+
+static inline struct talitos_ptr *
+from_talitos_desc_ptr(struct talitos_desc *desc, int idx)
+{
+ if (is_sec1())
+ return (struct talitos_ptr *)&desc->sec1.ptr[idx];
+ return (struct talitos_ptr *)&desc->sec2.ptr[idx];
+}
+
static inline void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr,
unsigned int len)
{
- ptr->ptr = cpu_to_be32(lower_32_bits(dma_addr));
if (is_sec1()) {
- ptr->len1 = cpu_to_be16(len);
+ ptr->sec1.ptr = cpu_to_be32(lower_32_bits(dma_addr));
+ ptr->sec1.len = cpu_to_be16(len);
} else {
- ptr->len = cpu_to_be16(len);
- ptr->eptr = upper_32_bits(dma_addr);
+ ptr->sec2.ptr = cpu_to_be32(lower_32_bits(dma_addr));
+ ptr->sec2.len = cpu_to_be16(len);
+ ptr->sec2.eptr = upper_32_bits(dma_addr);
}
}
static inline void copy_talitos_ptr(struct talitos_ptr *dst_ptr,
struct talitos_ptr *src_ptr)
{
- dst_ptr->ptr = src_ptr->ptr;
if (is_sec1()) {
- dst_ptr->len1 = src_ptr->len1;
+ dst_ptr->sec1.ptr = src_ptr->sec1.ptr;
+ dst_ptr->sec1.len = src_ptr->sec1.len;
} else {
- dst_ptr->len = src_ptr->len;
- dst_ptr->eptr = src_ptr->eptr;
+ dst_ptr->sec2.ptr = src_ptr->sec2.ptr;
+ dst_ptr->sec2.len = src_ptr->sec2.len;
+ dst_ptr->sec2.eptr = src_ptr->sec2.eptr;
}
}
static inline unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr)
{
if (is_sec1())
- return be16_to_cpu(ptr->len1);
+ return be16_to_cpu(ptr->sec1.len);
else
- return be16_to_cpu(ptr->len);
+ return be16_to_cpu(ptr->sec2.len);
}
static inline void to_talitos_ptr_ext_set(struct talitos_ptr *ptr, u8 val)
{
if (!is_sec1())
- ptr->j_extent = val;
+ ptr->sec2.j_extent = val;
}
static inline void to_talitos_ptr_ext_or(struct talitos_ptr *ptr, u8 val)
{
if (!is_sec1())
- ptr->j_extent |= val;
+ ptr->sec2.j_extent |= val;
}
/*
@@ -569,8 +638,8 @@ static inline void unmap_single_talitos_ptr(struct device *dev,
struct talitos_ptr *ptr,
enum dma_data_direction dir)
{
- dma_unmap_single(dev, be32_to_cpu(ptr->ptr), from_talitos_ptr_len(ptr),
- dir);
+ dma_unmap_single(dev, be32_to_cpu(from_talitos_ptr(ptr)),
+ from_talitos_ptr_len(ptr), dir);
}
int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox