linux-kernel - Re: [PATCH] dt-bindings: firmware: xilinx: Describe soc-vvmem subnode

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: <ec0f347c-483d-47d2-b868-0c64070cc153@amd.com>
Date: Tue, 30 Jan 2024 08:13:09 +0100
From: Michal Simek <michal.simek@....com>
To: Conor Dooley <conor@...nel.org>
Cc: linux-kernel@...r.kernel.org, monstr@...str.eu, michal.simek@...inx.com,
 git@...inx.com, Conor Dooley <conor+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Rob Herring <robh+dt@...nel.org>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, kishore Manne <nava.kishore.manne@....com>,
 "moderated list:ARM/ZYNQ ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] dt-bindings: firmware: xilinx: Describe soc-vvmem subnode



On 1/29/24 17:57, Conor Dooley wrote:
> On Mon, Jan 29, 2024 at 01:25:06PM +0100, Michal Simek wrote:
>> Describe soc-nvmem subnode as the part of firmware node. The name can't be
>> pure nvmem because dt-schema already defines it as array property that's
>> why different name should be used.
>>
>> Signed-off-by: Michal Simek <michal.simek@....com>
>> ---
>>
>> Dt binding for nvmem node has been already merged and it is the part of
>> linux-next tree.
>> Here is the reference to it just in case:
>> https://lore.kernel.org/r/170635581622.41421.8980881999042944764.b4-ty@linaro.org
>>
>> ---
>>   .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml   | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> index 7586fbff7ad6..108772ef574f 100644
>> --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>> @@ -62,6 +62,12 @@ properties:
>>         interface.
>>       type: object
>>   
>> +  soc-nvmem:
>> +    $ref: /schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
>> +    description: The ZynqMP MPSoC provides access to the hardware related data
>> +      like SOC revision, IDCODE and specific purpose efuses.
>> +    type: object
>> +
>>     pcap:
>>       $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
>>       description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
>> @@ -110,6 +116,9 @@ examples:
>>       firmware {
>>         zynqmp_firmware: zynqmp-firmware {
>>           #power-domain-cells = <1>;
>> +        soc-nvmem {
>> +          compatible = "xlnx,zynqmp-nvmem-fw";
>> +        };
> 
> Would it not be better to have an actual nvmem-layout in here? The
> ~empty node here looks rather odd.

No issue. Do you want full or just nvmem-layout with compatible string (which is
required)?
        soc-nvmem {
            compatible = "xlnx,zynqmp-nvmem-fw";
            nvmem-layout {
                compatible = "fixed-layout";
                #address-cells = <1>;
                #size-cells = <1>;

                soc_revision: soc-revision@0 {
                    reg = <0x0 0x4>;
                };
            };
        };


> 
> Also, there's a type in $subject of nvmem.

will fix.

Thanks,
Michal