[PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true

[Peng Fan]

> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
> 
> On 08/04/2024 08:08, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 08/04/2024 01:50, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 12:04, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> >>>>>>>> set additionalProperties to true
> >>>>>>>>
> >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>>>> From: Peng Fan <peng.fan at nxp.com>
> >>>>>>>>>
> >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> >> warning:
> >>>>>>>>> "
> >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol at 81', 'protocol at 84' do
> >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>>>> "
> >>>>>>>>>
> >>>>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>>>
> >>>>>>>> I do not see anything addressed here, except making the binding
> >>>>>>>> accepting anything anywhere...
> >>>>>>>
> >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> >> extension.
> >>>>>>>
> >>>>>>> With additionalProperties set to false, I not know how, please
> suggest.
> >>>>>>
> >>>>>> First of all, you cannot affect negatively existing devices
> >>>>>> (their
> >>>>>> bindings) and your patch does exactly that. This should make you
> >>>>>> thing what is the correct approach...
> >>>>>>
> >>>>>> Rob gave you the comment about missing compatible - you still did
> >>>>>> not address that.
> >>>>>
> >>>>> I added the compatible in patch 2/6 in the examples "compatible =
> >>>> "arm,scmi";"
> >>>>
> >>>> So you claim that your vendor extensions are the same or fully
> >>>> compatible with arm,scmi and you add nothing... Are your
> >>>> extensions/protocol valid for arm,scmi?
> >>>
> >>> Yes. They are valid for arm,scmi.
> >>>
> >>>  If yes, why is this in separate binding. If no, why you use someone
> >>>> else's compatible?
> >>>
> >>> Per SCMI Spec
> >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> >>> this interface
> >>>
> >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> >>> id for their own protocol.
> >>
> >> So how are they valid for arm,scmi? I don't understand.
> >
> > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > I think the arm,scmi is that saying the firmware following SCMI spec
> > to implement the protocols.
> >
> > For vendor reserved ID, firmware also follow the SCMI spec to
> > implement their own usage, so from firmware level, it is ARM SCMI spec
> compatible.
> 
> That's not the point. It is obvious that your firmware is compatible with
> arm,scmi, but what you try to say in this and revised patch is that every
> arm,scmi is compatible with your implementation. What you are saying is
> that 0x84 is MISC protocol for every firmware, Qualcomm, NXP, Samsung, TI,
> Mediatek etc.
> 
> I claim it is not true. 0x84 is not MISC for Qualcomm, for example.

You are right. I am lost now on how to add vendor ID support, using
arm,scmi.yaml or adding a new imx,scmi.yaml or else.

Please suggest.

Thanks,
Peng
> 
> Best regards,
> Krzysztof