From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Hector Martin" <marcan@marcan.st>,
"Sven Peter" <sven@svenpeter.dev>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"NXP Linux Team" <linux-imx@nxp.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Claudiu Beznea" <claudiu.beznea@microchip.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Andy Gross" <agross@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Orson Zhai" <orsonzhai@gmail.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Chunyan Zhang" <zhang.lyra@gmail.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Vincent Shih" <vincent.sunplus@gmail.com>,
"Chen-Yu Tsai" <wens@csie.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Samuel Holland" <samuel@sholland.org>,
"Kunihiko Hayashi" <hayashi.kunihiko@socionext.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Michal Simek" <michal.simek@xilinx.com>,
"Alessandro Zummo" <a.zummo@towertech.it>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Evgeniy Polyakov" <zbr@ioremap.net>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-sunxi@lists.linux.dev, linux-rtc@vger.kernel.org,
"Michael Walle" <michael@walle.cc>,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V3] nvmem: add explicit config option to read OF fixed cells
Date: Thu, 9 Mar 2023 14:19:20 +0100 [thread overview]
Message-ID: <20230309141920.1d3f774e@xps-13> (raw)
In-Reply-To: <e845b38c-d0eb-716c-dc51-b89582750f07@gmail.com>
Hi Rafał,
zajec5@gmail.com wrote on Thu, 9 Mar 2023 13:01:19 +0100:
> On 9.03.2023 12:35, Miquel Raynal wrote:
> >> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> >> index 0262b86194eb..b3c14ce87a65 100644
> >> --- a/include/linux/nvmem-provider.h
> >> +++ b/include/linux/nvmem-provider.h
> >> @@ -73,6 +73,7 @@ struct nvmem_cell_info {
> >> * @owner: Pointer to exporter module. Used for refcounting.
> >> * @cells: Optional array of pre-defined NVMEM cells.
> >> * @ncells: Number of elements in cells.
> >> + * @use_fixed_of_cells: Read fixed NVMEM cells from OF.
> >
> > I'm still unhappy with the naming, especially since you explained in
> > more details the whole plan which involves using a container to put
> > these fixed cells from now on. In both cases you extract cells from
> > fixed OF nodes but this boolean needs to be set to true in one
> > case, and false in the other, which would not make sense.
> >
> > Also, regarding the bindings changes, I'm fairly happy with the idea,
> > but if we go this way I would prefer a full series instead of
> > individual changes with:
> >
> > - the boolean you introduce here (renamed, at the very least)
> > - the new bindings
>
> I assume you mean fixed-layout.yaml?
Yes!
> > - the update of the current provider bindings to take the new bindings
> > into account and deprecate the old ones officially
>
> What has to be updated in current proceds? It seems to me that:
> 1. Current NVMEM providers reference nvmem.yaml
> 2. nvmem.yaml references nvmem-layout.yaml
> 3. nvmem-layout.yaml references fixed-layout.yaml
>
> what else is missing?
That's the theory, but then provider bindings should reflect the
changes as well in their own binding documents.
IOW, this one (and all its cousins) becomes legacy and must be updated:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml#L92
(and there are many files to update then)
>
>
> > - support for the new bindings in the core
>
> Please, don't get me wrong, but I'm not going to spend more hours on
> actual coding without approval of chosen path.
Well, you want to make the bindings evolve. Just updating a single
binding file is not enough, I believe we should at least provide full
support for the new description. But of course I'm fine discussing what
description we want first.
> I'll need to have
> [PATCH V2] dt-bindings: nvmem: layouts: add fixed-layout
> reviewed/acked first. If you can do that that's great.
>
>
> >> * @keepout: Optional array of keepout ranges (sorted ascending by start).
> >> * @nkeepout: Number of elements in the keepout array.
> >> * @type: Type of the nvmem storage
> >> @@ -103,6 +104,7 @@ struct nvmem_config {
> >> struct module *owner;
> >> const struct nvmem_cell_info *cells;
> >> int ncells;
> >> + bool use_fixed_of_cells;
> >> const struct nvmem_keepout *keepout;
> >> unsigned int nkeepout;
> >> enum nvmem_type type;
> >
> > Thanks,
> > Miquèl
>
Thanks,
Miquèl
next prev parent reply other threads:[~2023-03-09 13:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 11:20 [PATCH V3] nvmem: add explicit config option to read OF fixed cells Rafał Miłecki
2023-03-09 11:35 ` Miquel Raynal
2023-03-09 12:01 ` Rafał Miłecki
2023-03-09 13:19 ` Miquel Raynal [this message]
2023-03-10 9:22 ` Srinivas Kandagatla
2023-03-10 10:43 ` Rafał Miłecki
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=20230309141920.1d3f774e@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=agross@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=alyssa@rosenzweig.io \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=asahi@lists.linux.dev \
--cc=baolin.wang@linux.alibaba.com \
--cc=claudiu.beznea@microchip.com \
--cc=festevam@gmail.com \
--cc=hayashi.kunihiko@socionext.com \
--cc=heiko@sntech.de \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=konrad.dybcio@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=marcan@marcan.st \
--cc=martin.blumenstingl@googlemail.com \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mhiramat@kernel.org \
--cc=michael@walle.cc \
--cc=michal.simek@xilinx.com \
--cc=neil.armstrong@linaro.org \
--cc=orsonzhai@gmail.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=s.hauer@pengutronix.de \
--cc=samuel@sholland.org \
--cc=shawnguo@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=sven@svenpeter.dev \
--cc=vigneshr@ti.com \
--cc=vincent.sunplus@gmail.com \
--cc=wens@csie.org \
--cc=zajec5@gmail.com \
--cc=zbr@ioremap.net \
--cc=zhang.lyra@gmail.com \
/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