All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Marek Vasut <marex@denx.de>
Cc: linux-arm-kernel@lists.infradead.org,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Rafał Miłecki" <rafal@milecki.pl>,
	"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 1/3] [RFC] dt-bindings: nvmem: syscon: Add syscon backed nvmem bindings
Date: Fri, 28 Oct 2022 16:28:38 -0500	[thread overview]
Message-ID: <20221028212838.GA2286583-robh@kernel.org> (raw)
In-Reply-To: <20221027225020.215149-1-marex@denx.de>

On Fri, Oct 28, 2022 at 12:50:18AM +0200, Marek Vasut wrote:
> Add trivial bindings for driver which permits exposing syscon backed
> register to userspace. This is useful e.g. to expose U-Boot boot
> counter on various platforms where the boot counter is stored in
> random volatile register, like STM32MP15xx TAMP_BKPxR register.

Generic bindings always start trivial until they get appended one 
property at a time...

What happens when you have more than 1 field and/or more than 1 
register?

> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Rafał Miłecki <rafal@milecki.pl>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> To: linux-arm-kernel@lists.infradead.org
> ---
>  .../bindings/nvmem/nvmem-syscon.yaml          | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml b/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> new file mode 100644
> index 0000000000000..3035a0b2cd24a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/nvmem-syscon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic syscon backed nvmem
> +
> +maintainers:
> +  - Marek Vasut <marex@denx.de>
> +
> +allOf:
> +  - $ref: "nvmem.yaml#"
> +
> +properties:
> +  compatible:
> +    enum:
> +      - nvmem-syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    tamp@5c00a000 {
> +        compatible = "st,stm32-tamp", "syscon", "simple-mfd";

This is very common, but personally I think "syscon" and "simple-mfd" 
should be mutually exclusive. "simple-mfd" is saying the children have 
no dependency on the parent, yet the child nodes need a regmap from the 
parent. Sounds like a dependency.

> +        reg = <0x5c00a000 0x400>;
> +
> +        nvmem-syscon {
> +            compatible = "nvmem-syscon";
> +            reg = <0x14c 0x4>;

How does one identify this is the bootloader's boot count? How does the 
bootloader know it can write to this?

> +        };
> +    };
> -- 
> 2.35.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Marek Vasut <marex@denx.de>
Cc: linux-arm-kernel@lists.infradead.org,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Rafał Miłecki" <rafal@milecki.pl>,
	"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 1/3] [RFC] dt-bindings: nvmem: syscon: Add syscon backed nvmem bindings
Date: Fri, 28 Oct 2022 16:28:38 -0500	[thread overview]
Message-ID: <20221028212838.GA2286583-robh@kernel.org> (raw)
In-Reply-To: <20221027225020.215149-1-marex@denx.de>

On Fri, Oct 28, 2022 at 12:50:18AM +0200, Marek Vasut wrote:
> Add trivial bindings for driver which permits exposing syscon backed
> register to userspace. This is useful e.g. to expose U-Boot boot
> counter on various platforms where the boot counter is stored in
> random volatile register, like STM32MP15xx TAMP_BKPxR register.

Generic bindings always start trivial until they get appended one 
property at a time...

What happens when you have more than 1 field and/or more than 1 
register?

> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Rafał Miłecki <rafal@milecki.pl>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> To: linux-arm-kernel@lists.infradead.org
> ---
>  .../bindings/nvmem/nvmem-syscon.yaml          | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml b/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> new file mode 100644
> index 0000000000000..3035a0b2cd24a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem-syscon.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/nvmem-syscon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic syscon backed nvmem
> +
> +maintainers:
> +  - Marek Vasut <marex@denx.de>
> +
> +allOf:
> +  - $ref: "nvmem.yaml#"
> +
> +properties:
> +  compatible:
> +    enum:
> +      - nvmem-syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    tamp@5c00a000 {
> +        compatible = "st,stm32-tamp", "syscon", "simple-mfd";

This is very common, but personally I think "syscon" and "simple-mfd" 
should be mutually exclusive. "simple-mfd" is saying the children have 
no dependency on the parent, yet the child nodes need a regmap from the 
parent. Sounds like a dependency.

> +        reg = <0x5c00a000 0x400>;
> +
> +        nvmem-syscon {
> +            compatible = "nvmem-syscon";
> +            reg = <0x14c 0x4>;

How does one identify this is the bootloader's boot count? How does the 
bootloader know it can write to this?

> +        };
> +    };
> -- 
> 2.35.1
> 
> 

  parent reply	other threads:[~2022-10-28 21:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 22:50 [PATCH 1/3] [RFC] dt-bindings: nvmem: syscon: Add syscon backed nvmem bindings Marek Vasut
2022-10-27 22:50 ` Marek Vasut
2022-10-27 22:50 ` [PATCH 2/3] [RFC] nvmem: syscon: Add syscon backed nvmem driver Marek Vasut
2022-10-27 22:50   ` Marek Vasut
2022-10-27 22:50 ` [PATCH 3/3] [RFC] ARM: dts: stm32: Add nvmem-syscon node to TAMP to expose boot count on DHSOM Marek Vasut
2022-10-27 22:50   ` Marek Vasut
2022-10-28 12:20 ` [PATCH 1/3] [RFC] dt-bindings: nvmem: syscon: Add syscon backed nvmem bindings Rob Herring
2022-10-28 12:20   ` Rob Herring
2022-10-28 21:28 ` Rob Herring [this message]
2022-10-28 21:28   ` Rob Herring
2022-11-27 22:05   ` Marek Vasut
2022-11-27 22:05     ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221028212838.GA2286583-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@denx.de \
    --cc=rafal@milecki.pl \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.