drivers: stm32_rng: MP15 RNG is non-secure when PRNG is enable

[etienne-lms]

Register stm32_rng device as non-secure when software PRNG is enabled instead of testing the firewall configuration that is applied from stm32mp1_init_final_shres() at driver_init_late initcall level, far after RNG initialization.

Fixes: d773ec0 ("drivers: stm32_rng: update clock and power management")

[GseoC]

To be functional before your fix, we indeed need #7066. So:
Acked-by: Gatien Chevallier <gatien.chevallier@foss.st.com>

I'll take care on rebasing my series afterwards as I suppose it'll be merged after the final tag.

[etienne-lms]

I mean once #7066 is merged, this fix will no more be needed since the ETZPC config for STM32 RNG will then be loaded before stm32_rng driver init. Since #7066 is not yet merged, we need this fix to ensure STM32 RNG is assigned to non-secure world and U-Boot can safely use it (as required with U-Boot tag v2024.10).

[etienne-lms]

Review tag applied.

@jforissier, would you be ok to consider this platform fix in the 4.4.0 release tag?
It fixes an issue seen with latest U-Boot tag v2024.10 on stm32mp15 boards regarding STM32 RNG subsystem (accessed by U-Boot since commit [1] makes U-Boot to generate an ASLR seed for the dear kernel).
Stm32mp1/OP-TEE release build is currently based on U-Boot v2024.01-rc1 [2] and does not strictly needs this fix but I would rather have the coming 4.4.0 tag to comply with the latest released U-Boot tag for these platforms.

[1] https://source.denx.de/u-boot/u-boot/-/commit/ea955eea4f662b7e37d74228fed0c9147e6dba88
[2] https://github.com/OP-TEE/manifest/blob/refs/tags/4.3.0/stm32mp1.xml#L18

[jforissier]

@etienne-lms thanks for the detailed explanation. Yes this fix makes perfect sense to get into 4.4.0.

[etienne-lms]

Thanks.

[GseoC]

Thank you :)