[{"id":1762615,"web_url":"http://patchwork.ozlabs.org/comment/1762615/","msgid":"","list_archive_url":null,"date":"2017-09-04T12:58:03","subject":"Re: [PATCH v1 2/3] nvmem: uniphier: add UniPhier eFuse driver","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"2017-09-01 8:20 GMT+09:00 Keiji Hayashibara :\n> Add eFuse driver for Socionext UniPhier series SoC.\n> Note that eFuse device is under soc-glue and this register\n> implements as read only.\n>\n> Signed-off-by: Keiji Hayashibara \n> ---\n> arch/arm64/configs/defconfig | 1 +\n> drivers/nvmem/Kconfig | 11 +++++\n> drivers/nvmem/Makefile | 2 +\n> drivers/nvmem/uniphier-efuse.c | 98 ++++++++++++++++++++++++++++++++++++++++++\n> 4 files changed, 112 insertions(+)\n> create mode 100644 drivers/nvmem/uniphier-efuse.c\n>\n> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig\n> index 6c7d147..5c38b4a 100644\n> --- a/arch/arm64/configs/defconfig\n> +++ b/arch/arm64/configs/defconfig\n> @@ -514,6 +514,7 @@ CONFIG_PHY_XGENE=y\n> CONFIG_PHY_TEGRA_XUSB=y\n> CONFIG_QCOM_L2_PMU=y\n> CONFIG_QCOM_L3_PMU=y\n> +CONFIG_UNIPHIER_EFUSE=y\n> CONFIG_ARM_SCPI_PROTOCOL=y\n> CONFIG_RASPBERRYPI_FIRMWARE=y\n> CONFIG_EFI_CAPSULE_LOADER=y\n\n\nYou need to send this separately\n(after this driver is accepted)\n\n\n\n> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig\n> index 101ced4..aaeaebe 100644\n> --- a/drivers/nvmem/Kconfig\n> +++ b/drivers/nvmem/Kconfig\n> @@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID\n> This driver can also be built as a module. If so, the module\n> will be called nvmem_sunxi_sid.\n>\n> +config UNIPHIER_EFUSE\n> + tristate \"UniPhier SoCs eFuse support\"\n> + depends on ARCH_UNIPHIER || COMPILE_TEST\n> + depends on OF && MFD_SYSCON\n> + help\n> + This is a simple drive to dump specified values of UniPhier SoC\n> + from eFuse.\n\n\ns/drive/driver/\n\n\nI see the same typo in ROCKCHIP_EFUSE.\n\nYou copied it verbatim.\n\n\n\n\n> + This driver can also be built as a module. If so, the module\n> + will be called nvmem_uniphier-efuse.\n\n\nI do not like a mixture of '_' and '-' though...\n\n\n\n\n\n> config NVMEM_VF610_OCOTP\n> tristate \"VF610 SoC OCOTP support\"\n> depends on SOC_VF610 || COMPILE_TEST\n> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile\n> index 1731406..f5277c3 100644\n> --- a/drivers/nvmem/Makefile\n> +++ b/drivers/nvmem/Makefile\n> @@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) += nvmem_rockchip_efuse.o\n> nvmem_rockchip_efuse-y := rockchip-efuse.o\n> obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o\n> nvmem_sunxi_sid-y := sunxi_sid.o\n> +obj-$(CONFIG_UNIPHIER_EFUSE) += nvmem_uniphier-efuse.o\n> +nvmem_uniphier-efuse-y := uniphier-efuse.o\n> obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o\n> nvmem-vf610-ocotp-y := vf610-ocotp.o\n> obj-$(CONFIG_MESON_EFUSE) += nvmem_meson_efuse.o\n> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c\n> new file mode 100644\n> index 0000000..d553fa3\n> --- /dev/null\n> +++ b/drivers/nvmem/uniphier-efuse.c\n> @@ -0,0 +1,98 @@\n> +/*\n> + * UniPhier eFuse driver\n> + *\n> + * Copyright (C) 2017 Socionext Inc.\n> + *\n> + * This program is free software; you can redistribute it and/or modify\n> + * it under the terms of the GNU General Public License version 2 as\n> + * published by the Free Software Foundation.\n> + *\n> + * This program is distributed in the hope that it will be useful,\n> + * but WITHOUT ANY WARRANTY; without even the implied warranty of\n> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n> + * GNU General Public License for more details.\n> + */\n> +\n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +#include \n> +\n> +#define UNIPHIER_EFUSE_WORD_SIZE 4\n> +#define UNIPHIER_EFUSE_STRIDE 4\n> +\n> +static int uniphier_reg_read(void *context,\n> + unsigned int offset, void *val, size_t bytes)\n> +{\n> + int words = bytes / UNIPHIER_EFUSE_WORD_SIZE;\n> +\n> + return regmap_bulk_read(context, offset, val, words);\n> +}\n> +\n> +static struct nvmem_config econfig = {\n> + .name = \"uniphier-efuse\",\n> + .owner = THIS_MODULE,\n> + .read_only = true,\n> + .reg_read = uniphier_reg_read,\n> + .word_size = UNIPHIER_EFUSE_WORD_SIZE,\n> + .stride = UNIPHIER_EFUSE_STRIDE,\n> +};\n\n\n\n\"struct nvmem_config\" exists for the purpose of containing\ndriver-specific parameters.\nDo you still want to use\nUNIPHIER_EFUSE_WORD_SIZE / UNIPHIER_EFUSE_STRIDE macros here?\n\n\n\n\nstatic struct nvmem_config econfig = {\n .name = \"uniphier-efuse\",\n .owner = THIS_MODULE,\n .read_only = true,\n .reg_read = uniphier_reg_read,\n .word_size = 4,\n .stride = 4,\n};\n\nlooks nicer in my taste.\n\n\n\nBTW, is there really no possibility\nwhere the unphier_efuse_probe() is run concurrently?\n\nMany other drivers pass statically allocated memory\nto nvmem_register() like this...\n\n\n\n\n> +static int uniphier_efuse_probe(struct platform_device *pdev)\n> +{\n> + struct device *dev = &pdev->dev;\n> + struct nvmem_device *nvmem;\n> + struct regmap *regmap;\n> + struct resource res;\n> + int ret;\n> +\n> + ret = of_address_to_resource(dev->of_node, 0, &res);\n> + if (ret)\n> + return ret;\n> +\n> + regmap = syscon_node_to_regmap(dev->of_node);\n> + if (IS_ERR(regmap))\n> + return PTR_ERR(regmap);\n\n\nIn my understanding,\nsyscon_node_to_regmap() is generally useful\nto get regmap of another node,\ni.e. it is often used together with of_get_parent / of_parse_phandle etc.\n\nYou can use devm_regmap_init_mmio()\nto init regmap for itself.\n\n\nBTW, what is your motivation of using regmap?\n\n\nI think what you want to do is\nthe same as mtk-efuse.c, right?\n(and qfprom.c is similar, the difference is just register width)\n\n\n\n\n\n\n> + econfig.size = resource_size(&res);\n> + econfig.priv = regmap;\n> + econfig.dev = dev;\n> +\n> + nvmem = nvmem_register(&econfig);\n> + if (IS_ERR(nvmem))\n> + return PTR_ERR(nvmem);\n> +\n> + platform_set_drvdata(pdev, nvmem);\n> +\n> + return 0;\n> +}\n> +\n> +static int uniphier_efuse_remove(struct platform_device *pdev)\n> +{\n> + struct nvmem_device *nvmem = platform_get_drvdata(pdev);\n> +\n> + return nvmem_unregister(nvmem);\n> +}\n> +\n> +static const struct of_device_id uniphier_efuse_of_match[] = {\n> + { .compatible = \"socionext,uniphier-efuse\",},\n> + {/* sentinel */},\n> +};\n> +MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);\n> +\n> +static struct platform_driver uniphier_efuse_driver = {\n> + .probe = uniphier_efuse_probe,\n> + .remove = uniphier_efuse_remove,\n> + .driver = {\n> + .name = \"uniphier-efuse\",\n> + .of_match_table = uniphier_efuse_of_match,\n> + },\n> +};\n> +module_platform_driver(uniphier_efuse_driver);\n> +\n> +MODULE_AUTHOR(\"Keiji Hayashibara \");\n> +MODULE_DESCRIPTION(\"UniPhier eFuse driver\");\n> +MODULE_LICENSE(\"GPL v2\");\n> --\n> 2.7.4\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"y1EtS6sH\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm8zz5tjnz9sNr\n\tfor ;\n\tMon, 4 Sep 2017 22:58:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753588AbdIDM6y (ORCPT\n\t);\n\tMon, 4 Sep 2017 08:58:54 -0400","from conssluserg-05.nifty.com ([210.131.2.90]:62918 \"EHLO\n\tconssluserg-05.nifty.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753727AbdIDM6x (ORCPT\n\t); Mon, 4 Sep 2017 08:58:53 -0400","from mail-yw0-f169.google.com (mail-yw0-f169.google.com\n\t[209.85.161.169]) (authenticated)\n\tby conssluserg-05.nifty.com with ESMTP id v84CwivV016028;\n\tMon, 4 Sep 2017 21:58:45 +0900","by mail-yw0-f169.google.com with SMTP id x144so1760793ywg.2;\n\tMon, 04 Sep 2017 05:58:44 -0700 (PDT)","by 10.37.164.225 with HTTP; Mon, 4 Sep 2017 05:58:03 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com v84CwivV016028","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1504529925;\n\tbh=ZXeCNk//3O16J+ytoX6suibjtiCM9ZhsH+n6r5zxP4Y=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=y1EtS6sHqICsUGNwPHcBUdVYkO4HHak0vElhYcDiXWSmfaYbhhkxoreZt3BAItv5l\n\tYD100v6IKgm2tMUovbYNI5VGQ2AXWaW+duaHaWLb3QhzK+PWanbWcOkgPDDikGKWSA\n\t1FZxCjlUY+YgAF0FGT+5PMek03a/zZ0KFpbIPeqx9vTxbmSOvG9NV/qXgKPjsLaoGY\n\t27wXm+ZRoTGDkbfCWngZxVrA7xGD33h2LSI62yWovfOaq6t/nV3ZepXUjtgQ9tgkPt\n\tmTPZoxeczZPMcarI+I5Gz7sTtfNayn8428MUURqttTIgF9Sg9udavDH/6d/tcoETrH\n\t/6TFbA6xpNnHQ==","X-Nifty-SrcIP":"[209.85.161.169]","X-Gm-Message-State":"AHPjjUglR1STV5pIqrKu3N95dF67DAaNO0hG5KE4vcuYZeyoOoivlr27\n\tm7Vh+AKIyj3A4I9X46Grqr1r4o3Hgg==","X-Google-Smtp-Source":"ADKCNb7O/5uDfBh8vv9djWmZR4HhSTatTjKttUSlMIVWHqjg78vViRLYiaPHfWzc5zxg3uf4D1RYqUYcCmOwJzf57MQ=","X-Received":"by 10.129.123.194 with SMTP id w185mr240814ywc.333.1504529923801;\n\tMon, 04 Sep 2017 05:58:43 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<1504221620-358-3-git-send-email-hayashibara.keiji@socionext.com>","References":"<1504221620-358-1-git-send-email-hayashibara.keiji@socionext.com>\n\t<1504221620-358-3-git-send-email-hayashibara.keiji@socionext.com>","From":"Masahiro Yamada ","Date":"Mon, 4 Sep 2017 21:58:03 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v1 2/3] nvmem: uniphier: add UniPhier eFuse driver","To":"Keiji Hayashibara ","Cc":"Srinivas Kandagatla ,\n\tRob Herring , devicetree@vger.kernel.org,\n\tlinux-arm-kernel ,\n\tLinux Kernel Mailing List ,\n\tMasami Hiramatsu ,\n\tJassi Brar ,\n\tKunihiko Hayashi ,\n\tKiyoshi Owada ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764442,"web_url":"http://patchwork.ozlabs.org/comment/1764442/","msgid":"<000001d32771$544d0dc0$fce72940$@socionext.com>","list_archive_url":null,"date":"2017-09-07T00:36:21","subject":"RE: [PATCH v1 2/3] nvmem: uniphier: add UniPhier eFuse driver","submitter":{"id":71746,"url":"http://patchwork.ozlabs.org/api/people/71746/","name":"Keiji Hayashibara","email":"hayashibara.keiji@socionext.com"},"content":"Hello Yamada-san,\n\nThank you for your comment.\n\n> From: Masahiro Yamada [mailto:yamada.masahiro@socionext.com]\n> Sent: Monday, September 4, 2017 9:58 PM\n> \n> 2017-09-01 8:20 GMT+09:00 Keiji Hayashibara\n> :\n> > Add eFuse driver for Socionext UniPhier series SoC.\n> > Note that eFuse device is under soc-glue and this register implements\n> > as read only.\n> >\n> > Signed-off-by: Keiji Hayashibara \n> > ---\n> > arch/arm64/configs/defconfig | 1 +\n> > drivers/nvmem/Kconfig | 11 +++++\n> > drivers/nvmem/Makefile | 2 +\n> > drivers/nvmem/uniphier-efuse.c | 98\n> > ++++++++++++++++++++++++++++++++++++++++++\n> > 4 files changed, 112 insertions(+)\n> > create mode 100644 drivers/nvmem/uniphier-efuse.c\n> >\n> > diff --git a/arch/arm64/configs/defconfig\n> > b/arch/arm64/configs/defconfig index 6c7d147..5c38b4a 100644\n> > --- a/arch/arm64/configs/defconfig\n> > +++ b/arch/arm64/configs/defconfig\n> > @@ -514,6 +514,7 @@ CONFIG_PHY_XGENE=y CONFIG_PHY_TEGRA_XUSB=y\n> > CONFIG_QCOM_L2_PMU=y CONFIG_QCOM_L3_PMU=y\n> > +CONFIG_UNIPHIER_EFUSE=y\n> > CONFIG_ARM_SCPI_PROTOCOL=y\n> > CONFIG_RASPBERRYPI_FIRMWARE=y\n> > CONFIG_EFI_CAPSULE_LOADER=y\n> \n> \n> You need to send this separately\n> (after this driver is accepted)\n\nI see.\nNext I will post this separately.\n\n> \n> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig index\n> > 101ced4..aaeaebe 100644\n> > --- a/drivers/nvmem/Kconfig\n> > +++ b/drivers/nvmem/Kconfig\n> > @@ -123,6 +123,17 @@ config NVMEM_SUNXI_SID\n> > This driver can also be built as a module. If so, the module\n> > will be called nvmem_sunxi_sid.\n> >\n> > +config UNIPHIER_EFUSE\n> > + tristate \"UniPhier SoCs eFuse support\"\n> > + depends on ARCH_UNIPHIER || COMPILE_TEST\n> > + depends on OF && MFD_SYSCON\n> > + help\n> > + This is a simple drive to dump specified values of UniPhier\n> SoC\n> > + from eFuse.\n> \n> \n> s/drive/driver/\n> \n> \n> I see the same typo in ROCKCHIP_EFUSE.\n> \n> You copied it verbatim.\n> \n\nI will fix it...\n\n> \n> \n> > + This driver can also be built as a module. If so, the module\n> > + will be called nvmem_uniphier-efuse.\n> \n> \n> I do not like a mixture of '_' and '-' though...\n> \n\nI will fix it.\n> \n> \n> > config NVMEM_VF610_OCOTP\n> > tristate \"VF610 SoC OCOTP support\"\n> > depends on SOC_VF610 || COMPILE_TEST diff --git\n> > a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile index\n> > 1731406..f5277c3 100644\n> > --- a/drivers/nvmem/Makefile\n> > +++ b/drivers/nvmem/Makefile\n> > @@ -26,6 +26,8 @@ obj-$(CONFIG_ROCKCHIP_EFUSE) +=\n> nvmem_rockchip_efuse.o\n> > nvmem_rockchip_efuse-y := rockchip-efuse.o\n> > obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o\n> > nvmem_sunxi_sid-y := sunxi_sid.o\n> > +obj-$(CONFIG_UNIPHIER_EFUSE) += nvmem_uniphier-efuse.o\n> > +nvmem_uniphier-efuse-y := uniphier-efuse.o\n> > obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o\n> > nvmem-vf610-ocotp-y := vf610-ocotp.o\n> > obj-$(CONFIG_MESON_EFUSE) += nvmem_meson_efuse.o\n> > diff --git a/drivers/nvmem/uniphier-efuse.c\n> > b/drivers/nvmem/uniphier-efuse.c new file mode 100644 index\n> > 0000000..d553fa3\n> > --- /dev/null\n> > +++ b/drivers/nvmem/uniphier-efuse.c\n> > @@ -0,0 +1,98 @@\n> > +/*\n> > + * UniPhier eFuse driver\n> > + *\n> > + * Copyright (C) 2017 Socionext Inc.\n> > + *\n> > + * This program is free software; you can redistribute it and/or\n> > +modify\n> > + * it under the terms of the GNU General Public License version 2 as\n> > + * published by the Free Software Foundation.\n> > + *\n> > + * This program is distributed in the hope that it will be useful,\n> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of\n> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n> > + * GNU General Public License for more details.\n> > + */\n> > +\n> > +#include \n> > +#include \n> > +#include \n> > +#include \n> > +#include \n> > +#include \n> > +#include \n> > +\n> > +#define UNIPHIER_EFUSE_WORD_SIZE 4\n> > +#define UNIPHIER_EFUSE_STRIDE 4\n> > +\n> > +static int uniphier_reg_read(void *context,\n> > + unsigned int offset, void *val, size_t\n> > +bytes) {\n> > + int words = bytes / UNIPHIER_EFUSE_WORD_SIZE;\n> > +\n> > + return regmap_bulk_read(context, offset, val, words); }\n> > +\n> > +static struct nvmem_config econfig = {\n> > + .name = \"uniphier-efuse\",\n> > + .owner = THIS_MODULE,\n> > + .read_only = true,\n> > + .reg_read = uniphier_reg_read,\n> > + .word_size = UNIPHIER_EFUSE_WORD_SIZE,\n> > + .stride = UNIPHIER_EFUSE_STRIDE, };\n> \n> \n> \n> \"struct nvmem_config\" exists for the purpose of containing driver-specific\n> parameters.\n> Do you still want to use\n> UNIPHIER_EFUSE_WORD_SIZE / UNIPHIER_EFUSE_STRIDE macros here?\n> \n> \n> \n> \n> static struct nvmem_config econfig = {\n> .name = \"uniphier-efuse\",\n> .owner = THIS_MODULE,\n> .read_only = true,\n> .reg_read = uniphier_reg_read,\n> .word_size = 4,\n> .stride = 4,\n> };\n> \n> looks nicer in my taste.\n> \n\nI will fix it.\n\n> \n> BTW, is there really no possibility\n> where the unphier_efuse_probe() is run concurrently?\n> \n> Many other drivers pass statically allocated memory to nvmem_register()\n> like this...\n> \nIn the case of the uniphier system, since there is only one efuse device,\nit will not run concurrently. \nI would like to fix it when I need it in the future.\n\n> \n> > +static int uniphier_efuse_probe(struct platform_device *pdev) {\n> > + struct device *dev = &pdev->dev;\n> > + struct nvmem_device *nvmem;\n> > + struct regmap *regmap;\n> > + struct resource res;\n> > + int ret;\n> > +\n> > + ret = of_address_to_resource(dev->of_node, 0, &res);\n> > + if (ret)\n> > + return ret;\n> > +\n> > + regmap = syscon_node_to_regmap(dev->of_node);\n> > + if (IS_ERR(regmap))\n> > + return PTR_ERR(regmap);\n> \n> \n> In my understanding,\n> syscon_node_to_regmap() is generally useful to get regmap of another node,\n> i.e. it is often used together with of_get_parent / of_parse_phandle etc.\n> \n> You can use devm_regmap_init_mmio()\n> to init regmap for itself.\n> \n> \n> BTW, what is your motivation of using regmap?\n>\n> \n> I think what you want to do is\n> the same as mtk-efuse.c, right?\n> (and qfprom.c is similar, the difference is just register width)\n\nSince redundancy can be omitted, implementation is easier, I think so.\nHowever, since I can't find the merit of using regmap,\nI will implement it in a method that does not use it.\n\n> \n> \n> > + econfig.size = resource_size(&res);\n> > + econfig.priv = regmap;\n> > + econfig.dev = dev;\n> > +\n> > + nvmem = nvmem_register(&econfig);\n> > + if (IS_ERR(nvmem))\n> > + return PTR_ERR(nvmem);\n> > +\n> > + platform_set_drvdata(pdev, nvmem);\n> > +\n> > + return 0;\n> > +}\n> > +\n> > +static int uniphier_efuse_remove(struct platform_device *pdev) {\n> > + struct nvmem_device *nvmem = platform_get_drvdata(pdev);\n> > +\n> > + return nvmem_unregister(nvmem); }\n> > +\n> > +static const struct of_device_id uniphier_efuse_of_match[] = {\n> > + { .compatible = \"socionext,uniphier-efuse\",},\n> > + {/* sentinel */},\n> > +};\n> > +MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);\n> > +\n> > +static struct platform_driver uniphier_efuse_driver = {\n> > + .probe = uniphier_efuse_probe,\n> > + .remove = uniphier_efuse_remove,\n> > + .driver = {\n> > + .name = \"uniphier-efuse\",\n> > + .of_match_table = uniphier_efuse_of_match,\n> > + },\n> > +};\n> > +module_platform_driver(uniphier_efuse_driver);\n> > +\n> > +MODULE_AUTHOR(\"Keiji Hayashibara \");\n> > +MODULE_DESCRIPTION(\"UniPhier eFuse driver\"); MODULE_LICENSE(\"GPL\n> > +v2\");\n> > --\n> > 2.7.4\n> >\n> \n> \n> \n> --\n> Best Regards\n> Masahiro Yamada\n\nBest Regards,\nKeiji Hayashibara\n\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnhMy0fTFz9t2r\n\tfor ;\n\tThu, 7 Sep 2017 10:36:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751163AbdIGAg2 (ORCPT\n\t);\n\tWed, 6 Sep 2017 20:36:28 -0400","from mx.socionext.com ([202.248.49.38]:6739 \"EHLO mx.socionext.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750800AbdIGAg1 (ORCPT );\n\tWed, 6 Sep 2017 20:36:27 -0400","from unknown (HELO iyokan-ex.css.socionext.com) ([172.31.9.54])\n\tby mx.socionext.com with ESMTP; 07 Sep 2017 09:36:26 +0900","from mail.mfilter.local (unknown [10.213.24.61])\n\tby iyokan-ex.css.socionext.com (Postfix) with ESMTP id 2B91F610C6;\n\tThu, 7 Sep 2017 09:36:26 +0900 (JST)","from 172.31.9.51 (172.31.9.51) by m-FILTER with ESMTP;\n\tThu, 7 Sep 2017 09:36:26 +0900","from yuzu.css.socionext.com (yuzu [172.31.8.45])\n\tby kinkan.css.socionext.com (Postfix) with ESMTP id 87F041A0E16;\n\tThu, 7 Sep 2017 09:36:25 +0900 (JST)","from DESKTOP0FARE34 (unknown [10.213.134.218])\n\tby yuzu.css.socionext.com (Postfix) with ESMTP id 49C99120453;\n\tThu, 7 Sep 2017 09:36:25 +0900 (JST)"],"From":"\"Keiji Hayashibara\" ","To":"\"'Masahiro Yamada'\" ","Cc":"\"Srinivas Kandagatla\" , \"Rob Herring\"\n\t, , \"linux-arm-kernel\"\n\t, \"Linux Kernel Mailing List\"\n\t, \"Masami Hiramatsu\"\n\t, \n\t\"Jassi Brar\" , =?utf-8?q?Hayashi=2C_Kunih?=\n\t=?utf-8?b?aWtvL+aelyDpgqblvaY=?= ,\n\t=?utf-8?b?T3dhZGEsIEtpeW9zaGkv5aSn?= =?utf-8?b?5ZKM55SwIOa4heW/lw==?=\n\t","References":"<1504221620-358-1-git-send-email-hayashibara.keiji@socionext.com>\n\t<1504221620-358-3-git-send-email-hayashibara.keiji@socionext.com>\n\t","In-Reply-To":"","Subject":"RE: [PATCH v1 2/3] nvmem: uniphier: add UniPhier eFuse driver","Date":"Thu, 7 Sep 2017 09:36:21 +0900","Message-ID":"<000001d32771$544d0dc0$fce72940$@socionext.com>","MIME-Version":"1.0","Content-Type":"text/plain;\n charset=\"utf-8\"","Content-Transfer-Encoding":"7bit","X-Mailer":"Microsoft Outlook 15.0","Thread-Index":"AQHTIq+4DHAsvjFxIE+6uGRrOXeKMqKkHqOAgARq8SA=","Content-Language":"ja","x-securitypolicycheck":"OK by SHieldMailChecker v2.5.2","x-shieldmailcheckerpolicyversion":"POLICY170302","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]