[0/3] Add crypto nodes for J7200 and AM64x

Message

Suman Anna May 14, 2021, 9:07 p.m. UTC

Hi Nishanth,

The following series adds the crypto nodes including the underlying
rng nodes for J7200 and AM64x SoCs. Patches are on top of 5.13-rc1.

Note that AM64x supports only a limited number of algos compared to
the other K3 SoCs. The AM64x driver support accounting for this is
merged in v5.13-rc1. Also, the IP appears at the same address on
J7200 and AM64x but is in different domains.

I have verified the basic crypto self-tests, extra-tests and some
basic tcrypt tests on both J7200 EVM and AM64x EVM boards.

regards
Suman

Peter Ujfalusi (2):
  arm64: dts: ti: k3-j7200-mcu: Add the mcu sa2ul crypto node
  arm64: dts: ti: k3-am64-main: Enable crypto accelerator

Suman Anna (1):
  arm64: dts: ti: k3-am64: Add SA2UL address space to Main CBASS ranges

 arch/arm64/boot/dts/ti/k3-am64-main.dtsi      | 19 ++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am64.dtsi           |  1 +
 .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi      | 20 +++++++++++++++++++
 3 files changed, 40 insertions(+)

Comments

Nishanth Menon May 14, 2021, 10:11 p.m. UTC | #1

On 16:07-20210514, Suman Anna wrote:
> The following series adds the crypto nodes including the underlying
> rng nodes for J7200 and AM64x SoCs. Patches are on top of 5.13-rc1.
> 
> Note that AM64x supports only a limited number of algos compared to
> the other K3 SoCs. The AM64x driver support accounting for this is
> merged in v5.13-rc1. Also, the IP appears at the same address on
> J7200 and AM64x but is in different domains.
> 
> I have verified the basic crypto self-tests, extra-tests and some
> basic tcrypt tests on both J7200 EVM and AM64x EVM boards.
> 

Thanks..

While this is an appropriate description for a subset of hardware,
this maybe missing the pieces needed for certain "high security"
(HS-*) device variants. Public channels, shared data flows and lack of
full control on RNG (we can read RNG, but not seed it) come to mind
immediately and further, I am not completely sure I understand how
this plays well with DKEK with OPTEE.

I know that u-boot does have capability to disable some of these, but:
a) TF-A can definitely boot to linux kernel without the need for u-boot.
b) We still need to be able to leverage h/w acceleration support that
   the high security devices is already capable of.

As a result, I am not entirely sure what we can do with this series
without breaking existing "high-security" devices (which can boot mainline
linux today with TF-A).