[PATCH 1/3] [RFC] dt-bindings: nvmem: syscon: Add syscon backed nvmem bindings

[Marek Vasut]

On 10/28/22 23:28, Rob Herring wrote:
> On Fri, Oct 28, 2022 at 12:50:18AM +0200, Marek Vasut wrote:
>> Add trivial bindings for driver which permits exposing syscon backed
>> register to userspace. This is useful e.g. to expose U-Boot boot
>> counter on various platforms where the boot counter is stored in
>> random volatile register, like STM32MP15xx TAMP_BKPxR register.
> 
> Generic bindings always start trivial until they get appended one
> property at a time...
> 
> What happens when you have more than 1 field and/or more than 1
> register?

If it is a continuous register array, the user can use the size field to 
describe such register array here.

If it is a sparse register array, multiple nvmem-syscon nodes would be 
needed. I haven't seen anything which would require one node for sparse 
register arrays, like boot counter distributed across multiple 
non-continuous registers or such.

>> +properties:
>> +  compatible:
>> +    enum:
>> +      - nvmem-syscon
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    tamp at 5c00a000 {
>> +        compatible = "st,stm32-tamp", "syscon", "simple-mfd";
> 
> This is very common, but personally I think "syscon" and "simple-mfd"
> should be mutually exclusive. "simple-mfd" is saying the children have
> no dependency on the parent, yet the child nodes need a regmap from the
> parent. Sounds like a dependency.

So what exactly should be changed here?

>> +        reg = <0x5c00a000 0x400>;
>> +
>> +        nvmem-syscon {
>> +            compatible = "nvmem-syscon";
>> +            reg = <0x14c 0x4>;
> 
> How does one identify this is the bootloader's boot count?

The user has to know where the boot counter is stored (by hardware 
path). I wouldn't attempt to assign any complex logic here, since the 
boot counter could be implemented in various ways. Besides, this may not 
even be a boot counter, but some other variable exposed to user space. 
Maybe a unique node name can be used to discern the different 
nvmem-syscon nodes representing different variables if needed.

> How does the
> bootloader know it can write to this?

The bootloader implementer selected the bootcounter register based on 
hardware knowledge .