Re: [PATCH 2/4] dt-bindings: hwinfo: ti,k3-socinfo: Add nvmem-cells

[Krzysztof Kozlowski]

On 14/02/2024 10:31, Markus Schneider-Pargmann wrote:
> Hi Rob,
> 
> On Tue, Feb 06, 2024 at 06:43:05PM +0000, Rob Herring wrote:
>> On Tue, Feb 06, 2024 at 03:37:09PM +0100, Markus Schneider-Pargmann wrote:
>>> The information k3-socinfo requires is stored in an efuse area. This
>>> area is required by other devices/drivers as well, so using nvmem-cells
>>> can be a cleaner way to describe which information are used.
>>>
>>> If nvmem-cells are supplied, the address range is not required.
>>> Cells chipvariant, chippartno and chipmanufacturer are introduced to
>>> cover all required information.
>>>
>>> Signed-off-by: Markus Schneider-Pargmann <msp@xxxxxxxxxxxx>
>>> Reviewed-by: Andrew Davis <afd@xxxxxx>
>>> ---
>>>  .../bindings/hwinfo/ti,k3-socinfo.yaml        | 23 ++++++++++++++++++-
>>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> index dada28b47ea0..f085b7275b7d 100644
>>> --- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> @@ -26,9 +26,24 @@ properties:
>>>    reg:
>>>      maxItems: 1
>>>  
>>> +  nvmem-cells:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  nvmem-cell-names:
>>> +    items:
>>> +      - const: chipvariant
>>> +      - const: chippartno
>>> +      - const: chipmanufacturer
>>> +
>>>  required:
>>>    - compatible
>>> -  - reg
>>> +
>>> +oneOf:
>>> +  - required:
>>> +      - reg
>>> +  - required:
>>> +      - nvmem-cells
>>> +      - nvmem-cell-names
>>>  
>>>  additionalProperties: false
>>>  
>>> @@ -38,3 +53,9 @@ examples:
>>>          compatible = "ti,am654-chipid";
>>>          reg = <0x43000014 0x4>;
>>>      };
>>> +  - |
>>> +    chipid: chipid@14 {
>>> +        compatible = "ti,am654-chipid";
>>
>> This isn't compatible if you have a completely different way to access 
>> it. 
> 
> Thanks, it is not entirely clear to me how I could go forward with this?
> Are you suggesting to use a different compatible? Or is it something
> else I could do to proceed with this conversion?

What you claim now, is that you have one device with entirely different
interfaces and programming model. So either this is not the same device
or you just wrote bindings to whatever you have in driver.

Nothing in commit msg explains this.

What you should do? Depends. If you just write bindings for driver, then
stop. It's a NAK. Instead write bindings for hardware.

If the first choice, just the hardware is somehow like this, then
explain in commit msg and device description, how this device can be
connected over other bus, not MMIO. You can draw some schematics in
commit msg explaining architecture etc.

Best regards,
Krzysztof