From: Michael Walle <michael@walle.cc>
To: zajec5@gmail.com
Cc: a.zummo@towertech.it, agross@kernel.org,
alexandre.belloni@bootlin.com, alexandre.torgue@foss.st.com,
alyssa@rosenzweig.io, andersson@kernel.org,
angelogioacchino.delregno@collabora.com, asahi@lists.linux.dev,
baolin.wang@linux.alibaba.com, claudiu.beznea@microchip.com,
festevam@gmail.com, hayashi.kunihiko@socionext.com,
heiko@sntech.de, jbrunet@baylibre.com, jernej.skrabec@gmail.com,
kernel@pengutronix.de, khilman@baylibre.com,
konrad.dybcio@linaro.org, linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-imx@nxp.com,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-mtd@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-rtc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-sunxi@lists.linux.dev, marcan@marcan.st,
martin.blumenstingl@googlemail.com, matthias.bgg@gmail.com,
mcoquelin.stm32@gmail.com, mhiramat@kernel.org,
michal.simek@xilinx.com, miquel.raynal@bootlin.com,
neil.armstrong@linaro.org, orsonzhai@gmail.com, rafal@milecki.pl,
richard@nod.at, s.hauer@pengutronix.de, samuel@sholland.org,
shawnguo@kernel.org, srinivas.kandagatla@linaro.org,
sven@svenpeter.dev, vigneshr@ti.com, vincent.sunplus@gmail.com,
wens@csie.org, zbr@ioremap.net, zhang.lyra@gmail.com,
Michael Walle <michael@walle.cc>
Subject: Re: [PATCH V2] nvmem: add explicit config option to read OF fixed cells
Date: Thu, 9 Mar 2023 10:40:10 +0100 [thread overview]
Message-ID: <20230309094010.1051573-1-michael@walle.cc> (raw)
In-Reply-To: <20230224072903.20945-1-zajec5@gmail.com>
[as this mentions nvmem layouts it would have been nice to include me]
> NVMEM subsystem looks for fixed NVMEM cells (specified in DT) by
> default. This behaviour made sense in early days before adding support
> for dynamic cells.
Why is that? It still makes sense, doesn't it?
> With every new supported NVMEM device with dynamic cells current
> behaviour becomes non-optimal. It results in unneeded iterating over DT
> nodes and may result in false discovery of cells (depending on used DT
> properties).
What false discoveries?
> This behaviour has actually caused a problem already with the MTD
> subsystem. MTD subpartitions were incorrectly treated as NVMEM cells.
But this is solved, correct?
> Also with upcoming support for NVMEM layouts no new binding or driver
> should support fixed cells defined in device node.
How would you support older device trees with newer kernels or the
other way around? I'm not sure I get your motivation to drop handling
the fixed cells.
> Solve this by modifying drivers for bindings that support specifying
> fixed NVMEM cells in DT. Make them explicitly tell NVMEM subsystem to
> read cells from DT.
How can a driver know when there are fixed cells and when not? IOW.
only new ones can be affected.
If you want to get rid of the schema for *new* drivers then what
about having a new child node, something like "nvmem-fixed-cells",
similar to "nvmem-layout".
And then you'd tell the new drivers to use the new-style dt binding. But
there are no new drivers yet. So I'm still not sure I get your motivation.
-michael
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
prev parent reply other threads:[~2023-03-09 9:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 7:29 [PATCH V2] nvmem: add explicit config option to read OF fixed cells Rafał Miłecki
2023-02-24 13:13 ` AngeloGioacchino Del Regno
2023-02-24 16:31 ` Claudiu.Beznea
2023-03-08 16:34 ` Miquel Raynal
2023-03-08 16:55 ` Rafał Miłecki
2023-03-08 18:06 ` Miquel Raynal
2023-03-08 18:12 ` Rafał Miłecki
2023-03-08 18:31 ` Miquel Raynal
2023-03-09 6:56 ` Rafał Miłecki
2023-03-09 8:34 ` Miquel Raynal
2023-03-09 8:39 ` Rafał Miłecki
2023-03-09 8:56 ` Miquel Raynal
2023-03-09 9:37 ` Srinivas Kandagatla
2023-03-09 9:40 ` Michael Walle [this message]
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=20230309094010.1051573-1-michael@walle.cc \
--to=michael@walle.cc \
--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=michal.simek@xilinx.com \
--cc=miquel.raynal@bootlin.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