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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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