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