[PATCH 0/2] nvmem: add Microchip OTP controller

[PATCH 0/2] nvmem: add Microchip OTP controller

[Claudiu Beznea]

Hi,

This series adds support for Microchip OTP controller available on
SAMA7G5. The driver gives access to a non-volatile memory which
keeps (at the moment) information like booting media and temperature
calibration data used for thermal measurements.

Thank you,
Claudiu Beznea

Claudiu Beznea (2):
  dt-bindings: microchip-otpc: document Microchip OTPC
  nvmem: microchip-otpc: add support

 .../bindings/nvmem/microchip-otpc.yaml        |  55 ++++
 MAINTAINERS                                   |   8 +
 drivers/nvmem/Kconfig                         |   7 +
 drivers/nvmem/Makefile                        |   2 +
 drivers/nvmem/microchip-otpc.c                | 288 ++++++++++++++++++
 include/dt-bindings/nvmem/microchip,otpc.h    |  18 ++
 6 files changed, 378 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
 create mode 100644 drivers/nvmem/microchip-otpc.c
 create mode 040000 include/dt-bindings/nvmem
 create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h

-- 
2.34.1

[PATCH 0/2] nvmem: add Microchip OTP controller

[Claudiu Beznea]

Hi,

This series adds support for Microchip OTP controller available on
SAMA7G5. The driver gives access to a non-volatile memory which
keeps (at the moment) information like booting media and temperature
calibration data used for thermal measurements.

Thank you,
Claudiu Beznea

Claudiu Beznea (2):
  dt-bindings: microchip-otpc: document Microchip OTPC
  nvmem: microchip-otpc: add support

 .../bindings/nvmem/microchip-otpc.yaml        |  55 ++++
 MAINTAINERS                                   |   8 +
 drivers/nvmem/Kconfig                         |   7 +
 drivers/nvmem/Makefile                        |   2 +
 drivers/nvmem/microchip-otpc.c                | 288 ++++++++++++++++++
 include/dt-bindings/nvmem/microchip,otpc.h    |  18 ++
 6 files changed, 378 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
 create mode 100644 drivers/nvmem/microchip-otpc.c
 create mode 040000 include/dt-bindings/nvmem
 create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu Beznea]

Document Microchip OTP controller.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
 include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
 2 files changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
 create mode 040000 include/dt-bindings/nvmem
 create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h

diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
new file mode 100644
index 000000000000..a8df7fee5c2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings
+
+maintainers:
+  - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+  This binding represents the OTP controller found on SAMA7G5 SoC.
+
+allOf:
+  - $ref: "nvmem.yaml#"
+
+properties:
+  compatible:
+    items:
+      - const: microchip,sama7g5-otpc
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/at91.h>
+    #include <dt-bindings/nvmem/microchip,otpc.h>
+
+    otpc: efuse@e8c00000 {
+        compatible = "microchip,sama7g5-otpc", "syscon";
+        reg = <0xe8c00000 0xec>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        temperature_calib: calib@1 {
+            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
+        };
+    };
+
+...
diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
new file mode 100644
index 000000000000..44b6ed3b8f18
--- /dev/null
+++ b/include/dt-bindings/nvmem/microchip,otpc.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
+#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
+
+/*
+ * Need to have it as a multiple of 4 as NVMEM memory is registered with
+ * stride = 4.
+ */
+#define OTP_PKT(id)			((id) * 4)
+
+/*
+ * Temperature calibration packet length for SAMA7G5: 1 words header,
+ * 18 words payload.
+ */
+#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN	(19 * 4)
+
+#endif
-- 
2.34.1

[PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu Beznea]

Document Microchip OTP controller.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
 include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
 2 files changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
 create mode 040000 include/dt-bindings/nvmem
 create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h

diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
new file mode 100644
index 000000000000..a8df7fee5c2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings
+
+maintainers:
+  - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+  This binding represents the OTP controller found on SAMA7G5 SoC.
+
+allOf:
+  - $ref: "nvmem.yaml#"
+
+properties:
+  compatible:
+    items:
+      - const: microchip,sama7g5-otpc
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/at91.h>
+    #include <dt-bindings/nvmem/microchip,otpc.h>
+
+    otpc: efuse@e8c00000 {
+        compatible = "microchip,sama7g5-otpc", "syscon";
+        reg = <0xe8c00000 0xec>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        temperature_calib: calib@1 {
+            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
+        };
+    };
+
+...
diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
new file mode 100644
index 000000000000..44b6ed3b8f18
--- /dev/null
+++ b/include/dt-bindings/nvmem/microchip,otpc.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
+#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
+
+/*
+ * Need to have it as a multiple of 4 as NVMEM memory is registered with
+ * stride = 4.
+ */
+#define OTP_PKT(id)			((id) * 4)
+
+/*
+ * Temperature calibration packet length for SAMA7G5: 1 words header,
+ * 18 words payload.
+ */
+#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN	(19 * 4)
+
+#endif
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 10/05/2022 11:44, Claudiu Beznea wrote:
> Document Microchip OTP controller.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
>  .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
>  include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
>  2 files changed, 73 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>  create mode 040000 include/dt-bindings/nvmem
>  create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
> new file mode 100644
> index 000000000000..a8df7fee5c2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml

vendor,device.yaml
device should not be a wildcard but first compatible, so
microchip,sama7g5-otpc.yaml


> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings

s/device tree bindings//

> +
> +maintainers:
> +  - Claudiu Beznea <claudiu.beznea@microchip.com>
> +
> +description: |
> +  This binding represents the OTP controller found on SAMA7G5 SoC.

Entire description is duplicating title. Please describe the hardware or
skip it.

OTOH, you should mention the header, for example in description.

> +
> +allOf:
> +  - $ref: "nvmem.yaml#"
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: microchip,sama7g5-otpc
> +      - const: syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 1

These come from nvmem.yaml.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/at91.h>

How the clock is used here?

> +    #include <dt-bindings/nvmem/microchip,otpc.h>
> +
> +    otpc: efuse@e8c00000 {
> +        compatible = "microchip,sama7g5-otpc", "syscon";
> +        reg = <0xe8c00000 0xec>;
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        temperature_calib: calib@1 {
> +            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
> +        };
> +    };
> +
> +...
> diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
> new file mode 100644
> index 000000000000..44b6ed3b8f18
> --- /dev/null
> +++ b/include/dt-bindings/nvmem/microchip,otpc.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

Same license as bindings.

> +
> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
> +
> +/*
> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
> + * stride = 4.
> + */
> +#define OTP_PKT(id)			((id) * 4)

Do I get it correctly - the offset or register address is now part of a
binding? You write here "id", however you use it as part of "reg", so
it's confusing.

> +
> +/*
> + * Temperature calibration packet length for SAMA7G5: 1 words header,
> + * 18 words payload.
> + */
> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN	(19 * 4)

Length of some memory region also does not look like job for bindings.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 10/05/2022 11:44, Claudiu Beznea wrote:
> Document Microchip OTP controller.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
>  .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
>  include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
>  2 files changed, 73 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>  create mode 040000 include/dt-bindings/nvmem
>  create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
> new file mode 100644
> index 000000000000..a8df7fee5c2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml

vendor,device.yaml
device should not be a wildcard but first compatible, so
microchip,sama7g5-otpc.yaml


> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings

s/device tree bindings//

> +
> +maintainers:
> +  - Claudiu Beznea <claudiu.beznea@microchip.com>
> +
> +description: |
> +  This binding represents the OTP controller found on SAMA7G5 SoC.

Entire description is duplicating title. Please describe the hardware or
skip it.

OTOH, you should mention the header, for example in description.

> +
> +allOf:
> +  - $ref: "nvmem.yaml#"
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: microchip,sama7g5-otpc
> +      - const: syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 1

These come from nvmem.yaml.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/at91.h>

How the clock is used here?

> +    #include <dt-bindings/nvmem/microchip,otpc.h>
> +
> +    otpc: efuse@e8c00000 {
> +        compatible = "microchip,sama7g5-otpc", "syscon";
> +        reg = <0xe8c00000 0xec>;
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        temperature_calib: calib@1 {
> +            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
> +        };
> +    };
> +
> +...
> diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
> new file mode 100644
> index 000000000000..44b6ed3b8f18
> --- /dev/null
> +++ b/include/dt-bindings/nvmem/microchip,otpc.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

Same license as bindings.

> +
> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
> +
> +/*
> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
> + * stride = 4.
> + */
> +#define OTP_PKT(id)			((id) * 4)

Do I get it correctly - the offset or register address is now part of a
binding? You write here "id", however you use it as part of "reg", so
it's confusing.

> +
> +/*
> + * Temperature calibration packet length for SAMA7G5: 1 words header,
> + * 18 words payload.
> + */
> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN	(19 * 4)

Length of some memory region also does not look like job for bindings.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 11.05.2022 18:27, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 10/05/2022 11:44, Claudiu Beznea wrote:
>> Document Microchip OTP controller.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
>>  .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
>>  include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
>>  2 files changed, 73 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>>  create mode 040000 include/dt-bindings/nvmem
>>  create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>> new file mode 100644
>> index 000000000000..a8df7fee5c2b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
> 
> vendor,device.yaml
> device should not be a wildcard but first compatible, so
> microchip,sama7g5-otpc.yaml

