> 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. Please suggest. Thanks, Peng > > Best regards, > Krzysztof
