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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <013e44c6-45f5-44c1-94b3-536955fae78f@amd.com>
Date:   Fri, 13 Oct 2023 13:51:30 +0200
From:   Michal Simek <michal.simek@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        "Praveen Teja Kundanala" <praveen.teja.kundanala@....com>,
        <srinivas.kandagatla@...aro.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] dt-bindings: nvmem: Convert xlnx,zynqmp-nvmem.txt to
 yaml



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

Thanks,
Michal