[PATCH v9 0/3] Add support for more AES modes in TI DTHEv2

T Pratham posted 3 patches 2 months ago
There is a newer version of this series
drivers/crypto/ti/Kconfig         |   4 +
drivers/crypto/ti/dthev2-aes.c    | 865 ++++++++++++++++++++++++++++--
drivers/crypto/ti/dthev2-common.c |  19 +
drivers/crypto/ti/dthev2-common.h |  27 +-
4 files changed, 883 insertions(+), 32 deletions(-)
[PATCH v9 0/3] Add support for more AES modes in TI DTHEv2
Posted by T Pratham 2 months ago
DTHEv2 is a new cryptography engine introduced in TI AM62L SoC. The
features of DTHEv2 and details of AES modes supported were detailed in
[1]. Additional hardware details available in SoC TRM [2].

This patch series adds support for the following AES modes:
 - AES-CTR
 - AES-GCM
 - AES-CCM

The driver is tested using full kernel crypto selftests
(CRYPTO_SELFTESTS_FULL) which all pass successfully [3].

Signed-off-by: T Pratham <t-pratham@ti.com>
---
[1]: [PATCH v7 0/2] Add support for Texas Instruments DTHEv2 Crypto Engine
Link: https://lore.kernel.org/all/20250820092710.3510788-1-t-pratham@ti.com/

[2]: Section 14.6.3 (DMA Control Registers -> DMASS_DTHE)
Link: https://www.ti.com/lit/ug/sprujb4/sprujb4.pdf

[3]: DTHEv2 AES Engine kernel self-tests logs
Link: https://gist.github.com/Pratham-T/aaa499cf50d20310cb27266a645bfd60

Change log:
v9:
 - Removed modifying scatterlist in AES-CTR. Replaced with allocating
   our own scatterlist for the same purpose to handle padding.
v8:
 - Removed scatterlist chaining from AES-CTR, along with accompanying
   helper functions added in v6. Replaced with sending only complete
   blocks to hardware and handling the last partial block in software.
v7:
 - Moved padding buffer to inside request ctx.
 - Removed already merged AES-XTS patch.
 - Moved dthe_copy_sg() helper from CTR patch to GCM patch, where it is
   being used for first time.
v6:
 - Removed memory alloc calls on the data path (CTR padding in aes_run),
   replaced with scatterlist chaining for added a pad buffer. Added two
   accompanying helpers dthe_chain_pad_sg() and
   dthe_unchain_padded_sg(). 
 - Replaced GFP_KERNEL to GFP_ATOMIC in AEAD src and dst scatterlist
   prep functions to avoid deadlock in data path.
 - Added fallback to software in AEADs on failure.
v5:
 - Simplified AES-XTS fallback allocation, directly using xts(aes) for
   alg_name
 - Changed fallback to sync and allocated on stack
v4:
 - Return -EINVAL in AES-XTS when cryptlen = 0
 - Added software fallback for AES-XTS when ciphertext stealing is
   required (cryptlen is not multiple of AES_BLOCK_SIZE)
 - Changed DTHE_MAX_KEYSIZE definition to use AES_MAX_KEY_SIZE instead
   of AES_KEYSIZE_256
 - In AES-CTR, also pad dst scatterlist when padding src scatterlist
 - Changed polling for TAG ready to use readl_relaxed_poll_timeout()
 - Used crypto API functions to access struct members instead of
   directly accessing them (crypto_aead_tfm and aead_request_flags)
 - Allocated padding buffers in AEAD algos on the stack.
 - Changed helper functions dthe_aead_prep_* to return ERR_PTR on error
 - Changed some error labels in dthe_aead_run to improve clarity
 - Moved iv_in[] declaration from middle of the function to the top
 - Corrected setting CCM M value in the hardware register
 - Added checks for CCM L value input in the algorithm from IV.
 - Added more fallback cases for CCM where hardware has limitations
v3:
 - Added header files to remove implicit declaration error.
 - Corrected assignment of src_nents and dst_nents in dthe_aead_run
 (Ran the lkp kernel test bot script locally to ensure no more such
 errors are present)
v2:
 - Corrected assignment of variable unpadded_cryptlen in dthe_aead_run.
 - Removed some if conditions which are always false, and documented the
   cases in comments.
 - Moved polling of TAG ready register to a separate function and
   returning -ETIMEDOUT on poll timeout.
 - Corrected comments to adhere to kernel coding guidelines.

Link to previous version:

v8: https://lore.kernel.org/all/20260120144408.606911-1-t-pratham@ti.com/
v7: https://lore.kernel.org/all/20251126112207.4033971-1-t-pratham@ti.com/
v6: https://lore.kernel.org/all/20251111112137.976121-1-t-pratham@ti.com/
v5: https://lore.kernel.org/all/20251022180302.729728-1-t-pratham@ti.com/
v4: https://lore.kernel.org/all/20251009111727.911738-1-t-pratham@ti.com/
v3: https://lore.kernel.org/all/20250910100742.3747614-1-t-pratham@ti.com/
v2: https://lore.kernel.org/all/20250908140928.2801062-1-t-pratham@ti.com/
v1: https://lore.kernel.org/all/20250905133504.2348972-4-t-pratham@ti.com/
---

T Pratham (3):
  crypto: ti - Add support for AES-CTR in DTHEv2 driver
  crypto: ti - Add support for AES-GCM in DTHEv2 driver
  crypto: ti - Add support for AES-CCM in DTHEv2 driver

 drivers/crypto/ti/Kconfig         |   4 +
 drivers/crypto/ti/dthev2-aes.c    | 865 ++++++++++++++++++++++++++++--
 drivers/crypto/ti/dthev2-common.c |  19 +
 drivers/crypto/ti/dthev2-common.h |  27 +-
 4 files changed, 883 insertions(+), 32 deletions(-)

-- 
2.34.1
Re: [PATCH v9 0/3] Add support for more AES modes in TI DTHEv2
Posted by T Pratham 1 month, 2 weeks ago
On 13/02/26 18:32, T Pratham wrote:
> DTHEv2 is a new cryptography engine introduced in TI AM62L SoC. The
> features of DTHEv2 and details of AES modes supported were detailed in
> [1]. Additional hardware details available in SoC TRM [2].
> 
> This patch series adds support for the following AES modes:
>  - AES-CTR
>  - AES-GCM
>  - AES-CCM
> 
> The driver is tested using full kernel crypto selftests
> (CRYPTO_SELFTESTS_FULL) which all pass successfully [3].
> 
> Signed-off-by: T Pratham <t-pratham@ti.com>
> ---
> [1]: [PATCH v7 0/2] Add support for Texas Instruments DTHEv2 Crypto Engine
> Link: https://lore.kernel.org/all/20250820092710.3510788-1-t-pratham@ti.com/
> 
> [2]: Section 14.6.3 (DMA Control Registers -> DMASS_DTHE)
> Link: https://www.ti.com/lit/ug/sprujb4/sprujb4.pdf
> 
> [3]: DTHEv2 AES Engine kernel self-tests logs
> Link: https://gist.github.com/Pratham-T/aaa499cf50d20310cb27266a645bfd60
> 
> Change log:
> v9:
>  - Removed modifying scatterlist in AES-CTR. Replaced with allocating
>    our own scatterlist for the same purpose to handle padding.

Please ignore this series. I found that I had used a function in the
first commit of this series in the above change in v9, but that function
was being defined in the second commit for the first time. Thus making
the series non-bisectable.

Sent an updated version here:
https://lore.kernel.org/all/20260226125441.3559664-1-t-pratham@ti.com/

-- 
Regards
T Pratham <t-pratham@ti.com>