> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > Sent: Thursday, July 13, 2023 12:09 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 1/7] dt-bindings: arm: fsl: add se-fw binding doc > > 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: > > The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded secure > > enclave within the SoC boundary to enable features like > > - HSM > > - SHE > > - V2X > > > > Communicates via message unit with linux kernel. This driver is > > enables communication ensuring well defined message sequence protocol > > between Application Core and enclave's firmware. > > > > Driver configures multiple misc-device on the MU, for multiple > > user-space applications can communicate on single MU. > > > > It exists on some i.MX processors. e.g. i.MX8ULP, i.MX93 etc. > > > > Signed-off-by: Pankaj Gupta <pankaj.gupta@xxxxxxx> > > --- > > .../bindings/arm/freescale/fsl,se-fw.yaml | 121 ++++++++++++++++++ > > 1 file changed, 121 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/arm/freescale/fsl,se-fw.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/arm/freescale/fsl,se-fw.yaml > > b/Documentation/devicetree/bindings/arm/freescale/fsl,se-fw.yaml > > new file mode 100644 > > index 000000000000..7567da0b4c21 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,se-fw.yaml > > @@ -0,0 +1,121 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > +cetree.org%2Fschemas%2Farm%2Ffreescale%2Ffsl%2Cse- > fw.yaml%23&data=05% > > > +7C01%7Cpankaj.gupta%40nxp.com%7Cfd14adabdde046302b1908db83073 > a2d%7C68 > > > +6ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638247839285279031 > %7CUnknown > > > +%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLC > > > +JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vUn1TrC%2Fk2f%2B5do%2FoK > OSu7cWDl3s > > +6BddlvIIO%2FxZGMA%3D&reserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > +cetree.org%2Fmeta- > schemas%2Fcore.yaml%23&data=05%7C01%7Cpankaj.gupta% > > > +40nxp.com%7Cfd14adabdde046302b1908db83073a2d%7C686ea1d3bc2b4 > c6fa92cd9 > > > +9c5c301635%7C0%7C0%7C638247839285279031%7CUnknown%7CTWFpb > GZsb3d8eyJWI > > > +joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > 000% > > > +7C%7C%7C&sdata=9sbFCHNNCHHsjLbZ%2BHQls3ZrXKF%2BhbpizZhIxfvytlo% > 3D&res > > +erved=0 > > + > > +title: NXP i.MX EdgeLock Enclave Firmware (ELEFW) > > + > > +maintainers: > > + - Pankaj Gupta <pankaj.gupta@xxxxxxx> > > + > > +description: | > > + > > + The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded > > + secure enclave within the SoC boundary to enable features like > > + - HSM > > + - SHE > > + - V2X > > + > > + It uses message unit to communicate and coordinate to pass messages > > + (e.g., data, status and control) through its interfaces. > > + > > + This driver configures multiple misc-devices on the MU, to exchange > > + messages from User-space application and NXP's Edgelocke Enclave > firmware. > > + The driver ensures that the messages must follow the following > > + protocol defined. > > + > > + Non-Secure + Secure > > + | > > + | > > + +---------+ +-------------+ | > > + | ele_mu.c+<---->+imx-mailbox.c| | > > + | | | mailbox.c +<-->+------+ +------+ > > + +---+-----+ +-------------+ | MU X +<-->+ ELE | > > + | +------+ +------+ > > + +----------------+ | > > + | | | > > + v v | > > + logical logical | > > + receiver waiter | > > + + + | > > + | | | > > + | | | > > + | +----+------+ | > > + | | | | > > + | | | | > > + device_ctx device_ctx device_ctx | > > + | > > + User 0 User 1 User Y | > > + +------+ +------+ +------+ | > > + |misc.c| |misc.c| |misc.c| | > > + kernel space +------+ +------+ +------+ | > > + | > > + +------------------------------------------------------ | > > + | | | | > > + userspace /dev/ele_muXch0 | | | > > + /dev/ele_muXch1 | | > > + /dev/ele_muXchY | > > + | > > + > > + When a user sends a command to the ELE, it registers its device_ctx > > + as waiter of a response from ELE. > > + > > + A user can be registered as receiver of command from the ELE. > > + Create char devices in /dev as channels of the form /dev/ele_muXchY > > + with X the id of the driver and Y for each users. It allows to send > > + and receive messages to the NXP EdgeLock Enclave IP on NXP SoC, > > + where current possible value, i.e., supported SoC(s) are imx8ulp, imx93. > > + > > +properties: > > + compatible: > > + enum: > > + - fsl,imx-ele > > + - fsl,imx93-ele > > + > > + mboxes: > > + description: > > + A list of phandles of TX MU channels followed by a list of phandles of > > + RX MU channels. The number of expected tx and rx channels is 1 TX, > and > > + 1 RX channels. All MU channels must be within the same MU instance. > > + Cross instances are not allowed. The MU instance to be used is S4MUAP > > + for imx8ulp & imx93. Users need to ensure that used MU instance does > not > > + conflict with other execution environments. > > + items: > > + - description: TX0 MU channel > > + - description: RX0 MU channel > > + > > + mbox-names: > > + items: > > + - const: tx > > + - const: rx > > + > > + fsl,mu-did: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Owner of message-unit, is identified via Domain ID or did. > > What is Domain ID? By design, Domain is a clean separated processing island with separate power, clocking and peripheral; but with a tightly integrated bus fabric for efficient communication. The Domain to which this message-unit is associated, is identified via Domain ID or did. I will update this info in the YAML file too. > > > + > > + fsl,mu-id: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Identifier to the message-unit among the multiple message-unit that > exists on SoC. > > + It is used to create the channels, default to 2 > > Do you expect then multiple ele nodes in the DTS? What are these two > properties and why they are fixed per SoC, but still embedded in DTS? Removed this line. > > > + > > + > > Drop stray blank line. > Removed the blank line. > > +required: > > + - compatible > > + - mboxes > > + - mbox-names > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + ele_mu: ele_mu { > > No underscores in node names, generic node names, e.g. firmware. Look at > existing code. Changed from: - ele_mu to ele-mu. - "ele_mu {" to "se-fw {" Name of yaml file, is se-fw.yaml. > > > + compatible = "fsl,imx93-ele"; > > + mbox-names = "tx", "rx"; > > + mboxes = <&s4muap 2 0 > > + &s4muap 3 0>; > > Two items, not one. Corrected it to "mboxes= = <&s4muap 2 0 &s4muap 3 0>;" > > > + fsl,mu-did = <1>; > > + fsl,mu-id = <1>; > > + }; > > Plus you clearly did not test the binding and DTS. You said you did some > internal review, so I assume this also includes some testing. How did you test > your DTS? > Each version is tested before sent for review here. I have tested the DTS file by compiling it and loading the DTB to the board. Executed test on the board. > Best regards, > Krzysztof
