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

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

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
>

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