OK

> 
> 
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings
> 
> s/device tree bindings//

OK

> 
>> +
>> +maintainers:
>> +  - Claudiu Beznea <claudiu.beznea@microchip.com>
>> +
>> +description: |
>> +  This binding represents the OTP controller found on SAMA7G5 SoC.
> 
> Entire description is duplicating title. Please describe the hardware or
> skip it.

OK

> 
> OTOH, you should mention the header, for example in description.
> 
>> +
>> +allOf:
>> +  - $ref: "nvmem.yaml#"
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - const: microchip,sama7g5-otpc
>> +      - const: syscon
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#address-cells":
>> +    const: 1
>> +
>> +  "#size-cells":
>> +    const: 1
> 
> These come from nvmem.yaml.

OK

> 
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/at91.h>
> 
> How the clock is used here?

This is garbage. I forgot it here.

> 
>> +    #include <dt-bindings/nvmem/microchip,otpc.h>
>> +
>> +    otpc: efuse@e8c00000 {
>> +        compatible = "microchip,sama7g5-otpc", "syscon";
>> +        reg = <0xe8c00000 0xec>;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +
>> +        temperature_calib: calib@1 {
>> +            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
>> +        };
>> +    };
>> +
>> +...
>> diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
>> new file mode 100644
>> index 000000000000..44b6ed3b8f18
>> --- /dev/null
>> +++ b/include/dt-bindings/nvmem/microchip,otpc.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
> 
> Same license as bindings.

OK

> 
>> +
>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +
>> +/*
>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>> + * stride = 4.
>> + */
>> +#define OTP_PKT(id)                  ((id) * 4)
> 
> Do I get it correctly - the offset or register address is now part of a
> binding? You write here "id", however you use it as part of "reg", so
> it's confusing.

I agree that reg should describe the offset in OTP memory and its the
length for a cell.

However this OTP memory is organized into packets (this is how hardware is
designed), the 1st one being the boot configuration packet, the 2nd one
being temperature calibration data. At the moment Microchip provides only
these 2 packets in OTP memory. Boot configuration packet may vary in length
thus it may change the offset the temperature calibration packet resides
to. If this happen and we use offset based addressing in device trees then
the solution will not work all the time.

OTP hardware is designed to work with packets. For a packet being in memory
at offset 0x0E as follows:

offset  OTP Memory layout

         .           .
         .    ...    .
         .           .
0x0E     +-----------+	<--- packet X
         | header  X |
0x12     +-----------+
         | payload X |
0x16     |           |
         |           |
0x1A     |           |
         +-----------+
         .           .
         .    ...    .
         .           .

requesting from software data at address 0x16 (through OTP control
registers) will return the whole packet starting at offset 0x0E. Same
things happens when requesting data at offset 0x0E, 0x12, 0x1A.

Thus, as underlying hardware returns to software chunks of 4 bytes though
data registers the driver has been registered with stride = 4. The
OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
which manages a list of the available packets divides this value by 4 and
gets the packet ID and the proper offset in memory for the requested packet ID.

The intention was to have the OTP_PKT() macro here to be used in device
trees for simpler way of describing different cells in this OTP memory.
Also, using OTP_PKT() abstraction looked to me closer to the reality
(although the computed value is not reflecting this, it is only an
abstraction to be able to pass the NVMEM subsystem).

Would you prefer to have raw values instead of using this macro?

Adapting the subsystem for this kind of devices is also an option if
Srinivas thinks like this.

> 
>> +
>> +/*
>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>> + * 18 words payload.
>> + */
>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
> 
> Length of some memory region also does not look like job for bindings.

I added it here to be able to have the same macro in DT and consumer
drivers taking as example iio drivers that uses this approach to describe
IIO channel identifiers. I can remove it and use necessary macros in the
consumer drivers, if it's better this way.

Thank you for your review,
Claudiu Beznea

> 
> Best regards,
> Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 11.05.2022 18:27, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 10/05/2022 11:44, Claudiu Beznea wrote:
>> Document Microchip OTP controller.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
>>  .../bindings/nvmem/microchip-otpc.yaml        | 55 +++++++++++++++++++
>>  include/dt-bindings/nvmem/microchip,otpc.h    | 18 ++++++
>>  2 files changed, 73 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>>  create mode 040000 include/dt-bindings/nvmem
>>  create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>> new file mode 100644
>> index 000000000000..a8df7fee5c2b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
> 
> vendor,device.yaml
> device should not be a wildcard but first compatible, so
> microchip,sama7g5-otpc.yaml

OK

> 
> 
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings
> 
> s/device tree bindings//

OK

> 
>> +
>> +maintainers:
>> +  - Claudiu Beznea <claudiu.beznea@microchip.com>
>> +
>> +description: |
>> +  This binding represents the OTP controller found on SAMA7G5 SoC.
> 
> Entire description is duplicating title. Please describe the hardware or
> skip it.

OK

> 
> OTOH, you should mention the header, for example in description.
> 
>> +
>> +allOf:
>> +  - $ref: "nvmem.yaml#"
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - const: microchip,sama7g5-otpc
>> +      - const: syscon
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#address-cells":
>> +    const: 1
>> +
>> +  "#size-cells":
>> +    const: 1
> 
> These come from nvmem.yaml.

OK

> 
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/at91.h>
> 
> How the clock is used here?

This is garbage. I forgot it here.

> 
>> +    #include <dt-bindings/nvmem/microchip,otpc.h>
>> +
>> +    otpc: efuse@e8c00000 {
>> +        compatible = "microchip,sama7g5-otpc", "syscon";
>> +        reg = <0xe8c00000 0xec>;
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +
>> +        temperature_calib: calib@1 {
>> +            reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
>> +        };
>> +    };
>> +
>> +...
>> diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
>> new file mode 100644
>> index 000000000000..44b6ed3b8f18
>> --- /dev/null
>> +++ b/include/dt-bindings/nvmem/microchip,otpc.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
> 
> Same license as bindings.

OK

> 
>> +
>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +
>> +/*
>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>> + * stride = 4.
>> + */
>> +#define OTP_PKT(id)                  ((id) * 4)
> 
> Do I get it correctly - the offset or register address is now part of a
> binding? You write here "id", however you use it as part of "reg", so
> it's confusing.

I agree that reg should describe the offset in OTP memory and its the
length for a cell.

However this OTP memory is organized into packets (this is how hardware is
designed), the 1st one being the boot configuration packet, the 2nd one
being temperature calibration data. At the moment Microchip provides only
these 2 packets in OTP memory. Boot configuration packet may vary in length
thus it may change the offset the temperature calibration packet resides
to. If this happen and we use offset based addressing in device trees then
the solution will not work all the time.

OTP hardware is designed to work with packets. For a packet being in memory
at offset 0x0E as follows:

offset  OTP Memory layout

         .           .
         .    ...    .
         .           .
0x0E     +-----------+	<--- packet X
         | header  X |
0x12     +-----------+
         | payload X |
0x16     |           |
         |           |
0x1A     |           |
         +-----------+
         .           .
         .    ...    .
         .           .

requesting from software data at address 0x16 (through OTP control
registers) will return the whole packet starting at offset 0x0E. Same
things happens when requesting data at offset 0x0E, 0x12, 0x1A.

Thus, as underlying hardware returns to software chunks of 4 bytes though
data registers the driver has been registered with stride = 4. The
OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
which manages a list of the available packets divides this value by 4 and
gets the packet ID and the proper offset in memory for the requested packet ID.

The intention was to have the OTP_PKT() macro here to be used in device
trees for simpler way of describing different cells in this OTP memory.
Also, using OTP_PKT() abstraction looked to me closer to the reality
(although the computed value is not reflecting this, it is only an
abstraction to be able to pass the NVMEM subsystem).

Would you prefer to have raw values instead of using this macro?

Adapting the subsystem for this kind of devices is also an option if
Srinivas thinks like this.

> 
>> +
>> +/*
>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>> + * 18 words payload.
>> + */
>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
> 
> Length of some memory region also does not look like job for bindings.

I added it here to be able to have the same macro in DT and consumer
drivers taking as example iio drivers that uses this approach to describe
IIO channel identifiers. I can remove it and use necessary macros in the
consumer drivers, if it's better this way.

Thank you for your review,
Claudiu Beznea

