All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: mark.rutland@arm.com, lionel.debieve@st.com,
	alexandre.torgue@st.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, srinivas.kandagatla@linaro.org,
	mcoquelin.stm32@gmail.com,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem
Date: Mon, 25 Feb 2019 10:53:07 -0600	[thread overview]
Message-ID: <20190225165307.GA26260@bogus> (raw)
In-Reply-To: <1548866336-14765-2-git-send-email-fabrice.gasnier@st.com>

On Wed, Jan 30, 2019 at 05:38:53PM +0100, Fabrice Gasnier wrote:
> Add documentation for STMicroelectronics STM32 Factory-programmed
> read only memory area.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
>  .../devicetree/bindings/nvmem/st,stm32-romem.txt   | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> new file mode 100644
> index 0000000..fbff52e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> @@ -0,0 +1,31 @@
> +STMicroelectronics STM32 Factory-programmed data device tree bindings
> +
> +This represents STM32 Factory-programmed read only non-volatile area: locked
> +flash, OTP, read-only HW regs... This contains various information such as:

Several distinct types here. Does s/w need to know the difference 
rather than just one generic-ish compatible? Access size restrictions 
maybe? Ability to unlock and program?

If not, then why even make this stm32 specific?

> +analog calibration data for temperature sensor (e.g. TS_CAL1, TS_CAL2),
> +internal vref (VREFIN_CAL), unique device ID...
> +
> +Required properties:
> +- compatible:		Should be one of:
> +			"st,stm32-romem"
> +			"st,stm32mp15-bsec"
> +- reg:			Offset and length of factory-programmed area.
> +- #address-cells:	Should be '<1>'.
> +- #size-cells:		Should be '<1>'.
> +
> +Optional Data cells:
> +- Must be child nodes as described in nvmem.txt.
> +
> +Example on stm32f4:
> +	romem: nvmem@1fff7800 {
> +		compatible = "st,stm32-romem";
> +		reg = <0x1fff7800 0x400>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		/* Data cells: ts_cal1 at 0x1fff7a2c */
> +		ts_cal1: calib@22c {
> +			reg = <0x22c 0x2>;
> +		};
> +		...
> +	};
> -- 
> 1.9.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: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: srinivas.kandagatla@linaro.org, alexandre.torgue@st.com,
	mark.rutland@arm.com, mcoquelin.stm32@gmail.com,
	lionel.debieve@st.com, devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem
Date: Mon, 25 Feb 2019 10:53:07 -0600	[thread overview]
Message-ID: <20190225165307.GA26260@bogus> (raw)
In-Reply-To: <1548866336-14765-2-git-send-email-fabrice.gasnier@st.com>

On Wed, Jan 30, 2019 at 05:38:53PM +0100, Fabrice Gasnier wrote:
> Add documentation for STMicroelectronics STM32 Factory-programmed
> read only memory area.
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
>  .../devicetree/bindings/nvmem/st,stm32-romem.txt   | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> new file mode 100644
> index 0000000..fbff52e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
> @@ -0,0 +1,31 @@
> +STMicroelectronics STM32 Factory-programmed data device tree bindings
> +
> +This represents STM32 Factory-programmed read only non-volatile area: locked
> +flash, OTP, read-only HW regs... This contains various information such as:

Several distinct types here. Does s/w need to know the difference 
rather than just one generic-ish compatible? Access size restrictions 
maybe? Ability to unlock and program?

If not, then why even make this stm32 specific?

> +analog calibration data for temperature sensor (e.g. TS_CAL1, TS_CAL2),
> +internal vref (VREFIN_CAL), unique device ID...
> +
> +Required properties:
> +- compatible:		Should be one of:
> +			"st,stm32-romem"
> +			"st,stm32mp15-bsec"
> +- reg:			Offset and length of factory-programmed area.
> +- #address-cells:	Should be '<1>'.
> +- #size-cells:		Should be '<1>'.
> +
> +Optional Data cells:
> +- Must be child nodes as described in nvmem.txt.
> +
> +Example on stm32f4:
> +	romem: nvmem@1fff7800 {
> +		compatible = "st,stm32-romem";
> +		reg = <0x1fff7800 0x400>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +
> +		/* Data cells: ts_cal1 at 0x1fff7a2c */
> +		ts_cal1: calib@22c {
> +			reg = <0x22c 0x2>;
> +		};
> +		...
> +	};
> -- 
> 1.9.1
> 

  parent reply	other threads:[~2019-02-25 16:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 16:38 [PATCH 0/4] Add nvmem support on STM32 Fabrice Gasnier
2019-01-30 16:38 ` Fabrice Gasnier
2019-01-30 16:38 ` Fabrice Gasnier
2019-01-30 16:38 ` [PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-02-18 13:20   ` Fabrice Gasnier
2019-02-18 13:20     ` Fabrice Gasnier
2019-02-18 13:20     ` Fabrice Gasnier
2019-02-25 16:53   ` Rob Herring [this message]
2019-02-25 16:53     ` Rob Herring
2019-02-26  9:14     ` Fabrice Gasnier
2019-02-26  9:14       ` Fabrice Gasnier
2019-02-26  9:14       ` Fabrice Gasnier
2019-02-26 17:58       ` Rob Herring
2019-02-26 17:58         ` Rob Herring
2019-01-30 16:38 ` [PATCH 2/4] nvmem: Add driver for STM32 factory-programmed read only mem Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38 ` [PATCH 3/4] nvmem: stm32: add support for STM32MP15 BSEC to control OTP data Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38 ` [PATCH 4/4] ARM: dts: stm32: Add romem and temperature calibration on stm32mp157c Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-01-30 16:38   ` Fabrice Gasnier
2019-02-13 10:15 ` [PATCH 0/4] Add nvmem support on STM32 Fabrice Gasnier
2019-02-13 10:15   ` Fabrice Gasnier
2019-02-13 10:15   ` Fabrice Gasnier
2019-02-13 10:34   ` Srinivas Kandagatla
2019-02-13 10:34     ` Srinivas Kandagatla
2019-02-14 10:36     ` Fabrice Gasnier
2019-02-14 10:36       ` Fabrice Gasnier
2019-02-14 10:36       ` Fabrice Gasnier

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=20190225165307.GA26260@bogus \
    --to=robh@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrice.gasnier@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=lionel.debieve@st.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --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.