Add crypto support to TI cc23x0 SoC

[jpanisbl]

This series adds crypto support to TI cc23x0 SoC.

Datasheet: https://www.ti.com/lit/ds/symlink/cc2340r5.pdf

[zephyrbot]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[valeriosetti]

The overall implementation looks good to me. I only left few suggestions for improvements (some of which are also optional)

[valeriosetti]

One last suggestion: it could be nice to extend zephyr/samples/drivers/crypto/ sample to add support for your driver (as done for example in #85036). This allows everybody using the same board that you are using to run this sample and validate the driver.

[valeriosetti]

Thanks for addressing my comments. LGTM :)

[ceolin]

I have only one concern about the semaphore usage across crypto operations because I don't know how the hw operates.

From the driver interface perspective it looks good.

[ceolin]

I am wondering if you shouldn't protect this call with the semaphore. What happens if another thread changes the key while there is an operation happening ?

[jpanisbl]

Thank you for your time Flavio.
You're right, that's something that must be addressed. That's also the case for the whole encrypt/decrypt operation (not only for the key).

[jpanisbl]

Also, I read more carefully the documentation about "mutexes VS semaphores". and it seems to me that I should replace the existing mutex (currently used to protect the session) with a semaphore. The mutex I'm using to protect the session may not do the trick, since it can be locked twice by the same thread. I will double-check with @valeriosetti .
IOW, there will probably be 2 semaphores: 1 for the session, and 1 for the access to HW (similarly to crypto_stm32.c).

[valeriosetti]

After some internal discussion we agreed to:

• remove the session semaphore/mutex. Rationale: we don´t care if multiple thread start multiple sessions; we only care not to use AES HW at the same time.
• change device_sem to be a mutex and set it to protect any access to the AES HW (mutex over semaphore in this case because mutexes are thread-aware).
• keep the aes_done of course for HW synchronization.

This is the same as crypto_si32.c and crypto_stm32.c.

[jpanisbl]

As a complement, using the sample that is part of this PR:

*** Booting Zephyr OS build 0e205aafcff5 ***
I: Cipher Sample
I: ECB Mode
D: AES operation completed
I: Output length (encryption): 16
I: ECB mode ENCRYPT - Match
E: ECB decryption not supported by the hardware
I: CBC Mode
E: Unsupported mode
I: CTR Mode
D: AES operation completed
D: AES operation completed
D: AES operation completed
D: AES operation completed
I: Output length (encryption): 64
I: CTR mode ENCRYPT - Match
D: AES operation completed
D: AES operation completed
D: AES operation completed
D: AES operation completed
I: Output length (decryption): 64
I: CTR mode DECRYPT - Match
I: CCM Mode
D: Compute CMAC
D: AES operation completed (block 0)
D: AES operation completed (block 1)
D: AES operation completed (data)
D: AES operation completed (data)
D: Encrypt data
D: AES operation completed
D: AES operation completed
D: Encrypt tag
D: AES operation completed
I: Output length (encryption): 23
I: CCM mode ENCRYPT - Match
D: Decrypt data
D: AES operation completed
D: AES operation completed
D: Compute CMAC
D: AES operation completed (block 0)
D: AES operation completed (block 1)
D: AES operation completed (data)
D: AES operation completed (data)
D: Encrypt tag
D: AES operation completed
D: Check tag
I: Output length (decryption): 23
I: CCM mode DECRYPT - Match
I: GCM Mode
E: Unsupported mode

[ceolin]

Thanks guys !