From: Rafał Miłecki <[email protected]>
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 <[email protected]>
---
.../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 <[email protected]>
+
+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
From: Rafał Miłecki <[email protected]>
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 <[email protected]>
---
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 <[email protected]>
+ */
+
+#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
On Fri, Jan 27, 2023 at 06:58:30PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <[email protected]>
>
> 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 <[email protected]>
> ---
> .../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 <[email protected]>
> +
> +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
>
On Fri, Jan 27, 2023 at 06:58:31PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <[email protected]>
>
> 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 <[email protected]>
> ---
> 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 <[email protected]>
> + */
> +
> +#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