drivers: crypto: hash driver for the STM32H7RS series

[FRASTM]

Following the #93923
this PR adds the support of crypto hash hardware to the stm32h7RS

Note that -T crypto.hash will use the SW hash

The testcase only tests the SHA256, more SHA are available on the stm32 hash hw processors and main could be extended

[FRASTM]

west build -p -b nucleo_h7s3l8 tests/crypto/crypto_hash/ with LOG

*** Booting Zephyr OS build v4.2.0-2020-g7ef0acdb1ed5 ***
Running TESTSUITE crypto_hash
===================================================================
START - test_hash
D: begin_session (algo=2)
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: HASH compute SHA256
D: Hash computation successful
D: Session freed
 PASS - test_hash in 0.038 seconds
===================================================================
TESTSUITE crypto_hash succeeded

------ TESTSUITE SUMMARY START ------

SUITE PASS - 100.00% [crypto_hash]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.038 seconds
 - PASS - [crypto_hash.test_hash] duration = 0.038 seconds

------ TESTSUITE SUMMARY END ------

===================================================================
PROJECT EXECUTION SUCCESSFUL

[etienne-lms]

LGTM aside some indentation issues to be addressed or not.

[FRASTM]

Requires one commit to fix regression after #94869 --> fix the CI error on build

west build -p -b nucleo_h7s3l8 samples/drivers/i2s/output -T sample.drivers.i2s.output
with something like ./include/zephyr/drivers/dma/dma_stm32.h
#define __LL_DMA_GET_CHANNEL_INSTANCE LL_DMA_GET_CHANNEL_INSTANCE
(put in another PR)

[FRASTM]

Requires #95470

[FRASTM]

rebase on f878a55

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[etienne-lms]

LGTM.
Some coding style minor issues worth to address but not blocking.

[etienne-lms]

nitpicking consistency: remove this empty line, as in hal_func_hash_SHA224_start().

[etienne-lms]

Indenattion

static inline HAL_StatusTypeDef hal_func_hash_SHA224_start(HASH_HandleTypeDef *hhash,
							   void *p_in_buffer,
							   uint32_t in_size_byte,
							   void *p_out_buffer)

Ditto for hal_func_hash_SHA256_start().

[etienne-lms]

Indentation

		status = hal_func_hash_SHA256_start(&data->hhash, pkt->in_buf, pkt->in_len,
						    pkt->out_buf);

[erwango]

From what I can see, this implementation (calling HAL_HASH_SetConfig()/HAL_HASH_Start() instead of HAL_HASHEx_SHA224_Start() is also common with other all recent STM32 series (H5,MP2,N6,U3,WBA).

In order to avoid updating driver code with || defined(CONFIG_SOC_SERIES_STM32FOO) for each new series, let's define a new Kconfig (CRYPTO_STM32_HASH_HAL_CFG_START for instance) that would be selected by these series when driver support is added. That would minimize effort to add new series and be better for code readability.
(I'm not proposing a new compatible, as I think this is not an issue of HW, but pure HAL implementation, but I could be wrong)

[FRASTM]

to be reconsidered later "on-demand"