> 
> Best regards,
> Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 09:17, Claudiu.Beznea@microchip.com wrote:
>>
>>> +
>>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>> +
>>> +/*
>>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>>> + * stride = 4.
>>> + */
>>> +#define OTP_PKT(id)                  ((id) * 4)
>>
>> Do I get it correctly - the offset or register address is now part of a
>> binding? You write here "id", however you use it as part of "reg", so
>> it's confusing.
> 
> I agree that reg should describe the offset in OTP memory and its the
> length for a cell.
> 
> However this OTP memory is organized into packets (this is how hardware is
> designed), the 1st one being the boot configuration packet, the 2nd one
> being temperature calibration data. At the moment Microchip provides only
> these 2 packets in OTP memory. Boot configuration packet may vary in length
> thus it may change the offset the temperature calibration packet resides
> to. If this happen and we use offset based addressing in device trees then
> the solution will not work all the time.
> 
> OTP hardware is designed to work with packets. For a packet being in memory
> at offset 0x0E as follows:
> 
> offset  OTP Memory layout
> 
>          .           .
>          .    ...    .
>          .           .
> 0x0E     +-----------+	<--- packet X
>          | header  X |
> 0x12     +-----------+
>          | payload X |
> 0x16     |           |
>          |           |
> 0x1A     |           |
>          +-----------+
>          .           .
>          .    ...    .
>          .           .
> 
> requesting from software data at address 0x16 (through OTP control
> registers) will return the whole packet starting at offset 0x0E. Same
> things happens when requesting data at offset 0x0E, 0x12, 0x1A.
> 
> Thus, as underlying hardware returns to software chunks of 4 bytes though
> data registers the driver has been registered with stride = 4. The
> OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
> by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
> which manages a list of the available packets divides this value by 4 and
> gets the packet ID and the proper offset in memory for the requested packet ID.
> 
> The intention was to have the OTP_PKT() macro here to be used in device
> trees for simpler way of describing different cells in this OTP memory.
> Also, using OTP_PKT() abstraction looked to me closer to the reality
> (although the computed value is not reflecting this, it is only an
> abstraction to be able to pass the NVMEM subsystem).
> 
> Would you prefer to have raw values instead of using this macro?

Macro is a nice idea if it can be stable. I understood that length of
packets depends on hardware, so this part could be stable. But what
about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
You wrote "Boot configuration packet may vary in length", so it could be
changed by Microchip?

Once this value is stored in the bindings, it is not supposed to change.

> 
> Adapting the subsystem for this kind of devices is also an option if
> Srinivas thinks like this.
> 
>>
>>> +
>>> +/*
>>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>>> + * 18 words payload.
>>> + */
>>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
>>
>> Length of some memory region also does not look like job for bindings.
> 
> I added it here to be able to have the same macro in DT and consumer
> drivers taking as example iio drivers that uses this approach to describe
> IIO channel identifiers. I can remove it and use necessary macros in the
> consumer drivers, if it's better this way.



Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 09:17, Claudiu.Beznea@microchip.com wrote:
>>
>>> +
>>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>> +
>>> +/*
>>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>>> + * stride = 4.
>>> + */
>>> +#define OTP_PKT(id)                  ((id) * 4)
>>
>> Do I get it correctly - the offset or register address is now part of a
>> binding? You write here "id", however you use it as part of "reg", so
>> it's confusing.
> 
> I agree that reg should describe the offset in OTP memory and its the
> length for a cell.
> 
> However this OTP memory is organized into packets (this is how hardware is
> designed), the 1st one being the boot configuration packet, the 2nd one
> being temperature calibration data. At the moment Microchip provides only
> these 2 packets in OTP memory. Boot configuration packet may vary in length
> thus it may change the offset the temperature calibration packet resides
> to. If this happen and we use offset based addressing in device trees then
> the solution will not work all the time.
> 
> OTP hardware is designed to work with packets. For a packet being in memory
> at offset 0x0E as follows:
> 
> offset  OTP Memory layout
> 
>          .           .
>          .    ...    .
>          .           .
> 0x0E     +-----------+	<--- packet X
>          | header  X |
> 0x12     +-----------+
>          | payload X |
> 0x16     |           |
>          |           |
> 0x1A     |           |
>          +-----------+
>          .           .
>          .    ...    .
>          .           .
> 
> requesting from software data at address 0x16 (through OTP control
> registers) will return the whole packet starting at offset 0x0E. Same
> things happens when requesting data at offset 0x0E, 0x12, 0x1A.
> 
> Thus, as underlying hardware returns to software chunks of 4 bytes though
> data registers the driver has been registered with stride = 4. The
> OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
> by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
> which manages a list of the available packets divides this value by 4 and
> gets the packet ID and the proper offset in memory for the requested packet ID.
> 
> The intention was to have the OTP_PKT() macro here to be used in device
> trees for simpler way of describing different cells in this OTP memory.
> Also, using OTP_PKT() abstraction looked to me closer to the reality
> (although the computed value is not reflecting this, it is only an
> abstraction to be able to pass the NVMEM subsystem).
> 
> Would you prefer to have raw values instead of using this macro?

Macro is a nice idea if it can be stable. I understood that length of
packets depends on hardware, so this part could be stable. But what
about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
You wrote "Boot configuration packet may vary in length", so it could be
changed by Microchip?

Once this value is stored in the bindings, it is not supposed to change.

> 
> Adapting the subsystem for this kind of devices is also an option if
> Srinivas thinks like this.
> 
>>
>>> +
>>> +/*
>>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>>> + * 18 words payload.
>>> + */
>>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
>>
>> Length of some memory region also does not look like job for bindings.
> 
> I added it here to be able to have the same macro in DT and consumer
> drivers taking as example iio drivers that uses this approach to describe
> IIO channel identifiers. I can remove it and use necessary macros in the
> consumer drivers, if it's better this way.



Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 12.05.2022 10:54, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 09:17, Claudiu.Beznea@microchip.com wrote:
>>>
>>>> +
>>>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>>> +
>>>> +/*
>>>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>>>> + * stride = 4.
>>>> + */
>>>> +#define OTP_PKT(id)                  ((id) * 4)
>>>
>>> Do I get it correctly - the offset or register address is now part of a
>>> binding? You write here "id", however you use it as part of "reg", so
>>> it's confusing.
>>
>> I agree that reg should describe the offset in OTP memory and its the
>> length for a cell.
>>
>> However this OTP memory is organized into packets (this is how hardware is
>> designed), the 1st one being the boot configuration packet, the 2nd one
>> being temperature calibration data. At the moment Microchip provides only
>> these 2 packets in OTP memory. Boot configuration packet may vary in length
>> thus it may change the offset the temperature calibration packet resides
>> to. If this happen and we use offset based addressing in device trees then
>> the solution will not work all the time.
>>
>> OTP hardware is designed to work with packets. For a packet being in memory
>> at offset 0x0E as follows:
>>
>> offset  OTP Memory layout
>>
>>          .           .
>>          .    ...    .
>>          .           .
>> 0x0E     +-----------+        <--- packet X
>>          | header  X |
>> 0x12     +-----------+
>>          | payload X |
>> 0x16     |           |
>>          |           |
>> 0x1A     |           |
>>          +-----------+
>>          .           .
>>          .    ...    .
>>          .           .
>>
>> requesting from software data at address 0x16 (through OTP control
>> registers) will return the whole packet starting at offset 0x0E. Same
>> things happens when requesting data at offset 0x0E, 0x12, 0x1A.
>>
>> Thus, as underlying hardware returns to software chunks of 4 bytes though
>> data registers the driver has been registered with stride = 4. The
>> OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
>> by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
>> which manages a list of the available packets divides this value by 4 and
>> gets the packet ID and the proper offset in memory for the requested packet ID.
>>
>> The intention was to have the OTP_PKT() macro here to be used in device
>> trees for simpler way of describing different cells in this OTP memory.
>> Also, using OTP_PKT() abstraction looked to me closer to the reality
>> (although the computed value is not reflecting this, it is only an
>> abstraction to be able to pass the NVMEM subsystem).
>>
>> Would you prefer to have raw values instead of using this macro?
> 
> Macro is a nice idea if it can be stable. I understood that length of
> packets depends on hardware, so this part could be stable. But what
> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?

The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
calibration packet. This length is fixed and will not be changed.

After these 2 packets (provided by Microchip) user may further flash any
number of packets and use them as they wish.

Driver is in charge of scanning the NVMEM for the available packets and
prepare a list with their IDs and their starting offsets in NVMEM memory
such that when it receives a read request it will be able to decode the
packet offset based on packet identifier.

In case different number of packets are available in NVMEM for different
kind of setups (boards) these could also be referenced in board specific DT
using OTP_PKT() macro and with proper length (which will depend on what
user flashed).

> You wrote "Boot configuration packet may vary in length", so it could be
> changed by Microchip?

Yes, between chip revisions its length could be changed.

> 
> Once this value is stored in the bindings, it is not supposed to change.

I agree!

