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 at walle.cc>
---
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[+ 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 at 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