> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> Sent: Tuesday, August 8, 2023 8:22 PM
> To: Pankaj Gupta <pankaj.gupta@xxxxxxx>; shawnguo@xxxxxxxxxx;
> s.hauer@xxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx; clin@xxxxxxxx;
> conor+dt@xxxxxxxxxx; pierre.gondois@xxxxxxx; Jacky Bai
> <ping.bai@xxxxxxx>; Clark Wang <xiaoning.wang@xxxxxxx>; Wei Fang
> <wei.fang@xxxxxxx>; Peng Fan <peng.fan@xxxxxxx>; Bough Chen
> <haibo.chen@xxxxxxx>; festevam@xxxxxxxxx; dl-linux-imx <linux-
> imx@xxxxxxx>; davem@xxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> krzysztof.kozlowski+dt@xxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Gaurav Jain
> <gaurav.jain@xxxxxxx>; alexander.stein@xxxxxxxxxxxxxxx; Sahil Malhotra
> <sahil.malhotra@xxxxxxx>; Aisheng Dong <aisheng.dong@xxxxxxx>;
> Varun Sethi <V.Sethi@xxxxxxx>
> Subject: Re: [EXT] Re: [PATCH v4 4/7] arm64: dts: imx93-11x11-evk: added
> nxp secure enclave fw
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On 08/08/2023 13:49, Pankaj Gupta wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pankaj Gupta
> >> Sent: Tuesday, August 8, 2023 5:04 PM
> >> To: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>;
> >> shawnguo@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx;
> kernel@xxxxxxxxxxxxxx;
> >> clin@xxxxxxxx; conor+dt@xxxxxxxxxx; pierre.gondois@xxxxxxx; Jacky
> Bai
> >> <ping.bai@xxxxxxx>; Clark Wang <xiaoning.wang@xxxxxxx>; Wei Fang
> >> <wei.fang@xxxxxxx>; Peng Fan <peng.fan@xxxxxxx>; Bough Chen
> >> <haibo.chen@xxxxxxx>; festevam@xxxxxxxxx; dl-linux-imx <linux-
> >> imx@xxxxxxx>; davem@xxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> >> krzysztof.kozlowski+dt@xxxxxxxxxx;
> >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> >> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Gaurav Jain
> >> <gaurav.jain@xxxxxxx>; alexander.stein@xxxxxxxxxxxxxxx; Sahil
> >> Malhotra <sahil.malhotra@xxxxxxx>; Aisheng Dong
> >> <aisheng.dong@xxxxxxx>; Varun Sethi <V.Sethi@xxxxxxx>
> >> Subject: RE: [EXT] Re: [PATCH v4 4/7] arm64: dts: imx93-11x11-evk:
> >> added nxp secure enclave fw
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> >>> Sent: Thursday, July 13, 2023 12:38 AM
> >>> To: Pankaj Gupta <pankaj.gupta@xxxxxxx>; shawnguo@xxxxxxxxxx;
> >>> s.hauer@xxxxxxxxxxxxxx; kernel@xxxxxxxxxxxxxx; clin@xxxxxxxx;
> >>> conor+dt@xxxxxxxxxx; pierre.gondois@xxxxxxx; Jacky Bai
> >>> <ping.bai@xxxxxxx>; Clark Wang <xiaoning.wang@xxxxxxx>; Wei
> Fang
> >>> <wei.fang@xxxxxxx>; Peng Fan <peng.fan@xxxxxxx>; Bough Chen
> >>> <haibo.chen@xxxxxxx>; festevam@xxxxxxxxx; dl-linux-imx <linux-
> >>> imx@xxxxxxx>; davem@xxxxxxxxxxxxx; robh+dt@xxxxxxxxxx;
> >>> krzysztof.kozlowski+dt@xxxxxxxxxx;
> >>> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> >>> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Gaurav
> >>> Jain <gaurav.jain@xxxxxxx>; alexander.stein@xxxxxxxxxxxxxxx; Sahil
> >>> Malhotra <sahil.malhotra@xxxxxxx>; Aisheng Dong
> >>> <aisheng.dong@xxxxxxx>;
> >> Varun
> >>> Sethi <V.Sethi@xxxxxxx>
> >>> Subject: [EXT] Re: [PATCH v4 4/7] arm64: dts: imx93-11x11-evk: added
> >>> nxp secure enclave fw
> >>>
> >>> Caution: This is an external email. Please take care when clicking
> >>> links or opening attachments. When in doubt, report the message
> >>> using the 'Report this email' button
> >>>
> >>>
> >>> On 12/07/2023 14:12, Pankaj Gupta wrote:
> >>>> Added support for NXP secure enclave called EdgeLock Enclave
> >>>> firmware
> >>>> (se-fw) for imx93-11x11-evk.
> >>>>
> >>>> Signed-off-by: Pankaj Gupta <pankaj.gupta@xxxxxxx>
> >>>> ---
> >>>> arch/arm64/boot/dts/freescale/imx93.dtsi | 11 ++++++++++-
> >>>> 1 file changed, 10 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> >>>> b/arch/arm64/boot/dts/freescale/imx93.dtsi
> >>>> index 8643612ace8c..2b0f901d2709 100644
> >>>> --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> >>>> +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> >>>> @@ -1,6 +1,6 @@
> >>>> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>>> /*
> >>>> - * Copyright 2022 NXP
> >>>> + * Copyright 2022-2023 NXP
> >>>> */
> >>>>
> >>>> #include <dt-bindings/clock/imx93-clock.h> @@ -863,5 +863,14 @@
> >>>> ddr-pmu@4e300dc0 {
> >>>> reg = <0x4e300dc0 0x200>;
> >>>> interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> >>>> };
> >>>> +
> >>>> + ele_fw: se-fw {
> >>>> + compatible = "fsl,imx93-ele";
> >>>> + mboxes = <&s4muap 0 0 &s4muap 1 0>;
> >>>
> >>> This should be two entries.
> >>>
> >>>> + mbox-names = "tx", "rx";
> >>>> + fsl,mu-did = <3>;
> >>>> + fsl,mu-id = <2>;
> >>>
> >>> Drop both. Since you put it into the DTSI, it means it is compatible
> specific.
> >> [Pankaj] Removed the above three entries.
> >
> >
> > [Pankaj] Correction:
> > I missed to note that in our up-coming SoC(s), there will be multiple
> MU(s):
> > Those can only be identified using mu_id. Hence, following two only, will
> be removed:
> > + mbox-names = "tx", "rx";
> > + fsl,mu-did = <3>;
>
> Which SoC?
Existing NXP SoC iMX8DXL. Its driver will be using this as a base driver, which has multiple MU(s).
> How the bindings are going to look like for that SoC?
There are 8 MU(s): 3 for secure-enclave called SECO, and 5 for V2X based MU(s).
Bindings for that SoC will be like:
A. For SECO based HSM:
For mu_id =1:
seco_fw1: se-fw1 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&seco_mu1 0 0>,
<& seco_mu1 1 0>;
fsl,mu-id = <1>;
sram-pool = <&sram0>;
};
For mu_id = 2
seco_fw2: se-fw2 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&seco_mu2 0 0>,
<&seco_mu2 1 0>;
fsl,mu-id = <2>;
sram-pool = <&sram0>;
};
For mu_id = 3
seco_fw3: se-fw3 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&seco_mu3 0 0>,
<&seco_mu3 1 0>;
fsl,mu-id = <3>;
};
B. For V2X based HSM:
For mu_id =4:
v2x_fw4: se-fw4 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&v2x_mu4 0 0>,
<&v2x_mu4 1 0>;
fsl,mu-id = <4>;
sram-pool = <&sram0>;
};
For mu_id = 5
v2x_fw5: se-fw5 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&v2x_mu5 0 0>,
<&v2x_mu5 1 0>;
fsl,mu-id = <5>;
sram-pool = <&sram0>;
};
For mu_id = 6
v2x_fw6: se-fw6 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&v2x_mu6 0 0>,
<&v2x_mu6 1 0>;
fsl,mu-id = <6>;
};
For mu_id = 7:
ele_fw7: se-fw7 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&v2x_mu7 0 0>,
<& v2x_mu7 1 0>;
fsl,mu-id = <7>;
sram-pool = <&sram0>;
};
For mu_id = 8
v2x_fw2: se-fw8 {
compatible = "fsl,imx8dxl-se-fw";
mbox-names = "tx", "rx";
mboxes = <&v2x_mu8 0 0>,
<&v2x_mu8 1 0>;
fsl,mu-id = <8>;
sram-pool = <&sram0>;
};
> What is mu-did in such case and how does it relate to different mailboxes? Why it
> cannot be inferred from compatible?
"mu_did" will be removed. And it can be deduced from compatible.
If you mean “mu_id”, then it identifies communication interface for the IP block.
"mu_id" can be multiple for a SoC, with same compatible. As quoted for i.MX8DXL above.
"mu_id" will help us, identify the correct communication interface ele_fw<x>, to choose among multiple mu(s) .
>
> BTW, responding three weeks after my review does not help your case. I
> totally loose the context. Of course you can reply even after 1 year, it's your
> right, but it does not help the discussion.
Point noted. I will be prompt now-onwards.
>
> Best regards,
> Krzysztof