> 
>>
>> Adapting the subsystem for this kind of devices is also an option if
>> Srinivas thinks like this.
>>
>>>
>>>> +
>>>> +/*
>>>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>>>> + * 18 words payload.
>>>> + */
>>>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
>>>
>>> Length of some memory region also does not look like job for bindings.
>>
>> I added it here to be able to have the same macro in DT and consumer
>> drivers taking as example iio drivers that uses this approach to describe
>> IIO channel identifiers. I can remove it and use necessary macros in the
>> consumer drivers, if it's better this way.
> 
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 12.05.2022 10:54, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 09:17, Claudiu.Beznea@microchip.com wrote:
>>>
>>>> +
>>>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>>>> +
>>>> +/*
>>>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>>>> + * stride = 4.
>>>> + */
>>>> +#define OTP_PKT(id)                  ((id) * 4)
>>>
>>> Do I get it correctly - the offset or register address is now part of a
>>> binding? You write here "id", however you use it as part of "reg", so
>>> it's confusing.
>>
>> I agree that reg should describe the offset in OTP memory and its the
>> length for a cell.
>>
>> However this OTP memory is organized into packets (this is how hardware is
>> designed), the 1st one being the boot configuration packet, the 2nd one
>> being temperature calibration data. At the moment Microchip provides only
>> these 2 packets in OTP memory. Boot configuration packet may vary in length
>> thus it may change the offset the temperature calibration packet resides
>> to. If this happen and we use offset based addressing in device trees then
>> the solution will not work all the time.
>>
>> OTP hardware is designed to work with packets. For a packet being in memory
>> at offset 0x0E as follows:
>>
>> offset  OTP Memory layout
>>
>>          .           .
>>          .    ...    .
>>          .           .
>> 0x0E     +-----------+        <--- packet X
>>          | header  X |
>> 0x12     +-----------+
>>          | payload X |
>> 0x16     |           |
>>          |           |
>> 0x1A     |           |
>>          +-----------+
>>          .           .
>>          .    ...    .
>>          .           .
>>
>> requesting from software data at address 0x16 (through OTP control
>> registers) will return the whole packet starting at offset 0x0E. Same
>> things happens when requesting data at offset 0x0E, 0x12, 0x1A.
>>
>> Thus, as underlying hardware returns to software chunks of 4 bytes though
>> data registers the driver has been registered with stride = 4. The
>> OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
>> by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
>> which manages a list of the available packets divides this value by 4 and
>> gets the packet ID and the proper offset in memory for the requested packet ID.
>>
>> The intention was to have the OTP_PKT() macro here to be used in device
>> trees for simpler way of describing different cells in this OTP memory.
>> Also, using OTP_PKT() abstraction looked to me closer to the reality
>> (although the computed value is not reflecting this, it is only an
>> abstraction to be able to pass the NVMEM subsystem).
>>
>> Would you prefer to have raw values instead of using this macro?
> 
> Macro is a nice idea if it can be stable. I understood that length of
> packets depends on hardware, so this part could be stable. But what
> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?

The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
calibration packet. This length is fixed and will not be changed.

After these 2 packets (provided by Microchip) user may further flash any
number of packets and use them as they wish.

Driver is in charge of scanning the NVMEM for the available packets and
prepare a list with their IDs and their starting offsets in NVMEM memory
such that when it receives a read request it will be able to decode the
packet offset based on packet identifier.

In case different number of packets are available in NVMEM for different
kind of setups (boards) these could also be referenced in board specific DT
using OTP_PKT() macro and with proper length (which will depend on what
user flashed).

> You wrote "Boot configuration packet may vary in length", so it could be
> changed by Microchip?

Yes, between chip revisions its length could be changed.

> 
> Once this value is stored in the bindings, it is not supposed to change.

I agree!

> 
>>
>> Adapting the subsystem for this kind of devices is also an option if
>> Srinivas thinks like this.
>>
>>>
>>>> +
>>>> +/*
>>>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>>>> + * 18 words payload.
>>>> + */
>>>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN       (19 * 4)
>>>
>>> Length of some memory region also does not look like job for bindings.
>>
>> I added it here to be able to have the same macro in DT and consumer
>> drivers taking as example iio drivers that uses this approach to describe
>> IIO channel identifiers. I can remove it and use necessary macros in the
>> consumer drivers, if it's better this way.
> 
> 
> 
> Best regards,
> Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:

>>
>> Macro is a nice idea if it can be stable. I understood that length of
>> packets depends on hardware, so this part could be stable. But what
>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
> 
> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
> calibration packet. This length is fixed and will not be changed.
> 
> After these 2 packets (provided by Microchip) user may further flash any
> number of packets and use them as they wish.
> 
> Driver is in charge of scanning the NVMEM for the available packets and
> prepare a list with their IDs and their starting offsets in NVMEM memory
> such that when it receives a read request it will be able to decode the
> packet offset based on packet identifier.
> 
> In case different number of packets are available in NVMEM for different
> kind of setups (boards) these could also be referenced in board specific DT
> using OTP_PKT() macro and with proper length (which will depend on what
> user flashed).
> 
>> You wrote "Boot configuration packet may vary in length", so it could be
>> changed by Microchip?
> 
> Yes, between chip revisions its length could be changed.

Chip revisions like different board compatibles thus different
bindings/macro values? If not, then maybe better skip the length out of
bindings and just provide the first macro.



Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:

>>
>> Macro is a nice idea if it can be stable. I understood that length of
>> packets depends on hardware, so this part could be stable. But what
>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
> 
> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
> calibration packet. This length is fixed and will not be changed.
> 
> After these 2 packets (provided by Microchip) user may further flash any
> number of packets and use them as they wish.
> 
> Driver is in charge of scanning the NVMEM for the available packets and
> prepare a list with their IDs and their starting offsets in NVMEM memory
> such that when it receives a read request it will be able to decode the
> packet offset based on packet identifier.
> 
> In case different number of packets are available in NVMEM for different
> kind of setups (boards) these could also be referenced in board specific DT
> using OTP_PKT() macro and with proper length (which will depend on what
> user flashed).
> 
>> You wrote "Boot configuration packet may vary in length", so it could be
>> changed by Microchip?
> 
> Yes, between chip revisions its length could be changed.

Chip revisions like different board compatibles thus different
bindings/macro values? If not, then maybe better skip the length out of
bindings and just provide the first macro.



Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
> 
>>>
>>> Macro is a nice idea if it can be stable. I understood that length of
>>> packets depends on hardware, so this part could be stable. But what
>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>
>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>> calibration packet. This length is fixed and will not be changed.
>>
>> After these 2 packets (provided by Microchip) user may further flash any
>> number of packets and use them as they wish.
>>
>> Driver is in charge of scanning the NVMEM for the available packets and
>> prepare a list with their IDs and their starting offsets in NVMEM memory
>> such that when it receives a read request it will be able to decode the
>> packet offset based on packet identifier.
>>
>> In case different number of packets are available in NVMEM for different
>> kind of setups (boards) these could also be referenced in board specific DT
>> using OTP_PKT() macro and with proper length (which will depend on what
>> user flashed).
>>
>>> You wrote "Boot configuration packet may vary in length", so it could be
>>> changed by Microchip?
>>
>> Yes, between chip revisions its length could be changed.
> 
> Chip revisions like different board compatibles thus different
> bindings/macro values?

Not necessarily. It may happen that only ROM code to be updated (1st stage
bootloader) end everything else on Linux side to be able to run as is. Or
to just fix some bugs in different IPs. Things that will not necessarily
need adding new compatibles for the new chip. And it may happen that new
chip revisions to be populated on previous board revisions.

> Chip revisions like different board compatibles thus different
> *macro* values?

If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
established that will remain fixed b/w revisions. This is the length of the
2nd packet in NVMEM (that is of interest for thermal management).

Only the length of the 1st packet may change. And addressing the NVMEM with
packet id based index should take care of temperature calibration NVMEM DT
binding to work all the time.

> If not, then maybe better skip the length out of
> bindings and just provide the first macro.

As far as I know the length is part of the way the NVMEM cells are
described in DT: it needs the offset in memory (for the data to be
retrieved) and its length.

Thank you,
Claudiu Beznea

> 
> 
> 
> Best regards,
> Krzysztof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
> 
>>>
>>> Macro is a nice idea if it can be stable. I understood that length of
>>> packets depends on hardware, so this part could be stable. But what
>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>
>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>> calibration packet. This length is fixed and will not be changed.
>>
>> After these 2 packets (provided by Microchip) user may further flash any
>> number of packets and use them as they wish.
>>
>> Driver is in charge of scanning the NVMEM for the available packets and
>> prepare a list with their IDs and their starting offsets in NVMEM memory
>> such that when it receives a read request it will be able to decode the
>> packet offset based on packet identifier.
>>
>> In case different number of packets are available in NVMEM for different
>> kind of setups (boards) these could also be referenced in board specific DT
>> using OTP_PKT() macro and with proper length (which will depend on what
>> user flashed).
>>
>>> You wrote "Boot configuration packet may vary in length", so it could be
>>> changed by Microchip?
>>
>> Yes, between chip revisions its length could be changed.
> 
> Chip revisions like different board compatibles thus different
> bindings/macro values?

Not necessarily. It may happen that only ROM code to be updated (1st stage
bootloader) end everything else on Linux side to be able to run as is. Or
to just fix some bugs in different IPs. Things that will not necessarily
need adding new compatibles for the new chip. And it may happen that new
chip revisions to be populated on previous board revisions.

> Chip revisions like different board compatibles thus different
> *macro* values?

If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
established that will remain fixed b/w revisions. This is the length of the
2nd packet in NVMEM (that is of interest for thermal management).

Only the length of the 1st packet may change. And addressing the NVMEM with
packet id based index should take care of temperature calibration NVMEM DT
binding to work all the time.

> If not, then maybe better skip the length out of
> bindings and just provide the first macro.

