[PATCH] armv8: layerscape: don't remove crypto node on LS1028A
At least on the LS1028A the crypto module is always there, but has some functions disabled on non-E parts. Thus it doesn't make sense to completely remove the node. Linux will figure out what is there and what is not.
Please note, this patch is certainly not ideal. But I don't know which processors have the SEC module always available. NXP would have to comment on that and make sure, the condition when to remove the crypto node is correct.
Signed-off-by: Michael Walle michael@walle.cc --- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index 9c1e0c76f3..72c9fc8bb7 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -443,7 +443,7 @@ void ft_cpu_setup(void *blob, bd_t *bd) unsigned int svr = gur_in32(&gur->svr);
/* delete crypto node if not on an E-processor */ - if (!IS_E_PROCESSOR(svr)) + if (!IS_ENABLED(CONFIG_ARCH_LS1028A) && !IS_E_PROCESSOR(svr)) fdt_fixup_crypto_node(blob, 0); #if CONFIG_SYS_FSL_SEC_COMPAT >= 4 else {
[+ Horia]
Am 2020-06-02 17:09, schrieb Michael Walle:
At least on the LS1028A the crypto module is always there, but has some functions disabled on non-E parts. Thus it doesn't make sense to completely remove the node. Linux will figure out what is there and what is not.
Please note, this patch is certainly not ideal. But I don't know which processors have the SEC module always available. NXP would have to comment on that and make sure, the condition when to remove the crypto node is correct.
Signed-off-by: Michael Walle michael@walle.cc
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index 9c1e0c76f3..72c9fc8bb7 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -443,7 +443,7 @@ void ft_cpu_setup(void *blob, bd_t *bd) unsigned int svr = gur_in32(&gur->svr);
/* delete crypto node if not on an E-processor */
- if (!IS_E_PROCESSOR(svr))
- if (!IS_ENABLED(CONFIG_ARCH_LS1028A) && !IS_E_PROCESSOR(svr)) fdt_fixup_crypto_node(blob, 0);
#if CONFIG_SYS_FSL_SEC_COMPAT >= 4 else {
On 6/3/2020 11:09 PM, Michael Walle wrote:
[+ Horia]
Am 2020-06-02 17:09, schrieb Michael Walle:
At least on the LS1028A the crypto module is always there, but has some functions disabled on non-E parts. Thus it doesn't make sense to completely remove the node. Linux will figure out what is there and what is not.
Please note, this patch is certainly not ideal. But I don't know which processors have the SEC module always available. NXP would have to comment on that and make sure, the condition when to remove the crypto node is correct.
Based on previous (NXP-internal) discussions, non-E crypto module is: -fully disabled on: LS1021A (ARMv7), LS1043A, LS1088A, LS2088A (and their personalities) -partially [*] disabled on: LS1012A, LS1028A, LS1046A, LX2160A (and their personalities)
I am not aware if this has been tested before or not and I don't have non-E boards at hand to test on, so let me first double check with IP design and SoC integration teams...
Going forward, it might be better to filter based on the list of SoCs with crypto module fully disabled, since in theory all upcoming SoCs will partially disable the crypto module.
[*] This means the following should still be working: -hashing (using MDHA - message digest hash accelerator) -random number generation (using RNG4) -cyclic redundancy checking (using CRCA) -runtime integrity checker (RTIC)
Horia
participants (2)
-
Horia Geantă -
Michael Walle