[PATCH 1/2] dt-bindings: nvmem: io: new binding for IO accessible NVMEM devices

[PATCH 1/2] dt-bindings: nvmem: io: new binding for IO accessible NVMEM devices

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

With the NVMEM layouts binding in place we should now use:
1. NVMEM device access bindings
2. NVMEM content description bindings

This binding allows describing NVMEM devices that can be accessed using
IO mappings.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 .../devicetree/bindings/nvmem/io.yaml         | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/io.yaml

diff --git a/Documentation/devicetree/bindings/nvmem/io.yaml b/Documentation/devicetree/bindings/nvmem/io.yaml
new file mode 100644
index 000000000000..67e0aae9cd94
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/io.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/io.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IO access based NVMEM
+
+description: |
+  This binding describes simple NVMEM devices that can be accessed by simply
+  mapping a predefined IO address.
+
+  It's a generic solution for providing NVMEM content access. The way of
+  handling actual content may be device specific and can be described using a
+  proper layout.
+
+maintainers:
+  - Rafał Miłecki <rafal@milecki.pl>
+
+allOf:
+  - $ref: nvmem.yaml#
+
+properties:
+  compatible:
+    const: io-nvmem
+
+  reg:
+    maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    nvmem@10000 {
+        compatible = "io-nvmem";
+        reg = <0x10000000 0x10000>;
+    };
-- 
2.34.1

[PATCH 2/2] nvmem: add generic driver for devices with I/O based access

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

With nvmem layouts in place we should now work on plain content access
NVMEM drivers (e.g. IO one). Actual NVMEM content handling should go to
layout drivers.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 drivers/nvmem/Kconfig  |  7 ++++
 drivers/nvmem/Makefile |  2 ++
 drivers/nvmem/io.c     | 79 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 88 insertions(+)
 create mode 100644 drivers/nvmem/io.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 789729ff7e50..e77bfe6eb52e 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -90,6 +90,13 @@ config NVMEM_IMX_OCOTP_SCU
 	  This is a driver for the SCU On-Chip OTP Controller (OCOTP)
 	  available on i.MX8 SoCs.
 
+config NVMEM_IO
+	tristate "IO access based NVMEM support"
+	depends on HAS_IOMEM
+	help
+	  This driver provides support for NVMEM devices that can be accessed
+	  using I/O mapping.
+
 config NVMEM_JZ4780_EFUSE
 	tristate "JZ4780 EFUSE Memory Support"
 	depends on MACH_INGENIC || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 442f9a4876a5..82db0a89c4d6 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -20,6 +20,8 @@ obj-$(CONFIG_NVMEM_IMX_OCOTP)		+= nvmem-imx-ocotp.o
 nvmem-imx-ocotp-y			:= imx-ocotp.o
 obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU)	+= nvmem-imx-ocotp-scu.o
 nvmem-imx-ocotp-scu-y			:= imx-ocotp-scu.o
+obj-$(CONFIG_NVMEM_IO)			+= nvmem-io.o
+nvmem-io-y				:= io.o
 obj-$(CONFIG_NVMEM_JZ4780_EFUSE)	+= nvmem_jz4780_efuse.o
 nvmem_jz4780_efuse-y			:= jz4780-efuse.o
 obj-$(CONFIG_NVMEM_LAN9662_OTPC)	+= nvmem-lan9662-otpc.o
diff --git a/drivers/nvmem/io.c b/drivers/nvmem/io.c
new file mode 100644
index 000000000000..307526fda036
--- /dev/null
+++ b/drivers/nvmem/io.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Rafał Miłecki <rafal@milecki.pl>
+ */
+
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+
+struct io_nvmem {
+	void __iomem *base;
+};
+
+static int io_nvmem_read(void *context, unsigned int offset, void *val, size_t bytes)
+{
+	struct io_nvmem *priv = context;
+	u8 *dst = val;
+
+	while (bytes--)
+		*dst++ = readb(priv->base + offset++);
+
+	return 0;
+}
+
+static int io_nvmem_probe(struct platform_device *pdev)
+{
+	struct nvmem_config config = {
+		.name = "io-nvmem",
+		.reg_read = io_nvmem_read,
+	};
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct io_nvmem *priv;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	config.dev = dev;
+	config.priv = priv;
+	config.size = resource_size(res);
+
+	if (!device_property_present(dev, "read-only"))
+		dev_warn(dev, "Writing is not supported yet");
+
+	return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
+}
+
+static const struct of_device_id io_nvmem_of_match_table[] = {
+	{ .compatible = "io-nvmem", },
+	{},
+};
+
+static struct platform_driver io_nvmem_driver = {
+	.probe = io_nvmem_probe,
+	.driver = {
+		.name = "io_nvmem",
+		.of_match_table = io_nvmem_of_match_table,
+	},
+};
+
+static int __init io_nvmem_init(void)
+{
+	return platform_driver_register(&io_nvmem_driver);
+}
+
+subsys_initcall_sync(io_nvmem_init);
+
+MODULE_AUTHOR("Rafał Miłecki");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, io_nvmem_of_match_table);
-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: nvmem: io: new binding for IO accessible NVMEM devices

