linux-kernel - Re: [PATCH V3] dt-bindings: nvmem: convert base example to use "nvmem-layout" node

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]

Date:   Fri, 10 Mar 2023 10:29:00 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Michael Walle <michael@...le.cc>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH V3] dt-bindings: nvmem: convert base example to use
 "nvmem-layout" node

On 10.03.2023 09:59, Miquel Raynal wrote:
> Hi Rafał,
> 
> zajec5@...il.com wrote on Fri, 10 Mar 2023 08:51:45 +0100:
> 
>> From: Rafał Miłecki <rafal@...ecki.pl>
>>
>> With support for "fixed-layout" binding we can use now "nvmem-layout"
>> even for fixed NVMEM cells. Use that in the base example as it should be
>> preferred over placing cells directly in the device node.
>>
>> New and other bindings should follow as old binding will get deprecated
>> at some point.
>>
>> Signed-off-by: Rafał Miłecki <rafal@...ecki.pl>
>> ---
>>   .../devicetree/bindings/nvmem/nvmem.yaml      | 42 +++++++++++--------
>>   1 file changed, 24 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>> index 732162e9d13e..c77be1c20e47 100644
>> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>> @@ -67,24 +67,30 @@ examples:
>>   
>>             /* ... */
>>   
>> -          /* Data cells */
>> -          tsens_calibration: calib@404 {
>> -              reg = <0x404 0x10>;
>> -          };
>> -
>> -          tsens_calibration_bckp: calib_bckp@504 {
>> -              reg = <0x504 0x11>;
>> -              bits = <6 128>;
>> -          };
>> -
>> -          pvs_version: pvs-version@6 {
>> -              reg = <0x6 0x2>;
>> -              bits = <7 2>;
>> -          };
>> -
>> -          speed_bin: speed-bin@c{
>> -              reg = <0xc 0x1>;
>> -              bits = <2 3>;
>> +          nvmem-layout {
> 
> I believe we should not introduce "intermediate state" bindings when
> this is not strictly required, in order to avoid confusion with what is
> backward and what is transitory. So I would expect this to only apply
> after the switch to:
> 
> 	nvmem-layout@xxx {
> 		reg = <xxx>;
> 
> I don't care who will take care of it, but I think it would be better
> to have everything in one series.
> 
> Other than the "order" problematic which I think is important here, I
> agree with this series.

I fail to see how / why:
1. Adding new NVMEM layout
2. Supporting mutliple NVMEM layouts
would depend on each other.

We already have 2 NVMEM layouts bindings. I'm just adding a new (third)
one.

If having NVMEM layouts bindings puts us in any kind of intermediate
state then we're already there. I don't think my new NVMEM layout
changes this situation.


>> +              compatible = "fixed-layout";
>> +              #address-cells = <1>;
>> +              #size-cells = <1>;
>> +
>> +              /* Data cells */
>> +              tsens_calibration: calib@404 {
>> +                  reg = <0x404 0x10>;
>> +              };
>> +
>> +              tsens_calibration_bckp: calib_bckp@504 {
>> +                  reg = <0x504 0x11>;
>> +                  bits = <6 128>;
>> +              };
>> +
>> +              pvs_version: pvs-version@6 {
>> +                  reg = <0x6 0x2>;
>> +                  bits = <7 2>;
>> +              };
>> +
>> +              speed_bin: speed-bin@c{
>> +                  reg = <0xc 0x1>;
>> +                  bits = <2 3>;
>> +              };
>>             };
>>         };