| Message ID | 20221104164718.1290859-14-miquel.raynal@bootlin.com |
|---|---|
| State | Handled Elsewhere |
| Delegated to: | Miquel Raynal |
| Headers | show |
| Series | Improve MTD bindings | expand |
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
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 --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>;
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(-)