[PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension protocol
Peng Fan
peng.fan at nxp.com
Sun Apr 7 03:15:35 PDT 2024
> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> On 07/04/2024 02:51, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 2/6] dt-bindings: firmware: add i.MX SCMI
> >> Extension protocol
> >>
> >> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>> From: Peng Fan <peng.fan at nxp.com>
> >>>
> >>> Add i.MX SCMI Extension protocols bindings for:
> >>> - Battery Backed Secure Module(BBSM)
> >>
> >> Which is what?
> >
> > I should say BBM(BBSM + BBNSM), BBM has RTC and ON/OFF key features,
> > but BBM is managed by SCMI firmware and exported to agent by BBM
> > protocol. So add bindings for i.MX BBM protocol.
> >
> > Is this ok?
>
> No, I still don't know what is BBSM, BBNSM and BBM.
>From RM:
The Battery Backup (BB) Domain contains the Battery Backed
Security Module (BBSM) and the Battery Backed Non-Secure
Module (BBNSM).
BBNSM:
The BBNSM is the interface to a non-interruptable power
supply (backup battery) and serves as the non-volatile logic
and storage for the chip. When the chip is powered off, the
BBNSM will maintain PMIC logic while connected to a backup supply.
Main features: RTC, PMIC Control, ONOFF Control
BBSM serves as nonvolatile security logic and storage for ELE
Main features: Monotonic counter, Secure RTC,
Zeroizable Master Key,
Security Violation and Tamper Detection
>
> >
> >>
> >>> - MISC settings such as General Purpose Registers settings.
> >>>
> >>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> >>> ---
> >>> .../devicetree/bindings/firmware/imx,scmi.yaml | 80
> >> ++++++++++++++++++++++
> >>> 1 file changed, 80 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> new file mode 100644
> >>> index 000000000000..7ee19a661d83
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/firmware/imx,scmi.yaml
> >>> @@ -0,0 +1,80 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright
> >>> +2024 NXP %YAML 1.2
> >>> +---
> >>> +$id:
> >>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> >>>
> +vi%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C410d9f1b5b874269dc6
> 908dc5
> >>>
> +6e0b628%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638480
> 77032584
> >>>
> +3394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLC
> >>>
> +JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e4zKRcyHbSCtn
> o6%2B%
> >>> +2BBaz%2FGhvPT0HikAdLmwi4VZxX4o%3D&reserved=0
> >>>
> >>
> +cetree.org%2Fschemas%2Ffirmware%2Fimx%2Cscmi.yaml%23&data=05%7
> >> C02%7Cp
> >>>
> >>
> +eng.fan%40nxp.com%7C5d16781d3eca425a342508dc562910b7%7C686ea
> >> 1d3bc2b4c
> >>>
> >>
> +6fa92cd99c5c301635%7C0%7C0%7C638479981570959816%7CUnknown%
> >> 7CTWFpbGZsb
> >>>
> >>
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> >> 0%3D
> >>>
> >>
> +%7C0%7C%7C%7C&sdata=mWNwPvu2eyF18MroVOBHb%2Fjeo%2BIHfV5V
> >> h%2F9ebdx65MM
> >>> +%3D&reserved=0
> >>> +$schema:
> >>> +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fde
> >>>
> +vi%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C410d9f1b5b874269dc6
> 908dc5
> >>>
> +6e0b628%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638480
> 77032585
> >>>
> +6477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLC
> >>>
> +JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=y1OBJ%2FPp4
> MljifpmG
> >>> +ZM%2FB6Ab20ivqm2qef7gzEjbNmA%3D&reserved=0
> >>> +cetree.org%2Fmeta-
> >> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >>>
> >>
> +p.com%7C5d16781d3eca425a342508dc562910b7%7C686ea1d3bc2b4c6fa
> >> 92cd99c5c
> >>>
> >>
> +301635%7C0%7C0%7C638479981570971949%7CUnknown%7CTWFpbGZs
> >> b3d8eyJWIjoiM
> >>>
> >>
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> >> C%7C%7
> >>>
> >>
> +C&sdata=v4XnGG00D4I8j5MJvDUVYMRTm7yRrvz0V3fUyc5KAAA%3D&reser
> >> ved=0
> >>> +
> >>> +title: i.MX System Control and Management Interface(SCMI) Vendor
> >>> +Protocols Extension
> >>> +
> >>> +maintainers:
> >>> + - Peng Fan <peng.fan at nxp.com>
> >>> +
> >>> +allOf:
> >>> + - $ref: arm,scmi.yaml#
> >>
> >> Sorry, but arm,scmi is a final schema. Is your plan to define some
> >> common part?
> >
> > No. I just wanna add vendor extension per SCMI spec.
> >
> > 0x80-0xFF:
> > Reserved for vendor or platform-specific extensions to this interface
> >
> > Each vendor may have different usage saying id 0x81, so I add i.MX
> > dt-schema file.
> >
> >>
> >>> +
> >>> +properties:
> >>> + protocol at 81:
> >>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> >>> + unevaluatedProperties: false
> >>> + description:
> >>> + The BBM Protocol is for managing Battery Backed Secure Module
> >> (BBSM) RTC
> >>> + and the ON/OFF Key
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + const: 0x81
> >>> +
> >>> + required:
> >>> + - reg
> >>> +
> >>> + protocol at 84:
> >>> + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> >>> + unevaluatedProperties: false
> >>> + description:
> >>> + The MISC Protocol is for managing SoC Misc settings, such as
> >>> + GPR settings
> >>
> >> Genera register is not a setting... this is a pleonasm. Please be
> >> more specific what is the GPR, MISC protocol etc.
> >
> > The MISC Protocol is for managing SoC Misc settings, such as SAI
> > MCLK/MQS in Always On domain BLK CTRL, SAI_CLK_SEL in WAKEUP BLK
> > CTRL, gpio expanders which is under control of SCMI firmware.
>
> So like a bag for everything which you do not want to call something specific?
>
> No, be specific...
This is not linux stuff, this is i.MX SCMI firmware design.
Sadly there is no public RM for i.MX95, we could not afford each settings
has a protocol ID, it is too heavy. The name MISC is not developed for linux,
it is firmware owner decided to use it.
>
> >
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + const: 0x84
> >>> +
> >>> + wakeup-sources:
> >>> + description:
> >>> + Each entry consists of 2 integers, represents the source
> >>> + and electric signal edge
> >>
> >> Can you answer questions from reviewers?
> >
> > Sorry. Is this ok?
> > minItems: 1
> > maxItems: 32
>
> No. Does it answers Rob's question? I see zero correlation to his question.
Constraints and edge, right? Edge, I have use electric signal edge, so
what else?
>
> Do not ignore emails from reviewers but respond to them.
>
> >
> >>
> >>> + items:
> >>> + items:
> >>> + - description: the wakeup source
> >>> + - description: the wakeup electric signal edge
> >>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>> +
> >>> + required:
> >>> + - reg
> >>> +
> >>> +additionalProperties: false
> >>> +
> >>> +examples:
> >>> + - |
> >>> + firmware {
> >>> + scmi {
> >>> + compatible = "arm,scmi";
> >>
> >>> + mboxes = <&mu2 5 0>, <&mu2 3 0>, <&mu2 3 1>;
> >>> + shmem = <&scmi_buf0>, <&scmi_buf1>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + protocol at 81 {
> >>> + reg = <0x81>;
> >>> + };
> >>> +
> >>> + protocol at 84 {
> >>> + reg = <0x84>;
> >>> + wakeup-sources = <0x8000 1
> >>> + 0x8001 1
> >>> + 0x8002 1
> >>> + 0x8003 1
> >>> + 0x8004 1>;
> >>
> >> Nothing improved... If you are going to ignore reviews, then you will
> >> only get NAKed.
> >
> > Sorry, you mean the examples, or the whole dt-schema?
>
> *Read comments and respond to them*. Regardless where they are.
Yeah. My bad.
Thanks,
Peng
>
> Best regards,
> Krzysztof
More information about the linux-arm-kernel
mailing list