[2/2] arm64: dts: imx8mm: Add Crypto CAAM support
diff mbox series

Message ID 20191130225153.30111-2-aford173@gmail.com
State Changes Requested
Delegated to: Herbert Xu
Headers show
Series
  • [1/2] crypto: caam: Change the i.MX8MQ check support all i.MX8M variants
Related show

Commit Message

Adam Ford Nov. 30, 2019, 10:51 p.m. UTC
The i.MX8M Mini supports the same crypto engine as what is in
the i.MX8MQ, but it is not currently present in the device tree,
because it may be resricted by security features.

This patch places in into the device tree and marks it as disabled,
but anyone not restricting the CAAM with secure mode functions
can mark it as enabled.

Signed-off-by: Adam Ford <aford173@gmail.com>

Comments

Horia Geanta Dec. 9, 2019, 4:23 p.m. UTC | #1
On 12/1/2019 12:52 AM, Adam Ford wrote:
> The i.MX8M Mini supports the same crypto engine as what is in
> the i.MX8MQ, but it is not currently present in the device tree,
> because it may be resricted by security features.
> 
What exactly are you referring to?

> This patch places in into the device tree and marks it as disabled,
> but anyone not restricting the CAAM with secure mode functions
> can mark it as enabled.
> 
Even if - due to export control regulations - CAAM is "trimmed down",
it loses only the encryption capabilities (hashing etc. still working).

Again, please clarify what you mean by "secure mode functions",
"security features" etc.

Horia
Adam Ford Dec. 9, 2019, 4:47 p.m. UTC | #2
On Mon, Dec 9, 2019 at 10:23 AM Horia Geanta <horia.geanta@nxp.com> wrote:
>
> On 12/1/2019 12:52 AM, Adam Ford wrote:
> > The i.MX8M Mini supports the same crypto engine as what is in
> > the i.MX8MQ, but it is not currently present in the device tree,
> > because it may be resricted by security features.
> >
> What exactly are you referring to?

I don't know this hardware very well, but on a different platform, we
needed to make the crypto engines as disabled if they were being
accessed through secure operations which made it unavailable to Linux
without using some special barriers. I didn't have the special
hardware on the other platform that required it that way, so I can't
really explain it well.  I know on those special cases, because some
people were accessing these registers through other means, the devices
had to be marked as 'disabled' so to avoid breaking something.  Since
I wasn't sure if this was left out of the i.MX8M Mini on purpose, I
let this disabled just in case this hardware platform was also
affected in a similar and people wanting to use it could mark it as
'okay'

adam

>
> > This patch places in into the device tree and marks it as disabled,
> > but anyone not restricting the CAAM with secure mode functions
> > can mark it as enabled.
> >
> Even if - due to export control regulations - CAAM is "trimmed down",
> it loses only the encryption capabilities (hashing etc. still working).
>
> Again, please clarify what you mean by "secure mode functions",
> "security features" etc.
>
> Horia
Schrempf Frieder Dec. 11, 2019, 2:36 p.m. UTC | #3
Hi Adam,

On 09.12.19 17:47, Adam Ford wrote:
> On Mon, Dec 9, 2019 at 10:23 AM Horia Geanta <horia.geanta@nxp.com> wrote:
>>
>> On 12/1/2019 12:52 AM, Adam Ford wrote:
>>> The i.MX8M Mini supports the same crypto engine as what is in
>>> the i.MX8MQ, but it is not currently present in the device tree,
>>> because it may be resricted by security features.
>>>
>> What exactly are you referring to?
> 
> I don't know this hardware very well, but on a different platform, we
> needed to make the crypto engines as disabled if they were being
> accessed through secure operations which made it unavailable to Linux
> without using some special barriers. I didn't have the special
> hardware on the other platform that required it that way, so I can't
> really explain it well.  I know on those special cases, because some
> people were accessing these registers through other means, the devices
> had to be marked as 'disabled' so to avoid breaking something.  Since
> I wasn't sure if this was left out of the i.MX8M Mini on purpose, I
> let this disabled just in case this hardware platform was also
> affected in a similar and people wanting to use it could mark it as
> 'okay'

I don't know enough about this to understand the problem you're 
describing. It seems like most SoCs have the CAAM enabled by default in 
the devicetree. On first glance I could only find fsl-lx2160a.dtsi that 
has it disabled.

> 
> adam
> 
>>
>>> This patch places in into the device tree and marks it as disabled,
>>> but anyone not restricting the CAAM with secure mode functions
>>> can mark it as enabled.
>>>
>> Even if - due to export control regulations - CAAM is "trimmed down",
>> it loses only the encryption capabilities (hashing etc. still working).

I don't know much about this, but as Horia said the CAAM might have 
limited capabilities in some cases but would still work.

Therefore I think the CAAM should be enabled by default as it already is 
done for most other SoCs.

Regards,
Frieder

>>
>> Again, please clarify what you mean by "secure mode functions",
>> "security features" etc.
>>
>> Horia
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Patch
diff mbox series

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 2ed1a3537f05..68c7c1adeb60 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -723,6 +723,37 @@ 
 				status = "disabled";
 			};
 
+			crypto: crypto@30900000 {
+				compatible = "fsl,sec-v4.0";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x30900000 0x40000>;
+				ranges = <0 0x30900000 0x40000>;
+				interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&clk IMX8MM_CLK_AHB>,
+					 <&clk IMX8MM_CLK_IPG_ROOT>;
+				clock-names = "aclk", "ipg";
+				status = "disabled";
+
+				sec_jr0: jr@1000 {
+					compatible = "fsl,sec-v4.0-job-ring";
+					reg = <0x1000 0x1000>;
+					interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+				};
+
+				sec_jr1: jr@2000 {
+					compatible = "fsl,sec-v4.0-job-ring";
+					reg = <0x2000 0x1000>;
+					interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+				};
+
+				sec_jr2: jr@3000 {
+					compatible = "fsl,sec-v4.0-job-ring";
+					reg = <0x3000 0x1000>;
+					interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+				};
+			};
+
 			i2c1: i2c@30a20000 {
 				compatible = "fsl,imx8mm-i2c", "fsl,imx21-i2c";
 				#address-cells = <1>;