As far as I know the length is part of the way the NVMEM cells are
described in DT: it needs the offset in memory (for the data to be
retrieved) and its length.

Thank you,
Claudiu Beznea

> 
> 
> 
> Best regards,
> Krzysztof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 18:04, Claudiu.Beznea@microchip.com wrote:
> On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
>>
>>>>
>>>> Macro is a nice idea if it can be stable. I understood that length of
>>>> packets depends on hardware, so this part could be stable. But what
>>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>>
>>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>>> calibration packet. This length is fixed and will not be changed.
>>>
>>> After these 2 packets (provided by Microchip) user may further flash any
>>> number of packets and use them as they wish.
>>>
>>> Driver is in charge of scanning the NVMEM for the available packets and
>>> prepare a list with their IDs and their starting offsets in NVMEM memory
>>> such that when it receives a read request it will be able to decode the
>>> packet offset based on packet identifier.
>>>
>>> In case different number of packets are available in NVMEM for different
>>> kind of setups (boards) these could also be referenced in board specific DT
>>> using OTP_PKT() macro and with proper length (which will depend on what
>>> user flashed).
>>>
>>>> You wrote "Boot configuration packet may vary in length", so it could be
>>>> changed by Microchip?
>>>
>>> Yes, between chip revisions its length could be changed.
>>
>> Chip revisions like different board compatibles thus different
>> bindings/macro values?
> 
> Not necessarily. It may happen that only ROM code to be updated (1st stage
> bootloader) end everything else on Linux side to be able to run as is. Or
> to just fix some bugs in different IPs. Things that will not necessarily
> need adding new compatibles for the new chip. And it may happen that new
> chip revisions to be populated on previous board revisions.
> 
>> Chip revisions like different board compatibles thus different
>> *macro* values?
> 
> If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
> established that will remain fixed b/w revisions. This is the length of the
> 2nd packet in NVMEM (that is of interest for thermal management).
> 
> Only the length of the 1st packet may change. And addressing the NVMEM with
> packet id based index should take care of temperature calibration NVMEM DT
> binding to work all the time.
> 
>> If not, then maybe better skip the length out of
>> bindings and just provide the first macro.
> 
> As far as I know the length is part of the way the NVMEM cells are
> described in DT: it needs the offset in memory (for the data to be
> retrieved) and its length.

In DT yes, but now you put the length in the bindings. It means DTS must
have exactly that value and cannot use anything more. It's the same as
hard-coding unit addresses in the bindings.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Krzysztof Kozlowski]

On 12/05/2022 18:04, Claudiu.Beznea@microchip.com wrote:
> On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
>>
>>>>
>>>> Macro is a nice idea if it can be stable. I understood that length of
>>>> packets depends on hardware, so this part could be stable. But what
>>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>>
>>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>>> calibration packet. This length is fixed and will not be changed.
>>>
>>> After these 2 packets (provided by Microchip) user may further flash any
>>> number of packets and use them as they wish.
>>>
>>> Driver is in charge of scanning the NVMEM for the available packets and
>>> prepare a list with their IDs and their starting offsets in NVMEM memory
>>> such that when it receives a read request it will be able to decode the
>>> packet offset based on packet identifier.
>>>
>>> In case different number of packets are available in NVMEM for different
>>> kind of setups (boards) these could also be referenced in board specific DT
>>> using OTP_PKT() macro and with proper length (which will depend on what
>>> user flashed).
>>>
>>>> You wrote "Boot configuration packet may vary in length", so it could be
>>>> changed by Microchip?
>>>
>>> Yes, between chip revisions its length could be changed.
>>
>> Chip revisions like different board compatibles thus different
>> bindings/macro values?
> 
> Not necessarily. It may happen that only ROM code to be updated (1st stage
> bootloader) end everything else on Linux side to be able to run as is. Or
> to just fix some bugs in different IPs. Things that will not necessarily
> need adding new compatibles for the new chip. And it may happen that new
> chip revisions to be populated on previous board revisions.
> 
>> Chip revisions like different board compatibles thus different
>> *macro* values?
> 
> If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
> established that will remain fixed b/w revisions. This is the length of the
> 2nd packet in NVMEM (that is of interest for thermal management).
> 
> Only the length of the 1st packet may change. And addressing the NVMEM with
> packet id based index should take care of temperature calibration NVMEM DT
> binding to work all the time.
> 
>> If not, then maybe better skip the length out of
>> bindings and just provide the first macro.
> 
> As far as I know the length is part of the way the NVMEM cells are
> described in DT: it needs the offset in memory (for the data to be
> retrieved) and its length.

In DT yes, but now you put the length in the bindings. It means DTS must
have exactly that value and cannot use anything more. It's the same as
hard-coding unit addresses in the bindings.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 13.05.2022 10:49, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 18:04, Claudiu.Beznea@microchip.com wrote:
>> On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
>>>
>>>>>
>>>>> Macro is a nice idea if it can be stable. I understood that length of
>>>>> packets depends on hardware, so this part could be stable. But what
>>>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>>>
>>>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>>>> calibration packet. This length is fixed and will not be changed.
>>>>
>>>> After these 2 packets (provided by Microchip) user may further flash any
>>>> number of packets and use them as they wish.
>>>>
>>>> Driver is in charge of scanning the NVMEM for the available packets and
>>>> prepare a list with their IDs and their starting offsets in NVMEM memory
>>>> such that when it receives a read request it will be able to decode the
>>>> packet offset based on packet identifier.
>>>>
>>>> In case different number of packets are available in NVMEM for different
>>>> kind of setups (boards) these could also be referenced in board specific DT
>>>> using OTP_PKT() macro and with proper length (which will depend on what
>>>> user flashed).
>>>>
>>>>> You wrote "Boot configuration packet may vary in length", so it could be
>>>>> changed by Microchip?
>>>>
>>>> Yes, between chip revisions its length could be changed.
>>>
>>> Chip revisions like different board compatibles thus different
>>> bindings/macro values?
>>
>> Not necessarily. It may happen that only ROM code to be updated (1st stage
>> bootloader) end everything else on Linux side to be able to run as is. Or
>> to just fix some bugs in different IPs. Things that will not necessarily
>> need adding new compatibles for the new chip. And it may happen that new
>> chip revisions to be populated on previous board revisions.
>>
>>> Chip revisions like different board compatibles thus different
>>> *macro* values?
>>
>> If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
>> established that will remain fixed b/w revisions. This is the length of the
>> 2nd packet in NVMEM (that is of interest for thermal management).
>>
>> Only the length of the 1st packet may change. And addressing the NVMEM with
>> packet id based index should take care of temperature calibration NVMEM DT
>> binding to work all the time.
>>
>>> If not, then maybe better skip the length out of
>>> bindings and just provide the first macro.
>>
>> As far as I know the length is part of the way the NVMEM cells are
>> described in DT: it needs the offset in memory (for the data to be
>> retrieved) and its length.
> 
> In DT yes, but now you put the length in the bindings. It means DTS must
> have exactly that value and cannot use anything more. It's the same as
> hard-coding unit addresses in the bindings.

I see. I will provide only the OTP_PKT() macro in bindings as you suggested.

Thank you,
Claudiu Beznea

> 
> 
> Best regards,
> Krzysztof

Re: [PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC

[Claudiu.Beznea]

On 13.05.2022 10:49, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 12/05/2022 18:04, Claudiu.Beznea@microchip.com wrote:
>> On 12.05.2022 18:35, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 12/05/2022 17:31, Claudiu.Beznea@microchip.com wrote:
>>>
>>>>>
>>>>> Macro is a nice idea if it can be stable. I understood that length of
>>>>> packets depends on hardware, so this part could be stable. But what
>>>>> about number of packets, so the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN below?
>>>>
>>>> The OTP_PKT_SAMA7G5_TEMP_CALIB_LEN here is the length of thermal
>>>> calibration packet. This length is fixed and will not be changed.
>>>>
>>>> After these 2 packets (provided by Microchip) user may further flash any
>>>> number of packets and use them as they wish.
>>>>
>>>> Driver is in charge of scanning the NVMEM for the available packets and
>>>> prepare a list with their IDs and their starting offsets in NVMEM memory
>>>> such that when it receives a read request it will be able to decode the
>>>> packet offset based on packet identifier.
>>>>
>>>> In case different number of packets are available in NVMEM for different
>>>> kind of setups (boards) these could also be referenced in board specific DT
>>>> using OTP_PKT() macro and with proper length (which will depend on what
>>>> user flashed).
>>>>
>>>>> You wrote "Boot configuration packet may vary in length", so it could be
>>>>> changed by Microchip?
>>>>
>>>> Yes, between chip revisions its length could be changed.
>>>
>>> Chip revisions like different board compatibles thus different
>>> bindings/macro values?
>>
>> Not necessarily. It may happen that only ROM code to be updated (1st stage
>> bootloader) end everything else on Linux side to be able to run as is. Or
>> to just fix some bugs in different IPs. Things that will not necessarily
>> need adding new compatibles for the new chip. And it may happen that new
>> chip revisions to be populated on previous board revisions.
>>
>>> Chip revisions like different board compatibles thus different
>>> *macro* values?
>>
>> If you're referring to the OTP_PKT_SAMA7G5_TEMP_CALIB_LEN macro, this is
>> established that will remain fixed b/w revisions. This is the length of the
>> 2nd packet in NVMEM (that is of interest for thermal management).
>>
>> Only the length of the 1st packet may change. And addressing the NVMEM with
>> packet id based index should take care of temperature calibration NVMEM DT
>> binding to work all the time.
>>
>>> If not, then maybe better skip the length out of
>>> bindings and just provide the first macro.
>>
>> As far as I know the length is part of the way the NVMEM cells are
>> described in DT: it needs the offset in memory (for the data to be
>> retrieved) and its length.
> 
> In DT yes, but now you put the length in the bindings. It means DTS must
> have exactly that value and cannot use anything more. It's the same as
> hard-coding unit addresses in the bindings.

I see. I will provide only the OTP_PKT() macro in bindings as you suggested.

Thank you,
Claudiu Beznea

> 
> 
> Best regards,
> Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] nvmem: microchip-otpc: add support

[Claudiu Beznea]

Add support for Microchip OTP controller available on SAMA7G5. The OTPC
controls the access to a non-volatile memory. The memory behind OTPC is
organized into packets, packets are composed by a fixed length header
(4 bytes long) and a variable length payload (payload length is available
in the header). When software request the data at an offset in memory
the OTPC will return (via header + data registers) the whole packet that
has a word at that offset. For a packet in OTP memory like below:

offset  OTP Memory layout

         .           .
         .    ...    .
         .           .
0x0E     +-----------+	<--- packet X
         | header  X |
0x12     +-----------+
         | payload X |
0x16     |           |
         |           |
0x1A     |           |
         +-----------+
         .           .
         .    ...    .
         .           .

if user requests data at address 0x16 the data started at 0x0E will be
returned by controller. User will be able to fetch the whole packet
starting at 0x0E (or parts of the packet) via proper registers. The same
packet will be returned if software request the data at offset 0x0E or
0x12 or 0x1A.

The OTP will be populated by Microchip with at least 2 packets first one
being boot configuration packet and the 2nd one being temperature
calibration packet. The packet order will be preserved b/w different chip
revisions but the packet sizes may change.

For the above reasons and to keep the same software able to work on all
chip variants the read function of the driver is working with a packet
id instead of an offset in OTP memory.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 MAINTAINERS                    |   8 +
 drivers/nvmem/Kconfig          |   7 +
 drivers/nvmem/Makefile         |   2 +
 drivers/nvmem/microchip-otpc.c | 288 +++++++++++++++++++++++++++++++++
 4 files changed, 305 insertions(+)
 create mode 100644 drivers/nvmem/microchip-otpc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1bf57fd937b5..f4b646a801ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12953,6 +12953,14 @@ S:	Supported
 F:	Documentation/devicetree/bindings/mtd/atmel-nand.txt
 F:	drivers/mtd/nand/raw/atmel/*
 
+MICROCHIP OTPC DRIVER
+M:	Claudiu Beznea <claudiu.beznea@microchip.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
+F:	drivers/nvmem/microchip-otpc.c
+F:	dt-bindings/nvmem/microchip,otpc.h
+
 MICROCHIP PWM DRIVER
 M:	Claudiu Beznea <claudiu.beznea@microchip.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 967d0084800e..d72d879a6d34 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -107,6 +107,13 @@ config MTK_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called efuse-mtk.
 
+config MICROCHIP_OTPC
+	tristate "Microchip OTPC support"
+	depends on ARCH_AT91 || COMPILE_TEST
+	help
+	  This driver enable the OTP controller available on Microchip SAMA7G5
+	  SoCs. It controlls the access to the OTP memory connected to it.
+
 config NVMEM_NINTENDO_OTP
 	tristate "Nintendo Wii and Wii U OTP Support"
 	depends on WII || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 00e136a0a123..c710b64f9fe4 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -67,3 +67,5 @@ obj-$(CONFIG_NVMEM_SUNPLUS_OCOTP)	+= nvmem_sunplus_ocotp.o
 nvmem_sunplus_ocotp-y		:= sunplus-ocotp.o
 obj-$(CONFIG_NVMEM_APPLE_EFUSES)	+= nvmem-apple-efuses.o
 nvmem-apple-efuses-y 		:= apple-efuses.o
+obj-$(CONFIG_MICROCHIP_OTPC)	+= nvmem-microchip-otpc.o
+nvmem-microchip-otpc-y		:= microchip-otpc.o
diff --git a/drivers/nvmem/microchip-otpc.c b/drivers/nvmem/microchip-otpc.c
new file mode 100644
index 000000000000..5c5ac1bca074
--- /dev/null
+++ b/drivers/nvmem/microchip-otpc.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OTP Memory controller
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudiu Beznea <claudiu.beznea@microchip.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define MCHP_OTPC_CR			(0x0)
+#define MCHP_OTPC_CR_READ		BIT(6)
+#define MCHP_OTPC_MR			(0x4)
+#define MCHP_OTPC_MR_ADDR		GENMASK(31, 16)
+#define MCHP_OTPC_AR			(0x8)
+#define MCHP_OTPC_SR			(0xc)
+#define MCHP_OTPC_SR_READ		BIT(6)
+#define MCHP_OTPC_HR			(0x20)
+#define MCHP_OTPC_HR_SIZE		GENMASK(15, 8)
+#define MCHP_OTPC_DR			(0x24)
+
+#define MCHP_OTPC_NAME			"mchp-otpc"
+#define MCHP_OTPC_SIZE			(11 * 1024)
+
+/**
+ * struct mchp_otpc - OTPC private data structure
+ * @base: base address
+ * @dev: struct device pointer
+ * @packets: list of packets in OTP memory
+ * @npackets: number of packets in OTP memory
+ */
+struct mchp_otpc {
+	void __iomem *base;
+	struct device *dev;
+	struct list_head packets;
+	u32 npackets;
+};
+
+/**
+ * struct mchp_otpc_packet - OTPC packet data structure
+ * @list: list head
+ * @id: packet ID
+ * @offset: packet offset (in words) in OTP memory
+ */
+struct mchp_otpc_packet {
+	struct list_head list;
+	u32 id;
+	u32 offset;
+};
+
+static struct mchp_otpc_packet *mchp_otpc_id_to_packet(struct mchp_otpc *otpc,
+						       u32 id)
+{
+	struct mchp_otpc_packet *packet;
+
+	if (id >= otpc->npackets)
+		return NULL;
+
+	list_for_each_entry(packet, &otpc->packets, list) {
+		if (packet->id == id)
+			return packet;
+	}
+
+	return NULL;
+}
+
+static int mchp_otpc_prepare_read(struct mchp_otpc *otpc,
+				  unsigned int offset)
+{
+	u32 tmp;
+
+	/* Set address. */
+	tmp = readl_relaxed(otpc->base + MCHP_OTPC_MR);
+	tmp &= ~MCHP_OTPC_MR_ADDR;
+	tmp |= FIELD_PREP(MCHP_OTPC_MR_ADDR, offset);
+	writel_relaxed(tmp, otpc->base + MCHP_OTPC_MR);
+
+	/* Set read. */
+	tmp = readl_relaxed(otpc->base + MCHP_OTPC_CR);
+	tmp |= MCHP_OTPC_CR_READ;
+	writel_relaxed(tmp, otpc->base + MCHP_OTPC_CR);
+
+	/* Wait for packet to be transferred into temporary buffers. */
+	return read_poll_timeout(readl_relaxed, tmp, !(tmp & MCHP_OTPC_SR_READ),
+				 10000, 2000, false, otpc->base + MCHP_OTPC_SR);
+}
+
+/*
+ * OTPC memory is organized into packets. Each packets contains a header and
+ * a payload. Header is 4 bytes long and contains the size of the payload.
+ * Payload size varies. The memory footprint is something as follows:
+ *
+ * Memory offset  Memory footprint     Packet ID
+ * -------------  ----------------     ---------
+ *
+ * 0x0            +------------+   <-- packet 0
+ *                | header  0  |
+ * 0x4            +------------+
+ *                | payload 0  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offset1        +------------+   <-- packet 1
+ *                | header  1  |
+ * offset1 + 0x4  +------------+
+ *                | payload 1  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offset2        +------------+   <-- packet 2
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offsetN        +------------+   <-- packet N
+ *                | header  N  |
+ * offsetN + 0x4  +------------+
+ *                | payload N  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ *                +------------+
+ *
+ * where offset1, offset2, offsetN depends on the size of payload 0, payload 1,
+ * payload N-1.
+ *
+ * The access to memory is done on a per packet basis: the control registers
+ * need to be updated with an offset address (within a packet range) and the
+ * data registers will be update by controller with information contained by
+ * that packet. E.g. if control registers are updated with any address within
+ * the range [offset1, offset2) the data registers are updated by controller
+ * with packet 1. Header data is accessible though MCHP_OTPC_HR register.
+ * Payload data is accessible though MCHP_OTPC_DR and MCHP_OTPC_AR registers.
+ * There is no direct mapping b/w the offset requested by software and the
+ * offset returned by hardware.
+ *
+ * For this, the read function will return the first requested bytes in the
+ * packet. The user will have to be aware of the memory footprint before doing
+ * the read request.
+ */
+static int mchp_otpc_read(void *priv, unsigned int off, void *val,
+			  size_t bytes)
+{
+	struct mchp_otpc *otpc = priv;
+	struct mchp_otpc_packet *packet;
+	u32 *buf = val;
+	u32 offset;
+	size_t len = 0;
+	int ret, payload_size;
+
+	/*
+	 * We reach this point with off being multiple of stride = 4 to
+	 * be able to cross the subsystem. Inside the driver we use continuous
+	 * unsigned integer numbers for packet id, thus devide off by 4
+	 * before passing it to mchp_otpc_id_to_packet().
+	 */
+	packet = mchp_otpc_id_to_packet(otpc, off / 4);
+	if (!packet)
+		return -EINVAL;
+	offset = packet->offset;
+
+	while (len < bytes) {
+		ret = mchp_otpc_prepare_read(otpc, offset);
+		if (ret)
+			return ret;
+
+		/* Read and save header content. */
+		*buf++ = readl_relaxed(otpc->base + MCHP_OTPC_HR);
+		len += sizeof(*buf);
+		offset++;
+		if (len >= bytes)
+			break;
+
+		/* Read and save payload content. */
+		payload_size = FIELD_GET(MCHP_OTPC_HR_SIZE, *(buf - 1));
+		writel_relaxed(0UL, otpc->base + MCHP_OTPC_AR);
+		do {
+			*buf++ = readl_relaxed(otpc->base + MCHP_OTPC_DR);
+			len += sizeof(*buf);
+			offset++;
+			payload_size--;
+		} while (payload_size >= 0 && len < bytes);
+	}
+
+	return 0;
+}
+
+static int mchp_otpc_init_packets_list(struct mchp_otpc *otpc, u32 *size)
+{
+	struct mchp_otpc_packet *packet;
+	u32 word, word_pos = 0, id = 0, npackets = 0, payload_size;
+	int ret;
+
+	INIT_LIST_HEAD(&otpc->packets);
+	*size = 0;
+
+	while (*size < MCHP_OTPC_SIZE) {
+		ret = mchp_otpc_prepare_read(otpc, word_pos);
+		if (ret)
+			return ret;
+
+		word = readl_relaxed(otpc->base + MCHP_OTPC_HR);
+		payload_size = FIELD_GET(MCHP_OTPC_HR_SIZE, word);
+		if (!payload_size)
+			break;
+
+		packet = devm_kzalloc(otpc->dev, sizeof(*packet), GFP_KERNEL);
+		if (!packet)
+			return -ENOMEM;
+
+		packet->id = id++;
+		packet->offset = word_pos;
+		INIT_LIST_HEAD(&packet->list);
+		list_add_tail(&packet->list, &otpc->packets);
+
+		/* Count size by adding header and paload sizes. */
+		*size += 4 * (payload_size + 1);
+		/* Next word: this packet (header, payload) position + 1. */
+		word_pos += payload_size + 2;
+
+		npackets++;
+	}
+
+	otpc->npackets = npackets;
+
+	return 0;
+}
+
+static struct nvmem_config mchp_nvmem_config = {
+	.name = MCHP_OTPC_NAME,
+	.type = NVMEM_TYPE_OTP,
+	.read_only = true,
+	.word_size = 4,
+	.stride = 4,
+	.reg_read = mchp_otpc_read,
+};
+
+static int mchp_otpc_probe(struct platform_device *pdev)
+{
+	struct nvmem_device *nvmem;
+	struct mchp_otpc *otpc;
+	u32 size;
+	int ret;
+
+	otpc = devm_kzalloc(&pdev->dev, sizeof(*otpc), GFP_KERNEL);
+	if (!otpc)
+		return -ENOMEM;
+
+	otpc->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(otpc->base))
+		return PTR_ERR(otpc->base);
+
+	otpc->dev = &pdev->dev;
+	ret = mchp_otpc_init_packets_list(otpc, &size);
+	if (ret)
+		return ret;
+
+	mchp_nvmem_config.dev = otpc->dev;
+	mchp_nvmem_config.size = size;
+	mchp_nvmem_config.priv = otpc;
+	nvmem = devm_nvmem_register(&pdev->dev, &mchp_nvmem_config);
+
+	return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mchp_otpc_ids[] = {
+	{ .compatible = "microchip,sama7g5-otpc", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, mchp_otpc_ids);
+
+static struct platform_driver mchp_otpc_driver = {
+	.probe = mchp_otpc_probe,
+	.driver = {
+		.name = MCHP_OTPC_NAME,
+		.of_match_table = of_match_ptr(mchp_otpc_ids),
+	},
+};
+module_platform_driver(mchp_otpc_driver);
+
+MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea@microchip.com>");
+MODULE_DESCRIPTION("Microchip SAMA7G5 OTPC driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1

[PATCH 2/2] nvmem: microchip-otpc: add support

[Claudiu Beznea]

Add support for Microchip OTP controller available on SAMA7G5. The OTPC
controls the access to a non-volatile memory. The memory behind OTPC is
organized into packets, packets are composed by a fixed length header
(4 bytes long) and a variable length payload (payload length is available
in the header). When software request the data at an offset in memory
the OTPC will return (via header + data registers) the whole packet that
has a word at that offset. For a packet in OTP memory like below:

offset  OTP Memory layout

         .           .
         .    ...    .
         .           .
0x0E     +-----------+	<--- packet X
         | header  X |
0x12     +-----------+
         | payload X |
0x16     |           |
         |           |
0x1A     |           |
         +-----------+
         .           .
         .    ...    .
         .           .

if user requests data at address 0x16 the data started at 0x0E will be
returned by controller. User will be able to fetch the whole packet
starting at 0x0E (or parts of the packet) via proper registers. The same
packet will be returned if software request the data at offset 0x0E or
0x12 or 0x1A.

The OTP will be populated by Microchip with at least 2 packets first one
being boot configuration packet and the 2nd one being temperature
calibration packet. The packet order will be preserved b/w different chip
revisions but the packet sizes may change.

For the above reasons and to keep the same software able to work on all
chip variants the read function of the driver is working with a packet
id instead of an offset in OTP memory.

Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
 MAINTAINERS                    |   8 +
 drivers/nvmem/Kconfig          |   7 +
 drivers/nvmem/Makefile         |   2 +
 drivers/nvmem/microchip-otpc.c | 288 +++++++++++++++++++++++++++++++++
 4 files changed, 305 insertions(+)
 create mode 100644 drivers/nvmem/microchip-otpc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1bf57fd937b5..f4b646a801ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12953,6 +12953,14 @@ S:	Supported
 F:	Documentation/devicetree/bindings/mtd/atmel-nand.txt
 F:	drivers/mtd/nand/raw/atmel/*
 
+MICROCHIP OTPC DRIVER
+M:	Claudiu Beznea <claudiu.beznea@microchip.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
+F:	drivers/nvmem/microchip-otpc.c
+F:	dt-bindings/nvmem/microchip,otpc.h
+
 MICROCHIP PWM DRIVER
 M:	Claudiu Beznea <claudiu.beznea@microchip.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 967d0084800e..d72d879a6d34 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -107,6 +107,13 @@ config MTK_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called efuse-mtk.
 
+config MICROCHIP_OTPC
+	tristate "Microchip OTPC support"
+	depends on ARCH_AT91 || COMPILE_TEST
+	help
+	  This driver enable the OTP controller available on Microchip SAMA7G5
+	  SoCs. It controlls the access to the OTP memory connected to it.
+
 config NVMEM_NINTENDO_OTP
 	tristate "Nintendo Wii and Wii U OTP Support"
 	depends on WII || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 00e136a0a123..c710b64f9fe4 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -67,3 +67,5 @@ obj-$(CONFIG_NVMEM_SUNPLUS_OCOTP)	+= nvmem_sunplus_ocotp.o
 nvmem_sunplus_ocotp-y		:= sunplus-ocotp.o
 obj-$(CONFIG_NVMEM_APPLE_EFUSES)	+= nvmem-apple-efuses.o
 nvmem-apple-efuses-y 		:= apple-efuses.o
+obj-$(CONFIG_MICROCHIP_OTPC)	+= nvmem-microchip-otpc.o
+nvmem-microchip-otpc-y		:= microchip-otpc.o
diff --git a/drivers/nvmem/microchip-otpc.c b/drivers/nvmem/microchip-otpc.c
new file mode 100644
index 000000000000..5c5ac1bca074
--- /dev/null
+++ b/drivers/nvmem/microchip-otpc.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OTP Memory controller
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudiu Beznea <claudiu.beznea@microchip.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define MCHP_OTPC_CR			(0x0)
+#define MCHP_OTPC_CR_READ		BIT(6)
+#define MCHP_OTPC_MR			(0x4)
+#define MCHP_OTPC_MR_ADDR		GENMASK(31, 16)
+#define MCHP_OTPC_AR			(0x8)
+#define MCHP_OTPC_SR			(0xc)
+#define MCHP_OTPC_SR_READ		BIT(6)
+#define MCHP_OTPC_HR			(0x20)
+#define MCHP_OTPC_HR_SIZE		GENMASK(15, 8)
+#define MCHP_OTPC_DR			(0x24)
+
+#define MCHP_OTPC_NAME			"mchp-otpc"
+#define MCHP_OTPC_SIZE			(11 * 1024)
+
+/**
+ * struct mchp_otpc - OTPC private data structure
+ * @base: base address
+ * @dev: struct device pointer
+ * @packets: list of packets in OTP memory
+ * @npackets: number of packets in OTP memory
+ */
+struct mchp_otpc {
+	void __iomem *base;
+	struct device *dev;
+	struct list_head packets;
+	u32 npackets;
+};
+
+/**
+ * struct mchp_otpc_packet - OTPC packet data structure
+ * @list: list head
+ * @id: packet ID
+ * @offset: packet offset (in words) in OTP memory
+ */
+struct mchp_otpc_packet {
+	struct list_head list;
+	u32 id;
+	u32 offset;
+};
+
+static struct mchp_otpc_packet *mchp_otpc_id_to_packet(struct mchp_otpc *otpc,
+						       u32 id)
+{
+	struct mchp_otpc_packet *packet;
+
+	if (id >= otpc->npackets)
+		return NULL;
+
+	list_for_each_entry(packet, &otpc->packets, list) {
+		if (packet->id == id)
+			return packet;
+	}
+
+	return NULL;
+}
+
+static int mchp_otpc_prepare_read(struct mchp_otpc *otpc,
+				  unsigned int offset)
+{
+	u32 tmp;
+
+	/* Set address. */
+	tmp = readl_relaxed(otpc->base + MCHP_OTPC_MR);
+	tmp &= ~MCHP_OTPC_MR_ADDR;
+	tmp |= FIELD_PREP(MCHP_OTPC_MR_ADDR, offset);
+	writel_relaxed(tmp, otpc->base + MCHP_OTPC_MR);
+
+	/* Set read. */
+	tmp = readl_relaxed(otpc->base + MCHP_OTPC_CR);
+	tmp |= MCHP_OTPC_CR_READ;
+	writel_relaxed(tmp, otpc->base + MCHP_OTPC_CR);
+
+	/* Wait for packet to be transferred into temporary buffers. */
+	return read_poll_timeout(readl_relaxed, tmp, !(tmp & MCHP_OTPC_SR_READ),
+				 10000, 2000, false, otpc->base + MCHP_OTPC_SR);
+}
+
+/*
+ * OTPC memory is organized into packets. Each packets contains a header and
+ * a payload. Header is 4 bytes long and contains the size of the payload.
+ * Payload size varies. The memory footprint is something as follows:
+ *
+ * Memory offset  Memory footprint     Packet ID
+ * -------------  ----------------     ---------
+ *
+ * 0x0            +------------+   <-- packet 0
+ *                | header  0  |
+ * 0x4            +------------+
+ *                | payload 0  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offset1        +------------+   <-- packet 1
+ *                | header  1  |
+ * offset1 + 0x4  +------------+
+ *                | payload 1  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offset2        +------------+   <-- packet 2
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ * offsetN        +------------+   <-- packet N
+ *                | header  N  |
+ * offsetN + 0x4  +------------+
+ *                | payload N  |
+ *                .            .
+ *                .    ...     .
+ *                .            .
+ *                +------------+
+ *
+ * where offset1, offset2, offsetN depends on the size of payload 0, payload 1,
+ * payload N-1.
+ *
+ * The access to memory is done on a per packet basis: the control registers
+ * need to be updated with an offset address (within a packet range) and the
+ * data registers will be update by controller with information contained by
+ * that packet. E.g. if control registers are updated with any address within
+ * the range [offset1, offset2) the data registers are updated by controller
+ * with packet 1. Header data is accessible though MCHP_OTPC_HR register.
+ * Payload data is accessible though MCHP_OTPC_DR and MCHP_OTPC_AR registers.
+ * There is no direct mapping b/w the offset requested by software and the
+ * offset returned by hardware.
+ *
+ * For this, the read function will return the first requested bytes in the
+ * packet. The user will have to be aware of the memory footprint before doing
+ * the read request.
+ */
+static int mchp_otpc_read(void *priv, unsigned int off, void *val,
+			  size_t bytes)
+{
+	struct mchp_otpc *otpc = priv;
+	struct mchp_otpc_packet *packet;
+	u32 *buf = val;
+	u32 offset;
+	size_t len = 0;
+	int ret, payload_size;
+
+	/*
+	 * We reach this point with off being multiple of stride = 4 to
+	 * be able to cross the subsystem. Inside the driver we use continuous
+	 * unsigned integer numbers for packet id, thus devide off by 4
+	 * before passing it to mchp_otpc_id_to_packet().
+	 */
+	packet = mchp_otpc_id_to_packet(otpc, off / 4);
+	if (!packet)
+		return -EINVAL;
+	offset = packet->offset;
+
+	while (len < bytes) {
+		ret = mchp_otpc_prepare_read(otpc, offset);
+		if (ret)
+			return ret;
+
+		/* Read and save header content. */
+		*buf++ = readl_relaxed(otpc->base + MCHP_OTPC_HR);
+		len += sizeof(*buf);
+		offset++;
+		if (len >= bytes)
+			break;
+
+		/* Read and save payload content. */
+		payload_size = FIELD_GET(MCHP_OTPC_HR_SIZE, *(buf - 1));
+		writel_relaxed(0UL, otpc->base + MCHP_OTPC_AR);
+		do {
+			*buf++ = readl_relaxed(otpc->base + MCHP_OTPC_DR);
+			len += sizeof(*buf);
+			offset++;
+			payload_size--;
+		} while (payload_size >= 0 && len < bytes);
+	}
+
+	return 0;
+}
+
+static int mchp_otpc_init_packets_list(struct mchp_otpc *otpc, u32 *size)
+{
+	struct mchp_otpc_packet *packet;
+	u32 word, word_pos = 0, id = 0, npackets = 0, payload_size;
+	int ret;
+
+	INIT_LIST_HEAD(&otpc->packets);
+	*size = 0;
+
+	while (*size < MCHP_OTPC_SIZE) {
+		ret = mchp_otpc_prepare_read(otpc, word_pos);
+		if (ret)
+			return ret;
+
+		word = readl_relaxed(otpc->base + MCHP_OTPC_HR);
+		payload_size = FIELD_GET(MCHP_OTPC_HR_SIZE, word);
+		if (!payload_size)
+			break;
+
+		packet = devm_kzalloc(otpc->dev, sizeof(*packet), GFP_KERNEL);
+		if (!packet)
+			return -ENOMEM;
+
+		packet->id = id++;
+		packet->offset = word_pos;
+		INIT_LIST_HEAD(&packet->list);
+		list_add_tail(&packet->list, &otpc->packets);
+
+		/* Count size by adding header and paload sizes. */
+		*size += 4 * (payload_size + 1);
+		/* Next word: this packet (header, payload) position + 1. */
+		word_pos += payload_size + 2;
+
+		npackets++;
+	}
+
+	otpc->npackets = npackets;
+
+	return 0;
+}
+
+static struct nvmem_config mchp_nvmem_config = {
+	.name = MCHP_OTPC_NAME,
+	.type = NVMEM_TYPE_OTP,
+	.read_only = true,
+	.word_size = 4,
+	.stride = 4,
+	.reg_read = mchp_otpc_read,
+};
+
+static int mchp_otpc_probe(struct platform_device *pdev)
+{
+	struct nvmem_device *nvmem;
+	struct mchp_otpc *otpc;
+	u32 size;
+	int ret;
+
+	otpc = devm_kzalloc(&pdev->dev, sizeof(*otpc), GFP_KERNEL);
+	if (!otpc)
+		return -ENOMEM;
+
+	otpc->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(otpc->base))
+		return PTR_ERR(otpc->base);
+
+	otpc->dev = &pdev->dev;
+	ret = mchp_otpc_init_packets_list(otpc, &size);
+	if (ret)
+		return ret;
+
+	mchp_nvmem_config.dev = otpc->dev;
+	mchp_nvmem_config.size = size;
+	mchp_nvmem_config.priv = otpc;
+	nvmem = devm_nvmem_register(&pdev->dev, &mchp_nvmem_config);
+
+	return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mchp_otpc_ids[] = {
+	{ .compatible = "microchip,sama7g5-otpc", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, mchp_otpc_ids);
+
+static struct platform_driver mchp_otpc_driver = {
+	.probe = mchp_otpc_probe,
+	.driver = {
+		.name = MCHP_OTPC_NAME,
+		.of_match_table = of_match_ptr(mchp_otpc_ids),
+	},
+};
+module_platform_driver(mchp_otpc_driver);
+
+MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea@microchip.com>");
+MODULE_DESCRIPTION("Microchip SAMA7G5 OTPC driver");
+MODULE_LICENSE("GPL");
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel