From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>,
Andreas Kemnade <andreas@kemnade.info>,
Mathieu Malaterre <malat@debian.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paulburton@kernel.org>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Kees Cook <keescook@chromium.org>,
Andi Kleen <ak@linux.intel.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-mips@vger.kernel.org, letux-kernel@openphoenux.org,
kernel@pyra-handheld.com
Subject: Re: [PATCH v7 2/7] nvmem: add driver for JZ4780 efuse
Date: Fri, 28 Feb 2020 15:57:01 +0100 [thread overview]
Message-ID: <8722F126-2032-4AAF-BB99-82B3E9642818@goldelico.com> (raw)
In-Reply-To: <1582901323.3.4@crapouillou.net>
> Am 28.02.2020 um 15:48 schrieb Paul Cercueil <paul@crapouillou.net>:
>
> Hi Nikolaus,
>
> Le ven., févr. 28, 2020 at 14:58, H. Nikolaus Schaller <hns@goldelico.com> a écrit :
>> From: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
>> This patch brings support for the JZ4780 efuse. Currently it only exposes
>> a read only access to the entire 8K bits efuse memory and nvmem cells.
>> To fetch for example the MAC address:
>> dd if=/sys/devices/platform/134100d0.efuse/jz4780-efuse0/nvmem bs=1 skip=34 count=6 status=none | xxd
>> Tested-by: Mathieu Malaterre <malat@debian.org>
>> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>> drivers/nvmem/Kconfig | 12 ++
>> drivers/nvmem/Makefile | 2 +
>> drivers/nvmem/jz4780-efuse.c | 234 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 248 insertions(+)
>> create mode 100644 drivers/nvmem/jz4780-efuse.c
>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
>> index 35efab1ba8d9..d7b7f6d688e7 100644
>> --- a/drivers/nvmem/Kconfig
>> +++ b/drivers/nvmem/Kconfig
>> @@ -55,6 +55,18 @@ config NVMEM_IMX_OCOTP_SCU
>> This is a driver for the SCU On-Chip OTP Controller (OCOTP)
>> available on i.MX8 SoCs.
>> +config JZ4780_EFUSE
>> + tristate "JZ4780 EFUSE Memory Support"
>> + depends on MACH_INGENIC || COMPILE_TEST
>> + depends on HAS_IOMEM
>> + depends on OF
>> + select REGMAP_MMIO
>> + help
>> + Say Y here to include support for JZ4780 efuse memory found on
>> + all JZ4780 SoC based devices.
>> + To compile this driver as a module, choose M here: the module
>> + will be called nvmem_jz4780_efuse.
>> +
>> config NVMEM_LPC18XX_EEPROM
>> tristate "NXP LPC18XX EEPROM Memory Support"
>> depends on ARCH_LPC18XX || COMPILE_TEST
>> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
>> index 6b466cd1427b..65a268d17807 100644
>> --- a/drivers/nvmem/Makefile
>> +++ b/drivers/nvmem/Makefile
>> @@ -18,6 +18,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_JZ4780_EFUSE) += nvmem_jz4780_efuse.o
>> +nvmem_jz4780_efuse-y := jz4780-efuse.o
>> obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
>> nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
>> obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
>> diff --git a/drivers/nvmem/jz4780-efuse.c b/drivers/nvmem/jz4780-efuse.c
>> new file mode 100644
>> index 000000000000..4e9dd340e33a
>> --- /dev/null
>> +++ b/drivers/nvmem/jz4780-efuse.c
>> @@ -0,0 +1,234 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * JZ4780 EFUSE Memory Support driver
>> + *
>> + * Copyright (c) 2017 PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
>> + * Copyright (c) 2020 H. Nikolaus Schaller <hns@goldelico.com>
>> + */
>> +
>> +/*
>> + * Currently supports JZ4780 efuse which has 8K programmable bit.
>> + * Efuse is separated into seven segments as below:
>> + *
>> + * -----------------------------------------------------------------------
>> + * | 64 bit | 128 bit | 128 bit | 3520 bit | 8 bit | 2296 bit | 2048 bit |
>> + * -----------------------------------------------------------------------
>> + *
>> + * The rom itself is accessed using a 9 bit address line and an 8 word wide bus
>> + * which reads/writes based on strobes. The strobe is configured in the config
>> + * register and is based on number of cycles of the bus clock.
>> + *
>> + * Driver supports read only as the writes are done in the Factory.
>> + */
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/module.h>
>> +#include <linux/nvmem-provider.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/timer.h>
>> +
>> +#define JZ_EFUCTRL (0x0) /* Control Register */
>> +#define JZ_EFUCFG (0x4) /* Configure Register*/
>> +#define JZ_EFUSTATE (0x8) /* Status Register */
>> +#define JZ_EFUDATA(n) (0xC + (n) * 4)
>> +
>> +/* We read 32 byte chunks to avoid complexity in the driver. */
>> +#define JZ_EFU_READ_SIZE 32
>> +
>> +#define EFUCTRL_ADDR_MASK 0x3FF
>> +#define EFUCTRL_ADDR_SHIFT 21
>> +#define EFUCTRL_LEN_MASK 0x1F
>> +#define EFUCTRL_LEN_SHIFT 16
>> +#define EFUCTRL_PG_EN BIT(15)
>> +#define EFUCTRL_WR_EN BIT(1)
>> +#define EFUCTRL_RD_EN BIT(0)
>> +
>> +#define EFUCFG_INT_EN BIT(31)
>> +#define EFUCFG_RD_ADJ_MASK 0xF
>> +#define EFUCFG_RD_ADJ_SHIFT 20
>> +#define EFUCFG_RD_STR_MASK 0xF
>> +#define EFUCFG_RD_STR_SHIFT 16
>> +#define EFUCFG_WR_ADJ_MASK 0xF
>> +#define EFUCFG_WR_ADJ_SHIFT 12
>> +#define EFUCFG_WR_STR_MASK 0xFFF
>> +#define EFUCFG_WR_STR_SHIFT 0
>> +
>> +#define EFUSTATE_WR_DONE BIT(1)
>> +#define EFUSTATE_RD_DONE BIT(0)
>> +
>> +struct jz4780_efuse {
>> + struct device *dev;
>> + struct regmap *map;
>> + struct clk *clk;
>> +};
>> +
>> +/* main entry point */
>> +static int jz4780_efuse_read(void *context, unsigned int offset,
>> + void *val, size_t bytes)
>> +{
>> + struct jz4780_efuse *efuse = context;
>> +
>> + while (bytes > 0) {
>> + unsigned int start = offset & ~(JZ_EFU_READ_SIZE - 1);
>> + unsigned int chunk = min(bytes, (start + JZ_EFU_READ_SIZE)
>> + - offset);
>> + char buf[JZ_EFU_READ_SIZE];
>> + unsigned int tmp;
>> + u32 ctrl;
>> + int ret;
>> +
>> + ctrl = (start << EFUCTRL_ADDR_SHIFT)
>> + | ((JZ_EFU_READ_SIZE - 1) << EFUCTRL_LEN_SHIFT)
>> + | EFUCTRL_RD_EN;
>> +
>> + regmap_update_bits(efuse->map, JZ_EFUCTRL,
>> + (EFUCTRL_ADDR_MASK << EFUCTRL_ADDR_SHIFT) |
>> + (EFUCTRL_LEN_MASK << EFUCTRL_LEN_SHIFT) |
>> + EFUCTRL_PG_EN | EFUCTRL_WR_EN |
>> + EFUCTRL_RD_EN,
>> + ctrl);
>> +
>> + ret = regmap_read_poll_timeout(efuse->map, JZ_EFUSTATE,
>> + tmp, tmp & EFUSTATE_RD_DONE,
>> + 1 * MSEC_PER_SEC,
>> + 50 * MSEC_PER_SEC);
>> + if (ret < 0) {
>> + dev_err(efuse->dev, "Time out while reading efuse data");
>> + return ret;
>> + }
>> +
>> + ret = regmap_bulk_read(efuse->map, JZ_EFUDATA(0),
>> + buf, JZ_EFU_READ_SIZE / sizeof(u32));
>> + if (ret < 0)
>> + return ret;
>> +
>> + memcpy(val, &buf[offset - start], chunk);
>> +
>> + val += chunk;
>> + offset += chunk;
>> + bytes -= chunk;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct nvmem_config jz4780_efuse_nvmem_config = {
>> + .name = "jz4780-efuse",
>> + .size = 1024,
>> + .word_size = 1,
>> + .stride = 1,
>> + .owner = THIS_MODULE,
>> + .reg_read = jz4780_efuse_read,
>> +};
>> +
>> +static const struct regmap_config jz4780_efuse_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> + .max_register = JZ_EFUDATA(7),
>> +};
>> +
>> +static int jz4780_efuse_probe(struct platform_device *pdev)
>> +{
>> + struct nvmem_device *nvmem;
>> + struct jz4780_efuse *efuse;
>> + struct nvmem_config cfg;
>> + unsigned long clk_rate;
>> + unsigned long rd_adj;
>> + unsigned long rd_strobe;
>> + struct device *dev = &pdev->dev;
>> + void __iomem *regs;
>> + int ret;
>> +
>> + efuse = devm_kzalloc(dev, sizeof(*efuse), GFP_KERNEL);
>> + if (!efuse)
>> + return -ENOMEM;
>> +
>> + regs = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(regs))
>> + return PTR_ERR(regs);
>> +
>> + efuse->map = devm_regmap_init_mmio(dev, regs,
>> + &jz4780_efuse_regmap_config);
>> + if (IS_ERR(efuse->map))
>> + return PTR_ERR(efuse->map);
>> +
>> + efuse->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(efuse->clk))
>> + return PTR_ERR(efuse->clk);
>> +
>> + ret = clk_prepare_enable(efuse->clk);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = devm_add_action_or_reset(&pdev->dev,
>> + &clk_disable_unprepare,
>> + efuse->clk);
>
> That's what I thought, this does not build:
>
> CC drivers/nvmem/jz4780-efuse.o
> drivers/nvmem/jz4780-efuse.c: In function 'jz4780_efuse_probe':
> drivers/nvmem/jz4780-efuse.c:168:12: error: passing argument 2 of 'devm_add_action_or_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 168 | &clk_disable_unprepare,
> | ^~~~~~~~~~~~~~~~~~~~~~
> | |
> | void (*)(struct clk *)
> In file included from ./include/linux/platform_device.h:13,
> from drivers/nvmem/jz4780-efuse.c:29:
> ./include/linux/device.h:256:16: note: expected 'void (*)(void *)' but argument is of type 'void (*)(struct clk *)'
> 256 | void (*action)(void *), void *data)
> | ~~~~~~~^~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:268: drivers/nvmem/jz4780-efuse.o] Error 1
> make[1]: *** [scripts/Makefile.build:505: drivers/nvmem] Error 2
> make: *** [Makefile:1681: drivers] Error 2
>
>
> You need a local function of type 'void foo(void *data)' that just calls clk_disable_unprepare(data) and the compiler will be happy.
> (btw - no need to deference functions pointers, since they are already pointers)
Well, this asks for a devm_clk_enable_prepare but it was apparently rejected...
https://lore.kernel.org/patchwork/patch/755667/
>
> With that said, I expect you to at least compile-test the patchset before sending it upstream...
I have compiled and tested it on real hardware. But missed the warning because my cross-compiler seems to emit a warning only.
Sorry, I don't have a good day and after 7 rounds one wants to get things through the door and with least effort as quick as possible :)
BR,
Nikolaus
next prev parent reply other threads:[~2020-02-28 14:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 13:58 [PATCH v7 0/7] MIPS: CI20: Add efuse driver for Ingenic JZ4780 and attach to DM9000 for stable MAC addresses H. Nikolaus Schaller
2020-02-28 13:58 ` [PATCH v7 1/7] memory: jz4780_nemc: Only request IO memory the driver will use H. Nikolaus Schaller
2020-02-28 13:58 ` [PATCH v7 2/7] nvmem: add driver for JZ4780 efuse H. Nikolaus Schaller
2020-02-28 14:48 ` Paul Cercueil
2020-02-28 14:57 ` H. Nikolaus Schaller [this message]
2020-02-28 13:58 ` [PATCH v7 3/7] Bindings: nvmem: add bindings " H. Nikolaus Schaller
2020-02-28 14:40 ` Paul Cercueil
2020-02-28 14:47 ` H. Nikolaus Schaller
2020-02-28 14:52 ` Paul Cercueil
2020-02-28 13:58 ` [PATCH v7 4/7] Documentation: ABI: nvmem: add documentation for JZ4780 efuse ABI H. Nikolaus Schaller
2020-02-28 13:58 ` [PATCH v7 5/7] nvmem: MAINTAINERS: add maintainer for JZ4780 efuse driver H. Nikolaus Schaller
2020-02-28 13:58 ` [PATCH v7 6/7] MIPS: DTS: JZ4780: define node for JZ4780 efuse H. Nikolaus Schaller
2020-02-28 13:58 ` [PATCH v7 7/7] MIPS: DTS: CI20: make DM9000 Ethernet controller use NVMEM to find the default MAC address H. Nikolaus Schaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8722F126-2032-4AAF-BB99-82B3E9642818@goldelico.com \
--to=hns@goldelico.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=ak@linux.intel.com \
--cc=andreas@kemnade.info \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=kernel@pyra-handheld.com \
--cc=krzk@kernel.org \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=malat@debian.org \
--cc=mark.rutland@arm.com \
--cc=mchehab+samsung@kernel.org \
--cc=paul@crapouillou.net \
--cc=paulburton@kernel.org \
--cc=prasannatsmkumar@gmail.com \
--cc=ralf@linux-mips.org \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).