From: Rob Herring <robh@kernel.org>
To: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Lionel Debieve <lionel.debieve@st.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
linux-stm32@st-md-mailman.stormreply.com,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem
Date: Tue, 26 Feb 2019 11:58:09 -0600 [thread overview]
Message-ID: <CAL_JsqLKcJiZCUp1FW4E7-5uC8v1Af0TZsiPympX9HsYE1N_dQ@mail.gmail.com> (raw)
In-Reply-To: <d2473029-76a7-de2c-8ff5-9d065577f0b1@st.com>
On Tue, Feb 26, 2019 at 3:14 AM Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
>
> On 2/25/19 5:53 PM, Rob Herring wrote:
> > 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?
>
> Hi Rob,
>
> The reading part is represented here as "st,stm32-romem" compatible, to
> simply handle read only access. I agree this could be a generic-ish.
>
> BUT the specifics are regarding the ability to unlock/lock and program.
> Access size can vary from one part to another (e.g. on stm32f4,
> reference manual sates: OTP area is divided into 16 OTP data blocks of
> 32 bytes. on stm32f7, OTP area is divided into 16 OTP data blocks of 64
> bytes.)
>
> In STM32MP15, both the read & write access through the BSEC are
> specific, represented by dedicated compatible.
>
> Do you wish I update the compatible to something like:
> "st,stm32f4-otp"
> "st,stm32mp15-bsec"
> ?
Yes, I think given the above that makes sense. We can always map
specific bindings to generic drivers, but not the reverse.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-02-26 17:58 UTC|newest]
Thread overview: 12+ 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 ` [PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem Fabrice Gasnier
2019-02-18 13:20 ` Fabrice Gasnier
2019-02-25 16:53 ` Rob Herring
2019-02-26 9:14 ` Fabrice Gasnier
2019-02-26 17:58 ` Rob Herring [this message]
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 ` [PATCH 3/4] nvmem: stm32: add support for STM32MP15 BSEC to control OTP data Fabrice Gasnier
2019-01-30 16:38 ` [PATCH 4/4] ARM: dts: stm32: Add romem and temperature calibration on stm32mp157c Fabrice Gasnier
2019-02-13 10:15 ` [PATCH 0/4] Add nvmem support on STM32 Fabrice Gasnier
2019-02-13 10:34 ` Srinivas Kandagatla
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=CAL_JsqLKcJiZCUp1FW4E7-5uC8v1Af0TZsiPympX9HsYE1N_dQ@mail.gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).