| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<DU0PR04MB94176D02B90528913842B76A88002@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Mon, 8 Apr 2024 06:08:33 +0000
From: Peng Fan <peng.fan@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>, "Peng Fan (OSS)"
<peng.fan@....nxp.com>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Shawn Guo
<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
Sudeep Holla <sudeep.holla@....com>, Cristian Marussi
<cristian.marussi@....com>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
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 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@....com>
> >>>>>>>
> >>>>>>> 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.
firmware {
scmi {
compatible = "arm,scmi";
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sys_power: protocol@12 {
reg = <0x12>;
};
scmi_perf: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
Scmi_bbm: protocol@81 {
reg = <0x81>; ->vendor id
vendor,xyz; ---> vendor properties.
}
Thanks,
Peng.
>
>
>
> Best regards,
> Krzysztof
Powered by blists - more mailing lists