Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support of power management for stm32 SAES peripheral #6778

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

tbourgoi
Copy link
Contributor

@tbourgoi tbourgoi commented Apr 3, 2024

This PR adds support of power management in stm32 SAES driver.
We also properly manage the dependency between SAES and RNG.

core/drivers/crypto/stm32/stm32_saes.c Show resolved Hide resolved
@@ -1435,7 +1436,7 @@ static TEE_Result stm32_saes_probe(const void *fdt, int node,
if (res)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If SAES probe function is deferred, stm32_saes_parse_fdt() fills saes_pdata.base and the next call of stm32_saes_probe() will panic on the assertion. Before this change, stm32_saes_parse_fdt() used to first get the deferreable resources before getting SAES IOMEM base address. Please preserve this order.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, I think we can remove the assert.
It was to protect if we try to probe 2 instances of SAES but OP-TEE does not support several AES accelerator.
So It will fail during the register in crypto framework

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of removing an assertion that serves a purpose, I suggest you modify your commit "drivers: crypto: stm32_saes: SAES depends on RNG clock":

@@ -1364,10 +1365,14 @@ static TEE_Result stm32_saes_parse_fdt(struct stm32_saes_platdata *pdata,
 	    dt_saes.reg_size == DT_INFO_INVALID_REG_SIZE)
 		return TEE_ERROR_BAD_PARAMETERS;
 
-	res = clk_dt_get_by_index(fdt, node, 0, &pdata->clk);
+	res = clk_dt_get_by_name(fdt, node, "bus", &pdata->clk);
 	if (res != TEE_SUCCESS)
 		return res;
 
+	return clk_dt_get_by_name(fdt, node, "rng", &pdata->clk_rng);
+	if (res != TEE_SUCCESS)
+		return res;
+
 	res = rstctrl_dt_get_by_index(fdt, node, 0, &pdata->reset);
 	if (res != TEE_SUCCESS && res != TEE_ERROR_ITEM_NOT_FOUND)
 		return res;

@@ -249,6 +249,14 @@ $(call force,CFG_STM32_I2C,y)
$(call force,CFG_STM32_GPIO,y)
endif

#SAES and CRYP cannot be register at the same time in the crypto framework
#If CRYP and SAES are enable on STMP32MP13, disable CRYP for safety purpose
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a space char after # character and a . char at sentences end.
s/register/registered/
A would reword safety into consistency.

A last word, regarding this issue, can we let the DT define which of CRYP or SAES driver is to be probed, allowing both config to be enabled but panicking at OP-TEE initialization time if both are registered?
Note that build reveal an issue related to that:

core/drivers/crypto/stm32/cipher.c:96:1: error: function 'cryp_copy_state' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]

This is due to the assert(IS_ENABLED(CFG_STM32_CRYP)) instruction in cryp_copy_state().
`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea to compile both drivers and let the DT choose.
Today the device tree in built in OP-TEE, so you know which peripheral will be enabled or not.
You are building OP-TEE for a dedicated device tree (not a list of device tree)

The user may try to enables CRYP and SAES and this will result in a crash of the plateform. The sooner the error the better I think.

SAES is DPA resistant (CRYP is not) that's why we enable it in OP-TEE for MP13.
Moreover, SAES is mandatory to use access the HUK of the SoC. Using CRYP instead of SAES would mean no HUK services in OP-TEE which reduce the feature set of OP-TEE.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get your point despite I think one day, we'd like to have OP-TEE's DTB provided at boot time, not built-in. I agree we can address that later.

Here i strongly suggest to report a error instead of overriding a config value (line 256), as you said, the sooner the error is reported, the better it is. Something like:

ifeq ($(call cfg-all-enabled,CFG_STM32MP13 CFG_STM32_CRYP CFG_STM32_SAES),y)
$(error Cannot embed both SAES and CRYP in STM32MP13)
endif

patrickdelaunay and others added 7 commits April 19, 2024 15:04
Add power management support to the SAES driver through suspend/resume
callbacks.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
Adds missing RNG clock resource in SAES and PKA nodes in stm32mp13
SoC DTSI files.

Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com>
Fixes missing dependency of SAES device on RNG clock.

Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com>
Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
override value of CFG_STM32_CRYP to n when CFG_STM32_SAES=y.
OP-TEE crypto framework can only register one AES accelerator.
If CRYP and SAES are probed, OP-TEE will panic.

Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
…MP13.

fix typos

Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
remove rng clock, introduce in next commit

Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
add rng clock

Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
An assert was used to ensure we only probe one instance of SAES.
It can create an error if the probe is deferred.
Remove assert as it can create an error and the probe will fail when
registering in the crypto framework.

Fixes: 4320f5c ("crypto: stm32: SAES cipher support")
Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
@@ -249,6 +249,14 @@ $(call force,CFG_STM32_I2C,y)
$(call force,CFG_STM32_GPIO,y)
endif

#SAES and CRYP cannot be register at the same time in the crypto framework
#If CRYP and SAES are enable on STMP32MP13, disable CRYP for safety purpose
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get your point despite I think one day, we'd like to have OP-TEE's DTB provided at boot time, not built-in. I agree we can address that later.

Here i strongly suggest to report a error instead of overriding a config value (line 256), as you said, the sooner the error is reported, the better it is. Something like:

ifeq ($(call cfg-all-enabled,CFG_STM32MP13 CFG_STM32_CRYP CFG_STM32_SAES),y)
$(error Cannot embed both SAES and CRYP in STM32MP13)
endif

@@ -1435,7 +1436,7 @@ static TEE_Result stm32_saes_probe(const void *fdt, int node,
if (res)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of removing an assertion that serves a purpose, I suggest you modify your commit "drivers: crypto: stm32_saes: SAES depends on RNG clock":

@@ -1364,10 +1365,14 @@ static TEE_Result stm32_saes_parse_fdt(struct stm32_saes_platdata *pdata,
 	    dt_saes.reg_size == DT_INFO_INVALID_REG_SIZE)
 		return TEE_ERROR_BAD_PARAMETERS;
 
-	res = clk_dt_get_by_index(fdt, node, 0, &pdata->clk);
+	res = clk_dt_get_by_name(fdt, node, "bus", &pdata->clk);
 	if (res != TEE_SUCCESS)
 		return res;
 
+	return clk_dt_get_by_name(fdt, node, "rng", &pdata->clk_rng);
+	if (res != TEE_SUCCESS)
+		return res;
+
 	res = rstctrl_dt_get_by_index(fdt, node, 0, &pdata->reset);
 	if (res != TEE_SUCCESS && res != TEE_ERROR_ITEM_NOT_FOUND)
 		return res;


return TEE_SUCCESS;
default:
break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpicking: could move the return TEE_ERROR_NOT_IMPLEMENTED instruction here. Simpler, better IMHO.

# If CRYP and SAES are enable on STMP32MP13, disable CRYP for safety purpose
ifeq ($(CFG_STM32MP13),y)
ifeq ($(call cfg-all-enabled, CFG_STM32_CRYP CFG_STM32_SAES), y)
override CFG_STM32_CRYP := n
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my comment at #6778 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants