From: Rafał Miłecki <[email protected]>
There are a lot of devices with NVMEM content stored in MTD devices in
relevant partitions. Add a DT binding for marking such partitions.
Note: Linux already treats every MTD partition as NVMEM provider so in
general it doesn't need to care about this binding. It's meant just to
make DT clearer in describing hardware.
Signed-off-by: Rafał Miłecki <[email protected]>
---
As explained in commit body this isn't really needed for Linux. I
thought it'd be a small nice addition for writing clear DTS files.
---
.../devicetree/bindings/nvmem/mtd.yaml | 52 +++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/mtd.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/mtd.yaml b/Documentation/devicetree/bindings/nvmem/mtd.yaml
new file mode 100644
index 000000000000..7435b2803cf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/mtd.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/mtd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTD access based NVMEM
+
+description: |
+ MTD partitions can be NVMEM providers. This binding allows explicitly marking
+ such partitions.
+
+ The exact way of handling MTD partition content (NVMEM cells) should be
+ described using a proper NVMEM layout.
+
+maintainers:
+ - Rafał Miłecki <[email protected]>
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+ compatible:
+ const: mtd-nvmem
+
+ reg:
+ maxItems: 1
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ compatible = "mtd-nvmem";
+ reg = <0x0 0x40000>;
+ label = "device-data";
+
+ nvmem-layout {
+ /* Just a dummy example: Kontron can be found on OTP actually */
+ compatible = "kontron,sl28-vpd";
+ };
+ };
+ };
--
2.34.1
Hi Rafał,
[email protected] wrote on Fri, 10 Mar 2023 11:53:30 +0100:
> From: Rafał Miłecki <[email protected]>
>
> There are a lot of devices with NVMEM content stored in MTD devices in
> relevant partitions. Add a DT binding for marking such partitions.
>
> Note: Linux already treats every MTD partition as NVMEM provider so in
> general it doesn't need to care about this binding. It's meant just to
> make DT clearer in describing hardware.
>
> Signed-off-by: Rafał Miłecki <[email protected]>
> ---
> As explained in commit body this isn't really needed for Linux. I
> thought it'd be a small nice addition for writing clear DTS files.
> ---
> .../devicetree/bindings/nvmem/mtd.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/mtd.yaml
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mtd.yaml b/Documentation/devicetree/bindings/nvmem/mtd.yaml
> new file mode 100644
> index 000000000000..7435b2803cf9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/mtd.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MTD access based NVMEM
> +
> +description: |
> + MTD partitions can be NVMEM providers. This binding allows explicitly marking
> + such partitions.
We already have that, it's nvmem-cell? I understand what you want to
do, but I think it suffers from a common problem, see below.
> + The exact way of handling MTD partition content (NVMEM cells) should be
> + described using a proper NVMEM layout.
Ok so I believe this is another solution for the layout offset proposed
by Michael. Except that it only fixes it for mtd. I think I would
prefer the former solution which handles all nvmem cases.
> +
> +maintainers:
> + - Rafał Miłecki <[email protected]>
> +
> +allOf:
> + - $ref: nvmem.yaml#
> + - $ref: /schemas/mtd/partitions/partition.yaml#
> +
> +properties:
> + compatible:
> + const: mtd-nvmem
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + compatible = "mtd-nvmem";
Actually there has been valid push-back from devlink gurus against stale
compatibles (on a device-driver point of view) like that. Maybe
something like this instead:
partition@x{
<mtd-nvmem-property>
?
> + reg = <0x0 0x40000>;
> + label = "device-data";
> +
> + nvmem-layout {
> + /* Just a dummy example: Kontron can be found on OTP actually */
> + compatible = "kontron,sl28-vpd";
The Onie tlv compatible would perfectly apply here.
> + };
> + };
> + };
Thanks,
Miquèl