[{"id":1771721,"web_url":"http://patchwork.ozlabs.org/comment/1771721/","msgid":"","list_archive_url":null,"date":"2017-09-20T10:02:24","subject":"Re: [PATCH 0/5] nvmem: some cleanups and sparse warning fixes","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"Hi Srinivas,\n\n\n2017-09-11 22:00 GMT+09:00 Masahiro Yamada :\n>\n> Socionext is trying to add a new nvmem driver.\n>\n> Before adding a new one, I'd like to be sure about the preferred\n> coding style in this subsystem, and build-up cleaner code base.\n>\n> Please pick up what you like. Please feel free to throw away\n> what you do not like.\n>\n> 1/5, 2/5: convert kzalloc to stack because nvmem_config\n> is small one-time use data.\n> This is what we agreed in the discussion.\n>\n> 3/5, 4/5: fix sparse warning\n> For mtk-efuse, qfprom, the base address is the only private data\n> but, assigning (void __iomem *) to ->priv directly causes sparse\n> warnings.\n>\n> 5/5: clean-up of owner settings - if the owner field matches\n> nvmem->dev->driver->onwer, we need not set the onwer field\n> explicitly.\n\n\nDoes this series look OK?\n\nThanks.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"DcakNVnT\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"IxRq1T13\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxwLv5QsJz9s0Z\n\tfor ;\n\tWed, 20 Sep 2017 20:04:07 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dubrN-0005AS-7y; Wed, 20 Sep 2017 10:04:01 +0000","from conssluserg-02.nifty.com ([210.131.2.81])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dubrH-00055A-IU; Wed, 20 Sep 2017 10:03:57 +0000","from mail-yw0-f170.google.com (mail-yw0-f170.google.com\n\t[209.85.161.170]) (authenticated)\n\tby conssluserg-02.nifty.com with ESMTP id v8KA35Gk013319;\n\tWed, 20 Sep 2017 19:03:06 +0900","by mail-yw0-f170.google.com with SMTP id i6so1523930ywc.9;\n\tWed, 20 Sep 2017 03:03:06 -0700 (PDT)","by 10.37.170.198 with HTTP; Wed, 20 Sep 2017 03:02:24 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=0eD5uxat7M4P/CD43QFq4rPS5zKoAkkvtzhSxY3lbrE=;\n\tb=DcakNVnTG2b5Xb\n\tCZEqfV5Xk6GgDGtzabNB2g8O/t6xhT5PDTrP3b6i7vc8McZ8G2KQzExTzIrIsHsYr+qmMxz6bcIdg\n\t2HgivQsv7cMJkF+XhGpfWmP50lHy/8hNwzi7sC9jkYdvckJT+8S8vLhncYiwAVgQQWfCAsvx5XIPf\n\tKGfAWD/xuwT2kakNkOabSfH6BwIY6RkwlG93mL9sLQPW5MRlS8JZvwS/E15xZwLV1BRIwz8grHOoK\n\tskUw28S61GYYOEzWFtaHTxLk1TzaXKAOoP5ExsCm1lfhnlL1bf5SeTxXVzrjtb2jrate+I0zJJoWZ\n\tClDIK+5CvvDnbhFMMo5w==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1505901786;\n\tbh=FkqtduZRXelZd7exzU6bGc6Efm2AHrZpd9/N2MLmldc=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=IxRq1T139wp95xYxjTN0Ee3EPdB29wYqWO8vtWefRynB5jEHco2bULVKKtIdIWcVG\n\tWc1XVpJquoq/OXGo+AaQzv97/e70e4BWnL/QOO3ZXhiLsoIh8gnUAUFXvJyN5T0iqL\n\tEESr0UOpPwUtNZ14RrbKAb7WvCM0zjYw0ntolFTwo/4qs236w6wShKPtcw/nXOt5oZ\n\tRONRx+ijywc3BFXnhsr1UqK5WH1sfouqDhYfW0xq8/fQidAFaWuNUIeBRL7agwnJDC\n\tLHyfwdZAFodhtFgYwzQXB7oRZakM4Od23s0XGz4NV6Y4dIyGbJxVDcJw7lKCxpfKj0\n\twlmDfWWx3dgXQ=="],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com v8KA35Gk013319","X-Nifty-SrcIP":"[209.85.161.170]","X-Gm-Message-State":"AHPjjUiHJW7AM8i+ZCrmTank9cPA5gyJ/DxMNGj8Lx+U4GraFslbHK4c\n\thzw11qw7D2E92D3NUXjHXq48evxHlbh6HinG5sQ=","X-Google-Smtp-Source":"AOwi7QBWIDDxGsliG7Iow3+QLbRzpmjgTE1OEo7nH5uJBvR2lCKQW53Oeg9VH8PZAAOHsVVAqvvA7IBfAvnAn/eoUAk=","X-Received":"by 10.13.207.134 with SMTP id r128mr3199452ywd.273.1505901785066;\n\tWed, 20 Sep 2017 03:03:05 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>","References":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>","From":"Masahiro Yamada ","Date":"Wed, 20 Sep 2017 19:02:24 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 0/5] nvmem: some cleanups and sparse warning fixes","To":"Srinivas Kandagatla ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170920_030355_869645_8C7439B9 ","X-CRM114-Status":"GOOD ( 10.80 )","X-Spam-Score":"-0.7 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-0.7 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.161.170 listed in dnsbl.sorbs.net]\n\t0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Heiko Stuebner , Jassi Brar ,\n\tKevin Hilman ,\n\tJoachim Eastwood , \n\tKeiji Hayashibara ,\n\tLinux Kernel Mailing List ,\n\tMasahiro Yamada ,\n\tChen-Yu Tsai , \"moderated list:ARM/Mediatek SoC support\"\n\t, \n\tMasami Hiramatsu ,\n\tlinux-amlogic@lists.infradead.org, \n\tMatthias Brugger ,\n\t\"open list:ARM/Rockchip SoC...\" , \n\tMaxime Ripard ,\n\tCarlo Caione ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1772039,"web_url":"http://patchwork.ozlabs.org/comment/1772039/","msgid":"<1505924397.17049.1.camel@mtkswgap22>","list_archive_url":null,"date":"2017-09-20T16:19:57","subject":"Re: [PATCH 3/5] nvmem: mtk-efuse: fix different address space\n\twarnings of sparse","submitter":{"id":69660,"url":"http://patchwork.ozlabs.org/api/people/69660/","name":"Sean Wang","email":"sean.wang@mediatek.com"},"content":"On Mon, 2017-09-11 at 22:01 +0900, Masahiro Yamada wrote:\n> Fix the following sparse warnings:\n> \n> drivers/nvmem/mtk-efuse.c:24:30: warning: incorrect type in initializer (different address spaces)\n> drivers/nvmem/mtk-efuse.c:24:30: expected void [noderef] *base\n> drivers/nvmem/mtk-efuse.c:24:30: got void *context\n> drivers/nvmem/mtk-efuse.c:37:30: warning: incorrect type in initializer (different address spaces)\n> drivers/nvmem/mtk-efuse.c:37:30: expected void [noderef] *base\n> drivers/nvmem/mtk-efuse.c:37:30: got void *context\n> drivers/nvmem/mtk-efuse.c:69:23: warning: incorrect type in assignment (different address spaces)\n> drivers/nvmem/mtk-efuse.c:69:23: expected void *priv\n> drivers/nvmem/mtk-efuse.c:69:23: got void [noderef] *[assigned] base\n> \n> The type of nvmem_config->priv is (void *), so sparse complains\n> about assignment of the base address with (void __iomem *) type.\n> \n> Even if we cast it out, sparse still warns:\n> warning: cast removes address space of expression\n> \n> Of course, we can shut up the sparse by marking __force, but a more\n> correct way is to put the base address into driver private data.\n> \n> Signed-off-by: Masahiro Yamada \n\nAcked-by: Sean Wang \n\n> ---\n> \n> drivers/nvmem/mtk-efuse.c | 26 +++++++++++++++++---------\n> 1 file changed, 17 insertions(+), 9 deletions(-)\n> \n> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c\n> index fa7a0f6..c4058b5 100644\n> --- a/drivers/nvmem/mtk-efuse.c\n> +++ b/drivers/nvmem/mtk-efuse.c\n> @@ -18,15 +18,19 @@\n> #include \n> #include \n> \n> +struct mtk_efuse_priv {\n> +\tvoid __iomem *base;\n> +};\n> +\n> static int mtk_reg_read(void *context,\n> \t\t\tunsigned int reg, void *_val, size_t bytes)\n> {\n> -\tvoid __iomem *base = context;\n> +\tstruct mtk_efuse_priv *priv = context;\n> \tu32 *val = _val;\n> \tint i = 0, words = bytes / 4;\n> \n> \twhile (words--)\n> -\t\t*val++ = readl(base + reg + (i++ * 4));\n> +\t\t*val++ = readl(priv->base + reg + (i++ * 4));\n> \n> \treturn 0;\n> }\n> @@ -34,12 +38,12 @@ static int mtk_reg_read(void *context,\n> static int mtk_reg_write(void *context,\n> \t\t\t unsigned int reg, void *_val, size_t bytes)\n> {\n> -\tvoid __iomem *base = context;\n> +\tstruct mtk_efuse_priv *priv = context;\n> \tu32 *val = _val;\n> \tint i = 0, words = bytes / 4;\n> \n> \twhile (words--)\n> -\t\twritel(*val++, base + reg + (i++ * 4));\n> +\t\twritel(*val++, priv->base + reg + (i++ * 4));\n> \n> \treturn 0;\n> }\n> @@ -50,19 +54,23 @@ static int mtk_efuse_probe(struct platform_device *pdev)\n> \tstruct resource *res;\n> \tstruct nvmem_device *nvmem;\n> \tstruct nvmem_config econfig = {};\n> -\tvoid __iomem *base;\n> +\tstruct mtk_efuse_priv *priv;\n> +\n> +\tpriv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);\n> +\tif (!priv)\n> +\t\treturn -ENOMEM;\n> \n> \tres = platform_get_resource(pdev, IORESOURCE_MEM, 0);\n> -\tbase = devm_ioremap_resource(dev, res);\n> -\tif (IS_ERR(base))\n> -\t\treturn PTR_ERR(base);\n> +\tpriv->base = devm_ioremap_resource(dev, res);\n> +\tif (IS_ERR(priv->base))\n> +\t\treturn PTR_ERR(priv->base);\n> \n> \teconfig.stride = 4;\n> \teconfig.word_size = 4;\n> \teconfig.reg_read = mtk_reg_read;\n> \teconfig.reg_write = mtk_reg_write;\n> \teconfig.size = resource_size(res);\n> -\teconfig.priv = base;\n> +\teconfig.priv = priv;\n> \teconfig.dev = dev;\n> \teconfig.owner = THIS_MODULE;\n> \tnvmem = nvmem_register(&econfig);","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"Xw4VIuFi\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy4jL3Q3bz9sNr\n\tfor ;\n\tThu, 21 Sep 2017 02:20:38 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duhjk-0006Oy-PJ; Wed, 20 Sep 2017 16:20:32 +0000","from [210.61.82.183] (helo=mailgw01.mediatek.com)\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duhjg-000592-44; Wed, 20 Sep 2017 16:20:30 +0000","from mtkcas06.mediatek.inc [(172.21.101.30)] by\n\tmailgw01.mediatek.com (envelope-from )\n\t(mhqrelay.mediatek.com ESMTP with TLS)\n\twith ESMTP id 720742757; Thu, 21 Sep 2017 00:19:58 +0800","from mtkcas09.mediatek.inc (172.21.101.178) by\n\tmtkexhb01.mediatek.inc (172.21.101.102) with Microsoft SMTP Server\n\t(TLS) id 15.0.1210.3; Thu, 21 Sep 2017 00:20:04 +0800","from [172.21.77.33] (172.21.77.33) by mtkcas09.mediatek.inc\n\t(172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via\n\tFrontend Transport; Thu, 21 Sep 2017 00:20:14 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tDate:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=fjqeDKPbALgRQh64ZvAFWQ6IDpE8IWttI8WVI3f6aWo=;\n\tb=Xw4VIuFiacmiZm\n\tXqjyyt/n7fkKLy6T7eHCKYO57HqdFs1M5EQWxgLuRPGFPNjARX6xnEutZai9baguVBS+wEd9h7voh\n\td7hctHSPTkq9yOCq6MWzJXZm0Kz7OpFp97E4kV4+eCAlvGFi1vJ9Th/Lpmms9TRwjnIFz4jDLr35J\n\tVOq8niRvoYhOvnFNbGSVRuDylpyjD/1HAw4yT97xkW8jaogcuXKbRfAKuQxLHneNNHcrMJu5CcJJ2\n\teI/LTTYJVzznWwCLkJIThWmgbTGcj+AULx+DE4rVwLKq5TxvY/mz+u2u0qy1VqB+LP3Z29qv4JUdv\n\tsiWF3TIOBu4Qzk1+4viw==;","X-UUID":"dd9bfdfedecf42ca8c996dcbb1cddfa3-20170921","Message-ID":"<1505924397.17049.1.camel@mtkswgap22>","Subject":"Re: [PATCH 3/5] nvmem: mtk-efuse: fix different address space\n\twarnings of sparse","From":"Sean Wang ","To":"Masahiro Yamada ","Date":"Thu, 21 Sep 2017 00:19:57 +0800","In-Reply-To":"<1505134864-11975-4-git-send-email-yamada.masahiro@socionext.com>","References":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1505134864-11975-4-git-send-email-yamada.masahiro@socionext.com>","X-Mailer":"Evolution 3.2.3-0ubuntu6 ","MIME-Version":"1.0","X-MTK":"N","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170920_092028_467630_6E97615E ","X-CRM114-Status":"GOOD ( 16.23 )","X-Spam-Score":"-1.1 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.1 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t0.8 RDNS_NONE Delivered to internal network by a host with no rDNS\n\t0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay\n\tlines","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Keiji Hayashibara ,\n\tlinux-kernel@vger.kernel.org, Jassi Brar ,\n\tlinux-mediatek@lists.infradead.org,\n\tMasami Hiramatsu , \n\tMatthias Brugger ,\n\tSrinivas Kandagatla ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1772046,"web_url":"http://patchwork.ozlabs.org/comment/1772046/","msgid":"<1505925159.17049.12.camel@mtkswgap22>","list_archive_url":null,"date":"2017-09-20T16:32:39","subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config\n\tinstead of malloc'ing it","submitter":{"id":69660,"url":"http://patchwork.ozlabs.org/api/people/69660/","name":"Sean Wang","email":"sean.wang@mediatek.com"},"content":"Hi, Masahiro\n\nFor maintainability, I felt it's better if we use the same way to\nregister nvmem as that most drivers does under nvmem usually using\nstatic structure. Otherwise, they should also be changed to use the\none-time data in stack to avoid extra bytes to keep them.\n\n\tSean\n\n\nOn Mon, 2017-09-11 at 22:01 +0900, Masahiro Yamada wrote:\n> nvmem_register() copies all the members of nvmem_config to\n> nvmem_device. So, nvmem_config is one-time use data during\n> probing. There is no point to keep it until the driver detach.\n> Using stack should be no problem because nvmem_config is pretty\n> small.\n> \n> Signed-off-by: Masahiro Yamada \n> ---\n> \n> drivers/nvmem/mtk-efuse.c | 24 ++++++++++--------------\n> 1 file changed, 10 insertions(+), 14 deletions(-)\n> \n> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c\n> index 32fd572..fa7a0f6 100644\n> --- a/drivers/nvmem/mtk-efuse.c\n> +++ b/drivers/nvmem/mtk-efuse.c\n> @@ -49,7 +49,7 @@ static int mtk_efuse_probe(struct platform_device *pdev)\n> \tstruct device *dev = &pdev->dev;\n> \tstruct resource *res;\n> \tstruct nvmem_device *nvmem;\n> -\tstruct nvmem_config *econfig;\n> +\tstruct nvmem_config econfig = {};\n> \tvoid __iomem *base;\n> \n> \tres = platform_get_resource(pdev, IORESOURCE_MEM, 0);\n> @@ -57,19 +57,15 @@ static int mtk_efuse_probe(struct platform_device *pdev)\n> \tif (IS_ERR(base))\n> \t\treturn PTR_ERR(base);\n> \n> -\teconfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);\n> -\tif (!econfig)\n> -\t\treturn -ENOMEM;\n> -\n> -\teconfig->stride = 4;\n> -\teconfig->word_size = 4;\n> -\teconfig->reg_read = mtk_reg_read;\n> -\teconfig->reg_write = mtk_reg_write;\n> -\teconfig->size = resource_size(res);\n> -\teconfig->priv = base;\n> -\teconfig->dev = dev;\n> -\teconfig->owner = THIS_MODULE;\n> -\tnvmem = nvmem_register(econfig);\n> +\teconfig.stride = 4;\n> +\teconfig.word_size = 4;\n> +\teconfig.reg_read = mtk_reg_read;\n> +\teconfig.reg_write = mtk_reg_write;\n> +\teconfig.size = resource_size(res);\n> +\teconfig.priv = base;\n> +\teconfig.dev = dev;\n> +\teconfig.owner = THIS_MODULE;\n> +\tnvmem = nvmem_register(&econfig);\n> \tif (IS_ERR(nvmem))\n> \t\treturn PTR_ERR(nvmem);\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"ORG0Ymqs\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xy4zx36Zlz9t2V\n\tfor ;\n\tThu, 21 Sep 2017 02:33:17 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duhw0-0002pC-2F; Wed, 20 Sep 2017 16:33:12 +0000","from [210.61.82.183] (helo=mailgw01.mediatek.com)\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duhvv-0002lQ-23; Wed, 20 Sep 2017 16:33:09 +0000","from mtkcas08.mediatek.inc [(172.21.101.126)] by\n\tmailgw01.mediatek.com (envelope-from )\n\t(mhqrelay.mediatek.com ESMTP with TLS)\n\twith ESMTP id 1538915728; Thu, 21 Sep 2017 00:32:41 +0800","from mtkcas08.mediatek.inc (172.21.101.126) by\n\tmtkexhb02.mediatek.inc (172.21.101.103) with Microsoft SMTP Server\n\t(TLS) id 15.0.1210.3; Thu, 21 Sep 2017 00:32:49 +0800","from mtkcas09.mediatek.inc (172.21.101.178) by\n\tmtkcas08.mediatek.inc\n\t(172.21.101.126) with Microsoft SMTP Server (TLS) id 15.0.1210.3;\n\tThu, 21 Sep 2017 00:32:06 +0800","from [172.21.77.33] (172.21.77.33) by mtkcas09.mediatek.inc\n\t(172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via\n\tFrontend Transport; Thu, 21 Sep 2017 00:32:57 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tDate:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=9pCNBkPu+RpkNSgt1LdJVIwM/1EVsuE9bcHEBryrHHI=;\n\tb=ORG0YmqsXEmCi5\n\tQb+0uDwMV0ybsPsDM/ef50Pz5f9gLCJB7QFb+NRWJAnC9+JxsEQtd98lwR+5H6H+tuyiSfOa41ERi\n\tdhPfJCTydjxTHkJTX3nNtladxaqY3nyIKqz9y0CSsXyZVz6Ja/5TqJvVc/Rm0LwIZ1CJ/fluqCu8F\n\tMmXrd3IkLxEizlJ8XB+sDknUww19iBkaWA07UXD92PlyxTfwh4ygZ09AgvFvbnk/7I/xClOPRw2lb\n\tezSfUdOHZzgCQx2NSrDB2EQucQ0UPuC5OtOZAdEkiRZ/N5v4xw0Vg6hNpj3rKIXwsLh1CSDYsp9xq\n\tLk63G1OH1fwSOSogVqVg==;","X-UUID":"d0100e32e4d94fb29752f22acdb8dc66-20170921","Message-ID":"<1505925159.17049.12.camel@mtkswgap22>","Subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config\n\tinstead of malloc'ing it","From":"Sean Wang ","To":"Masahiro Yamada ","Date":"Thu, 21 Sep 2017 00:32:39 +0800","In-Reply-To":"<1505134864-11975-3-git-send-email-yamada.masahiro@socionext.com>","References":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1505134864-11975-3-git-send-email-yamada.masahiro@socionext.com>","X-Mailer":"Evolution 3.2.3-0ubuntu6 ","MIME-Version":"1.0","X-MTK":"N","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170920_093307_322289_843EA22A ","X-CRM114-Status":"GOOD ( 14.07 )","X-Spam-Score":"-1.1 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.1 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t0.8 RDNS_NONE Delivered to internal network by a host with no rDNS\n\t0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay\n\tlines","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Keiji Hayashibara ,\n\tlinux-kernel@vger.kernel.org, Jassi Brar ,\n\tlinux-mediatek@lists.infradead.org,\n\tMasami Hiramatsu , \n\tMatthias Brugger ,\n\tSrinivas Kandagatla ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1772368,"web_url":"http://patchwork.ozlabs.org/comment/1772368/","msgid":"","list_archive_url":null,"date":"2017-09-21T02:09:35","subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead\n\tof malloc'ing it","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"Hi Sean,\n\n\n2017-09-21 1:32 GMT+09:00 Sean Wang :\n> Hi, Masahiro\n>\n> For maintainability, I felt it's better if we use the same way to\n> register nvmem as that most drivers does under nvmem usually using\n> static structure. Otherwise, they should also be changed to use the\n> one-time data in stack to avoid extra bytes to keep them.\n>\n> Sean\n\n\nSrinivas and I discussed the best practice for allocating nvmem_config.\nhttps://lkml.org/lkml/2017/9/11/4\n\n>From the discussion, static structure is possible only when\nthe system has one instance of the device.\n\nIf you know this is the case for mediatek,\nyes, you can turn it into static,\nbut it is not always possible.\nFor example, Socionext SoCs have\ntwo banks of efuse devices.\n\nSo, if we want to align the coding style for consistency,\nnvmem in stack is safe and efficient, I think.\n\n\nMoving one-time data into stack slightly\nreduces the kernel image size.","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"TUShWo50\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"OSisUgbR\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xyKpz5MCcz9s78\n\tfor ;\n\tThu, 21 Sep 2017 12:11:23 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duqxT-0005HU-QT; Thu, 21 Sep 2017 02:11:19 +0000","from conssluserg-04.nifty.com ([210.131.2.83])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duqxP-0005CK-3M; Thu, 21 Sep 2017 02:11:17 +0000","from mail-yw0-f180.google.com (mail-yw0-f180.google.com\n\t[209.85.161.180]) (authenticated)\n\tby conssluserg-04.nifty.com with ESMTP id v8L2AGSP001394;\n\tThu, 21 Sep 2017 11:10:17 +0900","by mail-yw0-f180.google.com with SMTP id u205so3158901ywa.5;\n\tWed, 20 Sep 2017 19:10:16 -0700 (PDT)","by 10.37.170.198 with HTTP; Wed, 20 Sep 2017 19:09:35 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=fwDk1THoc+/TvR2YkmytBMHxXBlVvTph5DXZxBqtU6E=;\n\tb=TUShWo50ad0zjS\n\tqb+tVhQQf4dB5dg/NKEXVituGZMawDfjVQ5L3PhyMpQgW/E1xnwgVu9TWDt/cA1V4BJ8V69/+kxI6\n\tOFZMMLY80wSZUHkN2CHVjpsFBGuSPgZv2DIPLAvvRULgMmoHGwFfj9p+r1V0Artd6jN3KzgMR2nqc\n\t23GP8aRY7FBCCpZ/GJJynci5xfOkhn+nnIKQzMwRydkp8y4cb97N96m54IjI+MelP8vor8LmwVh6I\n\tzq73oZf+Vi7rbUXJZY2FYaSzHoLO5ovJg2PjmcK1XQh9L4zExx68XMlwUrUX+LBVVG32ttAOjeQs3\n\tLHi/ROTH1pYPzDR9ruyw==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1505959817;\n\tbh=301U0dBOSvhD470E5pb95Dh5oe84GgKE7JYqrkzO7lA=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=OSisUgbRmVUfJIP+Q0IoZAoZzLsDvYzkfwhsaFs0SsIAlyQzUlV2ld86LT+a8c2uD\n\ttSMycIY4CLuztcf85QForAk0CUIkAbzgefPbmDXWwQK0Yz7c1GqsdV+rovPEvZ6hQp\n\tXnlfA6Q5dPMfDyCBV84xbAM6PEFwsDDstFI4+pAinGrNzyiKsMaKpixr0rh87BxaqK\n\tMHRainRE+s6gSa2nrKRCD+g++3liHiAT5WI1Ousa9O030SwOzoK4RsDzY2XyVJrRhT\n\t88K3WpdeEGk8yWhilJrc8/fyo8K1s0Keg5v7okl2b3kQ+yy2xT3BO9ztp/Hm3otbpX\n\tzQLYOy+7NlPEg=="],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com v8L2AGSP001394","X-Nifty-SrcIP":"[209.85.161.180]","X-Gm-Message-State":"AHPjjUi3U3hYV5IeiqU2O3kzyH4M1ukjqHLCndGiIzyf18VaceCC0mEu\n\tEMK3m6ZmGs6yimAhSlfpTKzzxEHAUChU4AuI3ys=","X-Google-Smtp-Source":"AOwi7QA+AYJsdq50SNYcPdj7zQR2ORYh7SrjARELrkUK/kFTJ3L31KA8zd7OidDT5Gu9iHkwT7GtLT23OUBOh0Q0yLQ=","X-Received":"by 10.13.222.131 with SMTP id h125mr525376ywe.16.1505959815857; \n\tWed, 20 Sep 2017 19:10:15 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<1505925159.17049.12.camel@mtkswgap22>","References":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1505134864-11975-3-git-send-email-yamada.masahiro@socionext.com>\n\t<1505925159.17049.12.camel@mtkswgap22>","From":"Masahiro Yamada ","Date":"Thu, 21 Sep 2017 11:09:35 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead\n\tof malloc'ing it","To":"Sean Wang ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170920_191115_437855_DBBD4247 ","X-CRM114-Status":"GOOD ( 10.41 )","X-Spam-Score":"-0.7 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-0.7 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source\n\t[209.85.161.180 listed in dnsbl.sorbs.net]\n\t0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Keiji Hayashibara ,\n\tLinux Kernel Mailing List ,\n\tJassi Brar ,\n\t\"moderated list:ARM/Mediatek SoC support\"\n\t, \n\tMasami Hiramatsu ,\n\tMatthias Brugger ,\n\tSrinivas Kandagatla ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773248,"web_url":"http://patchwork.ozlabs.org/comment/1773248/","msgid":"<1506052787.21515.10.camel@mtkswgap22>","list_archive_url":null,"date":"2017-09-22T03:59:47","subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config\n\tinstead of malloc'ing it","submitter":{"id":69660,"url":"http://patchwork.ozlabs.org/api/people/69660/","name":"Sean Wang","email":"sean.wang@mediatek.com"},"content":"Hi, Masahiro\n\nOn Thu, 2017-09-21 at 11:09 +0900, Masahiro Yamada wrote:\n> Hi Sean,\n> \n> \n> 2017-09-21 1:32 GMT+09:00 Sean Wang :\n> > Hi, Masahiro\n> >\n> > For maintainability, I felt it's better if we use the same way to\n> > register nvmem as that most drivers does under nvmem usually using\n> > static structure. Otherwise, they should also be changed to use the\n> > one-time data in stack to avoid extra bytes to keep them.\n> >\n> > Sean\n> \n> \n> Srinivas and I discussed the best practice for allocating nvmem_config.\n> https://lkml.org/lkml/2017/9/11/4\n> \n> From the discussion, static structure is possible only when\n> the system has one instance of the device.\n> \n\nthank you for your detailed explanation\n\n> If you know this is the case for mediatek,\n> yes, you can turn it into static,\n> but it is not always possible.\n> For example, Socionext SoCs have\n> two banks of efuse devices.\n> \n\nthere should be only one instance of nvmem for mediatek soc, currently\n\n\n> So, if we want to align the coding style for consistency,\n> nvmem in stack is safe and efficient, I think.\n> \n> \n> Moving one-time data into stack slightly\n> reduces the kernel image size.\n> \n> \n\nagreed on those statements, indeed bigger struct uart_8250_port is still\nused on stack for configuring in a lot 8250 driver, so \n\nAcked-by: Sean Wang ","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"h2zE57nH\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz0BK25v6z9t16\n\tfor ;\n\tFri, 22 Sep 2017 14:00:25 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvF8V-00053J-2W; Fri, 22 Sep 2017 04:00:19 +0000","from [210.61.82.183] (helo=mailgw01.mediatek.com)\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvF8Q-0003ky-7G; Fri, 22 Sep 2017 04:00:16 +0000","from mtkexhb02.mediatek.inc [(172.21.101.103)] by\n\tmailgw01.mediatek.com (envelope-from )\n\t(mhqrelay.mediatek.com ESMTP with TLS)\n\twith ESMTP id 859694217; Fri, 22 Sep 2017 11:59:46 +0800","from mtkcas07.mediatek.inc (172.21.101.84) by\n\tmtkmbs01n2.mediatek.inc (172.21.101.79) with Microsoft SMTP Server\n\t(TLS) id 15.0.1210.3; Fri, 22 Sep 2017 11:59:34 +0800","from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc\n\t(172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via\n\tFrontend Transport; Fri, 22 Sep 2017 11:59:05 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tDate:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=YwMZ7B6EjAHX2Lh4pCOsuICR8vxrUPgvh+dukuiM4d8=;\n\tb=h2zE57nHsLOmd1\n\tXQw90CKGhXL/8Mt7tDRR967tbILLYAmbsT26G/s/b1/C8A9g5XJJdxCqfOrxhvnXzlGcuY3pd0x+V\n\tJEKb9KYdYYqC4wJWBrk6C1eH8KxWY4svq6lmv2h7Yow5xKSuQD4sQpxyrRdI2kXjgc5p7MKRDXHYd\n\tJkxg+gptnWRj1EvkY9qOGzoLG1UE80VbbY0hAzCc/PBWf02wpOt0pTIXjRFq68MNSliNbQvmdWvp3\n\tHrnSbYSA7PY149M1KmJt8KJQoKpNDLH4XQZW2Lj9VdVIJKWTpCnqEdnywgjnYczu5rudhn9Q4dv2k\n\tr08EYv8Fo6qQ4h+HQ1aQ==;","X-UUID":"af39409fb4874d15a0919ba6a17c8ccb-20170922","Message-ID":"<1506052787.21515.10.camel@mtkswgap22>","Subject":"Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config\n\tinstead of malloc'ing it","From":"Sean Wang ","To":"Masahiro Yamada ","Date":"Fri, 22 Sep 2017 11:59:47 +0800","In-Reply-To":"","References":"<1505134864-11975-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1505134864-11975-3-git-send-email-yamada.masahiro@socionext.com>\n\t<1505925159.17049.12.camel@mtkswgap22>\n\t","X-Mailer":"Evolution 3.2.3-0ubuntu6 ","MIME-Version":"1.0","X-MTK":"N","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170921_210014_410265_924373EC ","X-CRM114-Status":"GOOD ( 16.27 )","X-Spam-Score":"-1.1 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.1 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t0.8 RDNS_NONE Delivered to internal network by a host with no rDNS\n\t0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay\n\tlines","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Keiji Hayashibara ,\n\tLinux Kernel Mailing List ,\n\tJassi Brar ,\n\t\"moderated list:ARM/Mediatek SoC support\"\n\t, \n\tMasami Hiramatsu ,\n\tMatthias Brugger ,\n\tSrinivas Kandagatla ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]