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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Apr 2024 08:34:00 -0500
From: Rob Herring <robh@...nel.org>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc: Jonathan Corbet <corbet@....net>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Peng Fan <peng.fan@....com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 2/6] dt-bindings: firmware: add i.MX95 SCMI Extension
 protocol

On Fri, Apr 12, 2024 at 06:47:08PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> Add i.MX SCMI Extension protocols bindings for:
>  - Battery Backed Module(BBM) Protocol
>    This contains persistent storage (GPR), an RTC, and the ON/OFF button.
>    The protocol can also provide access to similar functions implemented via
>    external board components.
>  - MISC Protocol.
>    This includes controls that are misc settings/actions that must be exposed
>    from the SM to agents. They are device specific and are usually define to
>    access bit fields in various mix block control modules, IOMUX_GPR, and other
>    GPR/CSR owned by the SM.
> 
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml     | 21 +++++++++++++
>  .../bindings/firmware/nxp,imx95-scmi.yaml          | 36 ++++++++++++++++++++++
>  2 files changed, 57 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index 93fb7d05f849..fa2cc910c485 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -247,6 +247,27 @@ properties:
>        reg:
>          const: 0x18
>  
> +  protocol@81:
> +    $ref: '#/$defs/protocol-node'
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        const: 0x81
> +
> +  protocol@84:
> +    type: object
> +    anyOf:
> +      - allOf:
> +          - $ref: /schemas/firmware/nxp,imx95-scmi.yaml
> +          - $ref: '#/$defs/protocol-node'

If you put the ref under the protocol node, then it's 1 schema file per 
protocol per vendor. Also, we then have to list every possible protocol 
node here, and every one listed here will be valid for every vendor.  
What we discussed is putting the list of vendor protocol schemas at the 
top-level here and then the vendor schemas can list out all the protocol 
nodes.

Also, move "$ref: '#/$defs/protocol-node'" to nxp,imx95-scmi.yaml.

> +
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        const: 0x84
> +
>  additionalProperties: false
>  
>  $defs:
> diff --git a/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
> new file mode 100644
> index 000000000000..b84c4a53b78a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2024 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/nxp,imx95-scmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX95 System Control and Management Interface(SCMI) Vendor Protocols Extension
> +
> +maintainers:
> +  - Peng Fan <peng.fan@....com>
> +
> +properties:
> +  nxp,wakeup-sources:
> +    description:
> +      Each entry consists of 2 integers, represents the source and electric signal edge
> +    items:
> +      items:
> +        - description: the wakeup source
> +        - description: the wakeup electric signal edge
> +    minItems: 1
> +    maxItems: 32
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> +if:
> +  properties:
> +    reg:
> +      const: 0x84

This schema is only included from protocol@84 node, so how can this be 
false?

> +then:
> +  properties:
> +    nxp,wakeup-sources: true
> +else:
> +  properties:
> +    nxp,wakeup-sources: false
> +
> +additionalProperties: true
> 
> -- 
> 2.37.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