Messages in this thread | | | Date | Fri, 13 Oct 2023 14:08:42 +0200 | Subject | Re: [PATCH 2/5] dt-bindings: nvmem: Convert xlnx,zynqmp-nvmem.txt to yaml | From | 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
| |