[Rob Herring]

On Fri, Jan 27, 2023 at 06:58:30PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> With the NVMEM layouts binding in place we should now use:
> 1. NVMEM device access bindings
> 2. NVMEM content description bindings
> 
> This binding allows describing NVMEM devices that can be accessed using
> IO mappings.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  .../devicetree/bindings/nvmem/io.yaml         | 37 +++++++++++++++++++

What do we call nvmem using ISA/PCI IO space? That was my first thought 
seeing "IO". Probably unlikely, but still. "MMIO" instead?

>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/io.yaml
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/io.yaml b/Documentation/devicetree/bindings/nvmem/io.yaml
> new file mode 100644
> index 000000000000..67e0aae9cd94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/io.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/nvmem/io.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: IO access based NVMEM
> +
> +description: |
> +  This binding describes simple NVMEM devices that can be accessed by simply
> +  mapping a predefined IO address.
> +
> +  It's a generic solution for providing NVMEM content access. The way of
> +  handling actual content may be device specific and can be described using a
> +  proper layout.

As the accesses are memory-mapped, the child nodes should also have 
memory-mapped addresses. IOW, you need 'ranges', '#address-cells', 
'#size-cells'.

> +
> +maintainers:
> +  - Rafał Miłecki <rafal@milecki.pl>
> +
> +allOf:
> +  - $ref: nvmem.yaml#
> +
> +properties:
> +  compatible:
> +    const: io-nvmem
> +
> +  reg:
> +    maxItems: 1

The first addition here will be access size restrictions. Perhaps add 
that now (reg-io-width).

> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    nvmem@10000 {
> +        compatible = "io-nvmem";
> +        reg = <0x10000000 0x10000>;
> +    };
> -- 
> 2.34.1
> 

Re: [PATCH 2/2] nvmem: add generic driver for devices with I/O based access

[Rob Herring]

On Fri, Jan 27, 2023 at 06:58:31PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> With nvmem layouts in place we should now work on plain content access
> NVMEM drivers (e.g. IO one). Actual NVMEM content handling should go to
> layout drivers.

Surely we have some existing driver that could use this? Point its 
compatible here and delete the driver.

I'm normally against 'generic' bindings, but for generic drivers. In 
this case, I think nvmem is simple enough to be generic (hopefully).

> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  drivers/nvmem/Kconfig  |  7 ++++
>  drivers/nvmem/Makefile |  2 ++
>  drivers/nvmem/io.c     | 79 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 88 insertions(+)
>  create mode 100644 drivers/nvmem/io.c
> 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 789729ff7e50..e77bfe6eb52e 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -90,6 +90,13 @@ config NVMEM_IMX_OCOTP_SCU
>  	  This is a driver for the SCU On-Chip OTP Controller (OCOTP)
>  	  available on i.MX8 SoCs.
>  
> +config NVMEM_IO
> +	tristate "IO access based NVMEM support"
> +	depends on HAS_IOMEM
> +	help
> +	  This driver provides support for NVMEM devices that can be accessed
> +	  using I/O mapping.
> +
>  config NVMEM_JZ4780_EFUSE
>  	tristate "JZ4780 EFUSE Memory Support"
>  	depends on MACH_INGENIC || COMPILE_TEST
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index 442f9a4876a5..82db0a89c4d6 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -20,6 +20,8 @@ obj-$(CONFIG_NVMEM_IMX_OCOTP)		+= nvmem-imx-ocotp.o
>  nvmem-imx-ocotp-y			:= imx-ocotp.o
>  obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU)	+= nvmem-imx-ocotp-scu.o
>  nvmem-imx-ocotp-scu-y			:= imx-ocotp-scu.o
> +obj-$(CONFIG_NVMEM_IO)			+= nvmem-io.o
> +nvmem-io-y				:= io.o
>  obj-$(CONFIG_NVMEM_JZ4780_EFUSE)	+= nvmem_jz4780_efuse.o
>  nvmem_jz4780_efuse-y			:= jz4780-efuse.o
>  obj-$(CONFIG_NVMEM_LAN9662_OTPC)	+= nvmem-lan9662-otpc.o
> diff --git a/drivers/nvmem/io.c b/drivers/nvmem/io.c
> new file mode 100644
> index 000000000000..307526fda036
> --- /dev/null
> +++ b/drivers/nvmem/io.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Rafał Miłecki <rafal@milecki.pl>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +
> +struct io_nvmem {
> +	void __iomem *base;
> +};
> +
> +static int io_nvmem_read(void *context, unsigned int offset, void *val, size_t bytes)
> +{
> +	struct io_nvmem *priv = context;
> +	u8 *dst = val;
> +
> +	while (bytes--)
> +		*dst++ = readb(priv->base + offset++);

memcpy_fromio

readb() has a barrier to ensure ordering. Not likely needed here.

Rob