Re: [PATCH 2/5] dt-bindings: nvmem: Convert xlnx,zynqmp-nvmem.txt to yaml

[Michal Simek]

On 10/13/23 13:58, Krzysztof Kozlowski wrote:
> On 13/10/2023 13:51, Michal Simek wrote:
> > On 10/13/23 13:46, Krzysztof Kozlowski wrote:
> > > On 13/10/2023 13:22, Michal Simek wrote:
> > > > > > +
> > > > > > +required:
> > > > > > +  - compatible
> > > > >
> > > > > required: block goes after patternProperties: block
> > > > >
> > > > > > +
> > > > > > +patternProperties:
> > > > > > +  "^soc_revision@0$":
> > > > >
> > > > > Why do you define individual memory cells? Is this part of a binding?
> > > > > IOW, OS/Linux requires this?
> > > >
> > > > nvmem has in kernel interface where you can reference to nodes. nvmem_cell_get()
> > > > calls. It means you should be able to describe internal layout that's why names
> > > > are used. And address in name is there because of reg property is used to
> > > > describe base offset and size.
> > >
> > > That's not really what I am asking. Why internal layout of memory must
> > > be part of the bindings?
> >
> > It doesn't need to be but offsets are hardcoded inside the driver itself and
> > they can't be different.
>
> Hm, where? I opened drivers/nvmem/zynqmp_nvmem.c and I do not see any
> hard-coded offsets.

Current driver supports only soc revision from offset 0.
But if you look at 5/5 you need to define offsets where information is present.
+#define SOC_VERSION_OFFSET	0x0
+#define EFUSE_START_OFFSET	0xC
+#define EFUSE_END_OFFSET	0xFC
+#define EFUSE_PUF_START_OFFSET	0x100
+#define EFUSE_PUF_MID_OFFSET	0x140
+#define EFUSE_PUF_END_OFFSET	0x17F


> >   On different nvmem locations like MAC location in
> > eeprom this can vary across boards but in this case location has to be only like
> > this.
> > I am fine if they don't need to be actually check but there is no any other way
> > how they can be composed. And also others are not valid that's why not to
> > describe only valid one.
>
> OK, that would be valid (if I find anywhere the offsets) and answers my
> questions but I wish it was documented somewhere. Because now you are
> making it a binding, so it cannot change (e.g. for different devices
> with same hardware but different firmware or manufacturing process, for
> future hardware sharing this binding).

ZynqMP firmware with xlnx,zynqmp-nvmem-fw compatible string is using this map.
If there is different firmware likely xlnx,zynqmp-nvmem-fw compatible string 
can't be used.

> In any case the binding should have only items which are really fixed
> and OS depends on them. Neither this nor next commit answers this.

Actually 5/5 has this in commit message
	0 - SOC version(read only)
	0xC - 0xFC -ZynqMP specific purpose efuses
	0x100 - 0x17F - Physical Unclonable Function(PUF)
                efuses repurposed as user efuses

Thanks,
Michal