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

[Peng Fan]

Hi Krzysztof,

> Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
> 
> > 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@xxxxxxx>
> > >>>>>>>>>
> > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > >> warning:
> > >>>>>>>>> "
> > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@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.

Do you have any suggestions on how to add vendor protocol in
dt-schema? I am not sure what to do next, still keep imx,scmi.yaml
or add vendor stuff in arm,scmi.yaml?

Thanks,
Peng.

> 
> Please suggest.
> 
> Thanks,
> Peng
> >
> > Best regards,
> > Krzysztof