diff mbox series

[v2,13/17] dt-bindings: mtd: nvmem-cells: Fix example

Message ID 20221104164718.1290859-14-miquel.raynal@bootlin.com
State New
Headers
Series Improve MTD bindings |

Commit Message

Miquel Raynal Nov. 4, 2022, 4:47 p.m. UTC 
  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.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 .../devicetree/bindings/mtd/partitions/nvmem-cells.yaml          | 1 -
 1 file changed, 1 deletion(-)

Comments

Rob Herring Nov. 10, 2022, 4:59 p.m. UTC | #1 
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
Miquel Raynal Nov. 10, 2022, 5:28 p.m. UTC | #2 
Hi Rob,

robh@kernel.org wrote on Thu, 10 Nov 2022 10:59:06 -0600:

> 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.

Ah ok, I missed this possibility indeed, thanks for the explanation.

So I agree the commit log is wrong, but I guess the change itself
is fine because the property should be declared/authorized in the
schema. So here we have two options:
1- Document the property
2- Drop the property from the example

As we currently have no user upstream of this property I would argue we
can keep dropping 'ranges' from the example, knowing of course that
someone might come up some day and document it properly if it is
needed. In this case I would update the commit message to:

	dt-bindings: mtd: nvmem-cells: Drop range property from example

	Memory mapped devices such as parallel NOR flash could make use
	of the 'ranges' property to translate a nvmem 'reg' cell
	address to a CPU address but in practice there is no upstream
	user nor any declaration of this property being valid in this
	case.

	In order to avoid warnings when constraining a bit more the
	schema, let's drop the property from the example, knowing that
	someone might actually properly define it some day.

Would you agree with this change?

Thanks,
Miquèl
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
index 5cdd2efa9132..ca18892eacc7 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
@@ -84,7 +84,6 @@  examples:
             compatible = "nvmem-cells";
             label = "calibration";
             reg = <0xf00000 0x100000>;
-            ranges = <0 0xf00000 0x100000>;
             #address-cells = <1>;
             #size-cells = <1>;