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
