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

["Rafał Miłecki" <zajec5@gmail.com>]

On 10.03.2023 09:59, Miquel Raynal wrote:
> Hi Rafał,
> 
> zajec5@gmail.com wrote on Fri, 10 Mar 2023 08:51:45 +0100:
> 
>> From: Rafał Miłecki <rafal@milecki.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@milecki.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>;
>> +              };
>>             };
>>         };