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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230130205618.GB3290808-robh@kernel.org>
Date:   Mon, 30 Jan 2023 14:56:18 -0600
From:   Rob Herring <robh@...nel.org>
To:     Rafał Miłecki <zajec5@...il.com>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Walle <michael@...le.cc>, devicetree@...r.kernel.org,
        linux-mtd@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH 2/2] nvmem: add generic driver for devices with I/O based
 access

On Fri, Jan 27, 2023 at 06:58:31PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@...ecki.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@...ecki.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@...ecki.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