From: Rob Herring <robh@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Pratyush Yadav <p.yadav@ti.com>, Michael Walle <michael@walle.cc>,
linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 13/17] dt-bindings: mtd: nvmem-cells: Fix example
Date: Thu, 10 Nov 2022 10:59:06 -0600 [thread overview]
Message-ID: <20221110165906.GA241353-robh@kernel.org> (raw)
In-Reply-To: <20221104164718.1290859-14-miquel.raynal@bootlin.com>
On Fri, Nov 04, 2022 at 05:47:14PM +0100, Miquel Raynal wrote:
> There is no such thing as a "ranges" property within an nvmem-cells
> node. There is no use of it, it is anyway not pictured anywhere that
> this is valid, so drop it from the example.
For a memory mapped device such as parallel NOR flash. It would be
perfectly fine to translate a nvmem cell 'reg' address to a CPU address.
If the partitions are not memory mapped, then it's a gray area. Whether
it makes sense to translate just to just the absolute offset of the
flash device, maybe or maybe not. At a minimum, 'ranges' just means
can translate to the parent address space. The Linux DT translate code
only supports the full translation to CPU addresses, but then it mainly
just supports creating resources.
Rob
next prev parent reply other threads:[~2022-11-10 16:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 16:47 [PATCH v2 00/17] Improve MTD bindings Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 01/17] dt-bindings: mtd: Clarify all partition subnodes Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 02/17] dt-bindings: mtd: Remove useless file about partitions Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 03/17] dt-bindings: mtd: nand-chip: Reference mtd.yaml Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 04/17] dt-bindings: mtd: nand: Drop common properties already defined in generic files Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 05/17] dt-bindings: mtd: nand: Standardize the child node name Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 06/17] dt-bindings: mtd: ingenic: Mark partitions in the controller node as deprecated Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 07/17] dt-bindings: mtd: onenand: Mention the expected node name Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 08/17] dt-bindings: mtd: sunxi-nand: Add an example to validate the bindings Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 09/17] dt-bindings: mtd: spi-nor: Drop common properties Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 10/17] dt-bindings: mtd: physmap: Reuse the generic definitions Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 11/17] dt-bindings: mtd: partitions: Constrain the list of parsers Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 12/17] dt-bindings: mtd: partitions: Change qcom,smem-part partition type Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 13/17] dt-bindings: mtd: nvmem-cells: Fix example Miquel Raynal
2022-11-10 16:59 ` Rob Herring [this message]
2022-11-10 17:28 ` Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 14/17] dt-bindings: mtd: nvmem-cells: Inherit from MTD partitions Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 15/17] dt-bindings: mtd: Argue in favor of keeping additionalProperties set to true Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 16/17] dt-bindings: mtd: Drop object types when referencing other files Miquel Raynal
2022-11-04 16:47 ` [PATCH v2 17/17] dt-bindings: mtd: Standardize the style in the examples Miquel Raynal
2022-11-10 17:03 ` [PATCH v2 00/17] Improve MTD bindings Rob Herring
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=20221110165906.GA241353-robh@kernel.org \
--to=robh@kernel.org \
--cc=Tudor.Ambarus@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=srinivas.kandagatla@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.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;
as well as URLs for NNTP newsgroup(s).