[{"id":1764421,"web_url":"http://patchwork.ozlabs.org/comment/1764421/","msgid":"","list_archive_url":null,"date":"2017-09-06T22:50:12","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":70551,"url":"http://patchwork.ozlabs.org/api/people/70551/","name":"Cyrille Pitchen","email":"cyrille.pitchen@wedev4u.fr"},"content":"Le 06/09/2017 à 23:45, Cyrille Pitchen a écrit :\n> spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> When the m25p80 driver is used (pretty common case), nor->read() is then\n> implemented by the m25p80_read() function, which is likely to initialize a\n> 'struct spi_transfer' from its buf argument before appending this\n> structure inside the 'struct spi_message' argument of spi_sync().\n> \n> Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> memory as buf argument, hence not in a dma-safe area.\n> Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> given a kmalloc'ed buffer argument, hence dma-safe.\n> \n> So this patch fixes this issue by introducing a\n> spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> buffer.\n> \n> Reported-by: Geert Uytterhoeven \n> Signed-off-by: Cyrille Pitchen \n> ---\n> \n> Compiled but not tested yet!\n\ntested on a sama5d2 xplained board with:\n- an Adesto at25df321a on spi0 (using the m25p80.c driver)\n- a Macronix mx25l25673g on qspi0 (using the atmel-quadspi.c driver)\n\napplied on the spi-nor/next branch of l2-mtd\n\nshould be quickly sent as a fix to the MTD pull-request for 4.14\n\nSorry for that!\n\n> \n> drivers/mtd/spi-nor/spi-nor.c | 36 +++++++++++++++++++++++++++++++++---\n> 1 file changed, 33 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c\n> index cf1d4a15e10a..05254dd6a4a0 100644\n> --- a/drivers/mtd/spi-nor/spi-nor.c\n> +++ b/drivers/mtd/spi-nor/spi-nor.c\n> @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> * @nor:\tpointer to a 'struct spi_nor'\n> * @addr:\toffset in the SFDP area to start reading data from\n> * @len:\tnumber of bytes to read\n> - * @buf:\tbuffer where the SFDP data are copied into\n> + * @buf:\tbuffer where the SFDP data are copied into (dma-safe memory)\n> *\n> * Whatever the actual numbers of bytes for address and dummy cycles are\n> * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> \treturn ret;\n> }\n> \n> +/**\n> + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> + * @nor:\tpointer to a 'struct spi_nor'\n> + * @addr:\toffset in the SFDP area to start reading data from\n> + * @len:\tnumber of bytes to read\n> + * @buf:\tbuffer where the SFDP data are copied into\n> + *\n> + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> + * guaranteed to be dma-safe.\n> + *\n> + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> + * otherwise.\n> + */\n> +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> +\t\t\t\t\tsize_t len, void *buf)\n> +{\n> +\tvoid *dma_safe_buf;\n> +\tint ret;\n> +\n> +\tdma_safe_buf = kmalloc(len, GFP_KERNEL);\n> +\tif (!dma_safe_buf)\n> +\t\treturn -ENOMEM;\n> +\n> +\tret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> +\tmemcpy(buf, dma_safe_buf, len);\n> +\tkfree(dma_safe_buf);\n> +\n> +\treturn ret;\n> +}\n> +\n> struct sfdp_parameter_header {\n> \tu8\t\tid_lsb;\n> \tu8\t\tminor;\n> @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> \t\t bfpt_header->length * sizeof(u32));\n> \taddr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> \tmemset(&bfpt, 0, sizeof(bfpt));\n> -\terr = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> \tif (err < 0)\n> \t\treturn err;\n> \n> @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> \tint i, err;\n> \n> \t/* Get the SFDP header. */\n> -\terr = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> \tif (err < 0)\n> \t\treturn err;\n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"eaU8mdX3\"; \n\tdkim-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 3xnf2Z2MRTz9t2v\n\tfor ;\n\tThu, 7 Sep 2017 08:51:18 +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 1dpjA0-0003av-Ll; Wed, 06 Sep 2017 22:51:04 +0000","from smtp3-g21.free.fr ([212.27.42.3])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpj9a-0003W6-OP\n\tfor linux-mtd@lists.infradead.org; Wed, 06 Sep 2017 22:50:41 +0000","from mountainer.wedev4u.int (unknown [82.232.94.13])\n\tby smtp3-g21.free.fr (Postfix) with ESMTP id 72AD513F84C;\n\tThu, 7 Sep 2017 00:50:13 +0200 (CEST)"],"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:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=lthoYS05VKf4mId4cwxXdmQcQII7SLcDdxfz4a9B4ko=;\n\tb=eaU8mdX3G/628h\n\tRbTaBT7IDIq9pchBhPjq+ZuYvgTd5G0++9LqyzuSuXf6k71RoysOisdhKve8JGfoXeGNPYdFqSuz7\n\tzgN4Oqz3qkmZKUia2cc1G+E1L+j11a/P5wsPkGe7s4AEhswUQCaJ4C4Uu6KLQZPCVMEJ+h8/CefN9\n\tomYUyJAgmrl1IyM4RhdvIBsw6pM3iKV5LTcfLiEI+H++eL/a8BqoFNIaChz4jxyFlHJUEEHVS8FFm\n\tUrqrbUASKWnDH4mLTiF4craRJje5x6mxOeXa2HCgXpMLaSRNOkoVRyxcy86MvmPvdwHeR0IdBBpYR\n\thn0X4pzp0Tu4RjUNL8YA==;","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","To":"marek.vasut@gmail.com, linux-mtd@lists.infradead.org,\n\tgeert@linux-m68k.org","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","From":"Cyrille Pitchen ","Message-ID":"","Date":"Thu, 7 Sep 2017 00:50:12 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170906_155039_113991_1F0C9329 ","X-CRM114-Status":"GOOD ( 21.72 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/,\n\tlow trust [212.27.42.3 listed in list.dnswl.org]\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]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"boris.brezillon@free-electrons.com, richard@nod.at,\n\tNicolas Ferre ,\n\tlinux-kernel@vger.kernel.org, \n\tcomputersforpeace@gmail.com, dwmw2@infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1764544,"web_url":"http://patchwork.ozlabs.org/comment/1764544/","msgid":"<20170907090702.257d30a2@bbrezillon>","list_archive_url":null,"date":"2017-09-07T07:07:02","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":63120,"url":"http://patchwork.ozlabs.org/api/people/63120/","name":"Boris Brezillon","email":"boris.brezillon@free-electrons.com"},"content":"On Wed, 6 Sep 2017 23:45:02 +0200\nCyrille Pitchen wrote:\n\n> spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> When the m25p80 driver is used (pretty common case), nor->read() is then\n> implemented by the m25p80_read() function, which is likely to initialize a\n> 'struct spi_transfer' from its buf argument before appending this\n> structure inside the 'struct spi_message' argument of spi_sync().\n> \n> Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> memory as buf argument, hence not in a dma-safe area.\n> Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> given a kmalloc'ed buffer argument, hence dma-safe.\n> \n> So this patch fixes this issue by introducing a\n> spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> buffer.\n> \n> Reported-by: Geert Uytterhoeven \n\nMissing\n\nFixes: f384b352cbf0310f (\"mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables\")\n\n> Signed-off-by: Cyrille Pitchen \n> ---\n> \n> Compiled but not tested yet!\n> \n> drivers/mtd/spi-nor/spi-nor.c | 36 +++++++++++++++++++++++++++++++++---\n> 1 file changed, 33 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c\n> index cf1d4a15e10a..05254dd6a4a0 100644\n> --- a/drivers/mtd/spi-nor/spi-nor.c\n> +++ b/drivers/mtd/spi-nor/spi-nor.c\n> @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> * @nor:\tpointer to a 'struct spi_nor'\n> * @addr:\toffset in the SFDP area to start reading data from\n> * @len:\tnumber of bytes to read\n> - * @buf:\tbuffer where the SFDP data are copied into\n> + * @buf:\tbuffer where the SFDP data are copied into (dma-safe memory)\n> *\n> * Whatever the actual numbers of bytes for address and dummy cycles are\n> * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> \treturn ret;\n> }\n> \n> +/**\n> + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> + * @nor:\tpointer to a 'struct spi_nor'\n> + * @addr:\toffset in the SFDP area to start reading data from\n> + * @len:\tnumber of bytes to read\n> + * @buf:\tbuffer where the SFDP data are copied into\n> + *\n> + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> + * guaranteed to be dma-safe.\n> + *\n> + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> + * otherwise.\n> + */\n> +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> +\t\t\t\t\tsize_t len, void *buf)\n> +{\n> +\tvoid *dma_safe_buf;\n> +\tint ret;\n> +\n> +\tdma_safe_buf = kmalloc(len, GFP_KERNEL);\n> +\tif (!dma_safe_buf)\n> +\t\treturn -ENOMEM;\n> +\n> +\tret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> +\tmemcpy(buf, dma_safe_buf, len);\n> +\tkfree(dma_safe_buf);\n> +\n> +\treturn ret;\n> +}\n\nHm, do we really need to add this function? I would just kmalloc the bfpt\nand header objects in spi_nor_parse_bfpt(), which would avoid the extra\nheap-to-stack copy and also simplify this patch.\n\nI understand that you want to generically address the problem, but AFAICT\nthis patch is not doing that since the user has to explicitly call\nspi_nor_read_sfdp_dma_unsafe(), and I'm not even sure\nspi_nor_read_sfdp_dma_unsafe() can/will be re-used in the generic solution\nyou envision.\n\nLet's try to keep the fix as simple as possible and think about a better\napproach afterwards.\n\n> +\n> struct sfdp_parameter_header {\n> \tu8\t\tid_lsb;\n> \tu8\t\tminor;\n> @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> \t\t bfpt_header->length * sizeof(u32));\n> \taddr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> \tmemset(&bfpt, 0, sizeof(bfpt));\n> -\terr = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> \tif (err < 0)\n> \t\treturn err;\n> \n> @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> \tint i, err;\n> \n> \t/* Get the SFDP header. */\n> -\terr = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> \tif (err < 0)\n> \t\treturn err;\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"tls4pDne\"; \n\tdkim-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 3xns3p4lNXz9sCZ\n\tfor ;\n\tThu, 7 Sep 2017 17:08:06 +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 1dpqup-0006xR-UZ; Thu, 07 Sep 2017 07:07:55 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpquO-0006tQ-Rt\n\tfor linux-mtd@lists.infradead.org; Thu, 07 Sep 2017 07:07:32 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid C8E572097A; Thu, 7 Sep 2017 09:07:02 +0200 (CEST)","from bbrezillon (unknown [217.114.201.150])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 8A94820891;\n\tThu, 7 Sep 2017 09:07:02 +0200 (CEST)"],"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\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=xBlRYC2ysBb2C4bxZyO7QCHS783iMfj4e/zCt2uq04E=;\n\tb=tls4pDne0eqEcR\n\tH2FjTjqwEfkvCVjsANmlrVMq7RO6ocnw5Y78zflXiS9i/3b9LHkMI9unm0lb4YUrzmokuyvgGDtC3\n\tg68vqFj+/b83wnqTqkNaJE1viPtCPbv/sRP+GbRK2+roOM2OyFjmDRg7PDJBwQ4GrqQ0Fo+j7Bxph\n\tGJ13epxFJXC2p8UL9STafM7mI0GfcM2fGnUJI0i1nPdW4VmFIFSVMZs2+JH+p1i2sNzxA16XOZnJ5\n\t5AXwJMQNVqrynAJ6H7/8yjTsoEXU4MqHrr0OnuvoVwNaVJAit7rkK39nJ2a3tslxu2SNzqDc6vNfK\n\thY4334OPwpfuorDmE1lQ==;","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Thu, 7 Sep 2017 09:07:02 +0200","From":"Boris Brezillon ","To":"Cyrille Pitchen ","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","Message-ID":"<20170907090702.257d30a2@bbrezillon>","In-Reply-To":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_000729_208406_31F2E32B ","X-CRM114-Status":"GOOD ( 24.68 )","X-Spam-Score":"-0.2 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-0.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist\n\t[URIs: wedev4u.fr]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"richard@nod.at, linux-kernel@vger.kernel.org, marek.vasut@gmail.com,\n\tlinux-mtd@lists.infradead.org, geert@linux-m68k.org,\n\tcomputersforpeace@gmail.com, dwmw2@infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1764549,"web_url":"http://patchwork.ozlabs.org/comment/1764549/","msgid":"<20170907091251.5ff0333f@bbrezillon>","list_archive_url":null,"date":"2017-09-07T07:12:51","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":63120,"url":"http://patchwork.ozlabs.org/api/people/63120/","name":"Boris Brezillon","email":"boris.brezillon@free-electrons.com"},"content":"On Thu, 7 Sep 2017 00:50:12 +0200\nCyrille Pitchen wrote:\n\n> Le 06/09/2017 à 23:45, Cyrille Pitchen a écrit :\n> > spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> > When the m25p80 driver is used (pretty common case), nor->read() is then\n> > implemented by the m25p80_read() function, which is likely to initialize a\n> > 'struct spi_transfer' from its buf argument before appending this\n> > structure inside the 'struct spi_message' argument of spi_sync().\n> > \n> > Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> > 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> > three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> > memory as buf argument, hence not in a dma-safe area.\n> > Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> > given a kmalloc'ed buffer argument, hence dma-safe.\n> > \n> > So this patch fixes this issue by introducing a\n> > spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> > spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> > buffer.\n> > \n> > Reported-by: Geert Uytterhoeven \n> > Signed-off-by: Cyrille Pitchen \n> > ---\n> > \n> > Compiled but not tested yet! \n> \n> tested on a sama5d2 xplained board with:\n> - an Adesto at25df321a on spi0 (using the m25p80.c driver)\n> - a Macronix mx25l25673g on qspi0 (using the atmel-quadspi.c driver)\n\nCool, that was fast.\n\n> \n> applied on the spi-nor/next branch of l2-mtd\n\nMaybe a bit too fast. You should leave at least one day to\nreviewers/testers before applying the patch.\n\nBTW, I was planning on taking the patch directly.\n\n> \n> should be quickly sent as a fix to the MTD pull-request for 4.14\n> \n> Sorry for that!\n> \n> > \n> > drivers/mtd/spi-nor/spi-nor.c | 36 +++++++++++++++++++++++++++++++++---\n> > 1 file changed, 33 insertions(+), 3 deletions(-)\n> > \n> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c\n> > index cf1d4a15e10a..05254dd6a4a0 100644\n> > --- a/drivers/mtd/spi-nor/spi-nor.c\n> > +++ b/drivers/mtd/spi-nor/spi-nor.c\n> > @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> > * @nor:\tpointer to a 'struct spi_nor'\n> > * @addr:\toffset in the SFDP area to start reading data from\n> > * @len:\tnumber of bytes to read\n> > - * @buf:\tbuffer where the SFDP data are copied into\n> > + * @buf:\tbuffer where the SFDP data are copied into (dma-safe memory)\n> > *\n> > * Whatever the actual numbers of bytes for address and dummy cycles are\n> > * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> > @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> > \treturn ret;\n> > }\n> > \n> > +/**\n> > + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> > + * @nor:\tpointer to a 'struct spi_nor'\n> > + * @addr:\toffset in the SFDP area to start reading data from\n> > + * @len:\tnumber of bytes to read\n> > + * @buf:\tbuffer where the SFDP data are copied into\n> > + *\n> > + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> > + * guaranteed to be dma-safe.\n> > + *\n> > + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> > + * otherwise.\n> > + */\n> > +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> > +\t\t\t\t\tsize_t len, void *buf)\n> > +{\n> > +\tvoid *dma_safe_buf;\n> > +\tint ret;\n> > +\n> > +\tdma_safe_buf = kmalloc(len, GFP_KERNEL);\n> > +\tif (!dma_safe_buf)\n> > +\t\treturn -ENOMEM;\n> > +\n> > +\tret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> > +\tmemcpy(buf, dma_safe_buf, len);\n> > +\tkfree(dma_safe_buf);\n> > +\n> > +\treturn ret;\n> > +}\n> > +\n> > struct sfdp_parameter_header {\n> > \tu8\t\tid_lsb;\n> > \tu8\t\tminor;\n> > @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> > \t\t bfpt_header->length * sizeof(u32));\n> > \taddr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> > \tmemset(&bfpt, 0, sizeof(bfpt));\n> > -\terr = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> > +\terr = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> > \tif (err < 0)\n> > \t\treturn err;\n> > \n> > @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> > \tint i, err;\n> > \n> > \t/* Get the SFDP header. */\n> > -\terr = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> > +\terr = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> > \tif (err < 0)\n> > \t\treturn err;\n> > \n> > \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"tki7p75C\"; \n\tdkim-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 3xnsBQ37ZCz9sCZ\n\tfor ;\n\tThu, 7 Sep 2017 17:13:50 +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 1dpr0Q-000151-HQ; Thu, 07 Sep 2017 07:13:42 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpr00-0000zK-CV\n\tfor linux-mtd@lists.infradead.org; Thu, 07 Sep 2017 07:13:18 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 78637209AE; Thu, 7 Sep 2017 09:12:54 +0200 (CEST)","from bbrezillon (unknown [217.114.201.150])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 3542A2097A;\n\tThu, 7 Sep 2017 09:12:54 +0200 (CEST)"],"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\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=Rfrl4sr3m7Zwwdd1fYcjzLVYF3jSOXSO026YWSo2GU8=;\n\tb=tki7p75CIaztX3\n\tR2PErS4DeU+rdYHgM90/TaEo0kQdqt4VT+aN0g+j16HgL9Z3Gn5oo6FEc+JH12mGNxiS3EAa4djtr\n\thDx7rKuWUQt6dIyfHUym3dAlajzRjUGcxafwVUuqM2+Jgi4DAJ8rjD6EhfCFhVyCXkOPYSf9aBDKn\n\twrhgF/JKNbYKw2bABUJDfg2HUY4GvosZxduNIyQOX1gnQWClcS+fw6iKOiBqI63ugPOXDfQYEoP2j\n\tu9NCWRZNxljy2J3Zw2ORqepDV+tUUVHiqgc4MJcKilIA18In1AhwJqtuelyfvjdcv+PZGXYdvltAZ\n\t8Qvsz5HT1dMn9ZJ34amA==;","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Thu, 7 Sep 2017 09:12:51 +0200","From":"Boris Brezillon ","To":"Cyrille Pitchen ","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","Message-ID":"<20170907091251.5ff0333f@bbrezillon>","In-Reply-To":"","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>\n\t","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_001316_840419_398BD15F ","X-CRM114-Status":"GOOD ( 26.11 )","X-Spam-Score":"-0.2 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-0.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist\n\t[URIs: wedev4u.fr]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"richard@nod.at, linux-kernel@vger.kernel.org,\n\tNicolas Ferre , marek.vasut@gmail.com,\n\tlinux-mtd@lists.infradead.org, geert@linux-m68k.org,\n\tcomputersforpeace@gmail.com, dwmw2@infradead.org","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1764571,"web_url":"http://patchwork.ozlabs.org/comment/1764571/","msgid":"","list_archive_url":null,"date":"2017-09-07T08:00:50","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":703,"url":"http://patchwork.ozlabs.org/api/people/703/","name":"Geert Uytterhoeven","email":"geert@linux-m68k.org"},"content":"Hi Cyrille,\n\nOn Wed, Sep 6, 2017 at 11:45 PM, Cyrille Pitchen\n wrote:\n> spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> When the m25p80 driver is used (pretty common case), nor->read() is then\n> implemented by the m25p80_read() function, which is likely to initialize a\n> 'struct spi_transfer' from its buf argument before appending this\n> structure inside the 'struct spi_message' argument of spi_sync().\n>\n> Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> memory as buf argument, hence not in a dma-safe area.\n> Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> given a kmalloc'ed buffer argument, hence dma-safe.\n>\n> So this patch fixes this issue by introducing a\n> spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> buffer.\n>\n> Reported-by: Geert Uytterhoeven \n> Signed-off-by: Cyrille Pitchen \n\nWhile this patch got rid of the warning, it does not fix the SPI FLASH\nidentification\nissue:\n\n m25p80 spi0.0: s25fl512s (0 Kbytes)\n 3 ofpart partitions found on MTD device spi0.0\n Creating 3 MTD partitions on \"spi0.0\":\n 0x000000000000-0x000000040000 : \"loader\"\n mtd: partition \"loader\" is out of reach -- disabled\n 0x000000040000-0x000000080000 : \"system\"\n mtd: partition \"system\" is out of reach -- disabled\n 0x000000080000-0x000004000000 : \"user\"\n mtd: partition \"user\" is out of reach -- disabled\n\nI noticed there's still one direct call to spi_nor_read_sfdp() left in\nspi_nor_parse_sfdp().\nI tried changing that to spi_nor_read_sfdp_dma_unsafe(), but that didn't help.\n\n> --- a/drivers/mtd/spi-nor/spi-nor.c\n> +++ b/drivers/mtd/spi-nor/spi-nor.c\n> @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> * @nor: pointer to a 'struct spi_nor'\n> * @addr: offset in the SFDP area to start reading data from\n> * @len: number of bytes to read\n> - * @buf: buffer where the SFDP data are copied into\n> + * @buf: buffer where the SFDP data are copied into (dma-safe memory)\n> *\n> * Whatever the actual numbers of bytes for address and dummy cycles are\n> * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> return ret;\n> }\n>\n> +/**\n> + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> + * @nor: pointer to a 'struct spi_nor'\n> + * @addr: offset in the SFDP area to start reading data from\n> + * @len: number of bytes to read\n> + * @buf: buffer where the SFDP data are copied into\n> + *\n> + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> + * guaranteed to be dma-safe.\n> + *\n> + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> + * otherwise.\n> + */\n> +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> + size_t len, void *buf)\n> +{\n> + void *dma_safe_buf;\n> + int ret;\n> +\n> + dma_safe_buf = kmalloc(len, GFP_KERNEL);\n> + if (!dma_safe_buf)\n> + return -ENOMEM;\n> +\n> + ret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> + memcpy(buf, dma_safe_buf, len);\n> + kfree(dma_safe_buf);\n> +\n> + return ret;\n> +}\n> +\n> struct sfdp_parameter_header {\n> u8 id_lsb;\n> u8 minor;\n> @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> bfpt_header->length * sizeof(u32));\n> addr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> memset(&bfpt, 0, sizeof(bfpt));\n> - err = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> + err = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> if (err < 0)\n> return err;\n>\n> @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> int i, err;\n>\n> /* Get the SFDP header. */\n> - err = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> + err = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> if (err < 0)\n> return err;\n>\n\nInstead of having buffers on the stack, passing them around through multiple\ncall levels, and then kmalloc()ing a buffer, what about using the helpers in\n instead, which take care of the issue through the\nstatic bounce\nbuffer or kmalloc() themselves?\n\nGr{oetje,eeting}s,\n\n Geert\n\n--\nGeert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org\n\nIn personal conversations with technical people, I call myself a hacker. But\nwhen I'm talking to journalists I just say \"programmer\" or something like that.\n -- Linus Torvalds","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"Vk1/0mNC\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"sS8niWZh\"; 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 3xntFs5JQDz9s9Y\n\tfor ;\n\tThu, 7 Sep 2017 18:01:53 +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 1dprkt-0003lm-Oz; Thu, 07 Sep 2017 08:01:43 +0000","from mail-pf0-x242.google.com ([2607:f8b0:400e:c00::242])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dprkO-0003eW-UT\n\tfor linux-mtd@lists.infradead.org; Thu, 07 Sep 2017 08:01:20 +0000","by mail-pf0-x242.google.com with SMTP id q76so4178266pfq.5\n\tfor ;\n\tThu, 07 Sep 2017 01:00:52 -0700 (PDT)","by 10.100.160.9 with HTTP; Thu, 7 Sep 2017 01:00:50 -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=w08MsjbthOMB0AoYaT3tP5OZTwp0n/sXNCXQJF+ZHnk=;\n\tb=Vk1/0mNCUpcVbO\n\tPUYMLyEDLX8IF/7mWN78WISM2mh4PP4gNcNuDGPbpcAYdjDVKEdr2J/89i7SJdN0WJjvRpgdf3HTP\n\tYPYtbT3PTgwHYhUL0IWJzM2buAz+9aHSHjE6wejZ/DM4Yj5Hilly71bH8Bw8JMLaZG7fl675qnbQE\n\tkJR05FXBAJOiAa4mlMEBDcC/xOlvxu/OSYflyOWQg84Lwo9d1tQgw9/FdH+xH8j9fTU/KPexi6Pnk\n\tTMVdP4ZVr8+F9hY1tqO3je/W67EXFHSsTwJHi0dLxZ14jCWWfG6PSVHLLPNlc4tFCKUriO+rJ7wLa\n\t7XsPBJk1B7XbvC8shObA==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=c1KtQgxuw18ynk3z4ktFpMXxGYaWG/ouFMyoT9/scqQ=;\n\tb=sS8niWZhaDdyO32m+GZOaaPsWQWYCxn9Fq2oNbAIem6l+dSkKJtqGb/9FWsZREZi5F\n\tz4eqnGhVyEyjFUAT3VbglR0gcITkJsUIdMmeR5i5qImnXKpZXNwmaE6ntoXyXD6FtvPA\n\tbi78/pq47O2N2TYTchXjknX/OL625ogIwdGT+BBw994qr6TAjbkN2wRpDRo0g5afSdJ4\n\t3oqKA3NJNdvcn4EGYV1vy8IaILNWzzHyMY1UoLahdbbAQXss0Wct7F9pIw2sCZBE7sV1\n\tlUhoRnfpA4CSBaYs5WDT+zeKQd8qo7dkqPFiZH+H1QiMefesK1m743mipe11zzL01Y8F\n\tgGcQ=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:sender:in-reply-to:references:from\n\t:date:message-id:subject:to:cc;\n\tbh=c1KtQgxuw18ynk3z4ktFpMXxGYaWG/ouFMyoT9/scqQ=;\n\tb=KoN5RN8tMTkHnSss3HaqirzhgQuK/j9lBNLmbVQMOkfq6aj7Mm/uY6DF6c8UBdpHXl\n\tx6g0D02T0Z9cHJk166OqsZL9MleN37s2Pfeil5RWA4+Ccr3mH5hSQl+O14a7QxvAUfJd\n\tZZnuIquQL8KtzzfJI/9NxtFqe1lAqELoUER1G5LqTuSBkJSahK731OtXoWYrdJboy+uv\n\tr6Fy9FFp6aky5YLxL6HW25L96Azeht+GUGSKb/x3ONFRWqes+F68bs13njMR1O1gJl7P\n\t+KmeefPLE7eBljJAfQmyI/xYxSHkS4WPMY2Lr8/IVWPKTFkuH7QHYP7YjtoDIRQzwn72\n\tbd/Q==","X-Gm-Message-State":"AHPjjUhwfBWQHcU1Lv7/cSxVecPtoofS1dObNEa1prfVkiWtu1MMdcn+\n\txO8ChHkSBSbn0fsrLrBxF6wwCgN5dw==","X-Google-Smtp-Source":"ADKCNb65TnzkbmCW/OEjUmIxLI0JcMmyZ95QHb/TZyhJOQP7eUzgGOfJlS+7YRI3FgPEJI5zobR0temFu5JU36nokUA=","X-Received":"by 10.84.253.2 with SMTP id z2mr2038974pll.354.1504771251242;\n\tThu, 07 Sep 2017 01:00:51 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","From":"Geert Uytterhoeven ","Date":"Thu, 7 Sep 2017 10:00:50 +0200","X-Google-Sender-Auth":"HcVDlXXSYK8uZGMz_5YhKbbPmCA","Message-ID":"","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","To":"Cyrille Pitchen ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_010113_111459_686343BA ","X-CRM114-Status":"GOOD ( 24.75 )","X-Spam-Score":"0.0 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (0.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist\n\t[URIs: wedev4u.fr]\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:242 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (geert.uytterhoeven[at]gmail.com)\n\t0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level\n\tmail domains are different\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\n\t0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and\n\tEnvelopeFrom freemail headers are different","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Boris BREZILLON ,\n\tRichard Weinberger ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tLinux-Renesas ,\n\tMarek Vasut , Mark Brown , \n\tMTD Maling List ,\n\tBrian Norris ,\n\tDavid Woodhouse ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1764668,"web_url":"http://patchwork.ozlabs.org/comment/1764668/","msgid":"<20170907133756.6c1f02f6@bbrezillon>","list_archive_url":null,"date":"2017-09-07T11:37:56","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":63120,"url":"http://patchwork.ozlabs.org/api/people/63120/","name":"Boris Brezillon","email":"boris.brezillon@free-electrons.com"},"content":"On Thu, 7 Sep 2017 10:00:50 +0200\nGeert Uytterhoeven wrote:\n\n> Hi Cyrille,\n> \n> On Wed, Sep 6, 2017 at 11:45 PM, Cyrille Pitchen\n> wrote:\n> > spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> > When the m25p80 driver is used (pretty common case), nor->read() is then\n> > implemented by the m25p80_read() function, which is likely to initialize a\n> > 'struct spi_transfer' from its buf argument before appending this\n> > structure inside the 'struct spi_message' argument of spi_sync().\n> >\n> > Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> > 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> > three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> > memory as buf argument, hence not in a dma-safe area.\n> > Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> > given a kmalloc'ed buffer argument, hence dma-safe.\n> >\n> > So this patch fixes this issue by introducing a\n> > spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> > spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> > buffer.\n> >\n> > Reported-by: Geert Uytterhoeven \n> > Signed-off-by: Cyrille Pitchen \n> \n> While this patch got rid of the warning, it does not fix the SPI FLASH\n> identification\n> issue:\n> \n> m25p80 spi0.0: s25fl512s (0 Kbytes)\n> 3 ofpart partitions found on MTD device spi0.0\n> Creating 3 MTD partitions on \"spi0.0\":\n> 0x000000000000-0x000000040000 : \"loader\"\n> mtd: partition \"loader\" is out of reach -- disabled\n> 0x000000040000-0x000000080000 : \"system\"\n> mtd: partition \"system\" is out of reach -- disabled\n> 0x000000080000-0x000004000000 : \"user\"\n> mtd: partition \"user\" is out of reach -- disabled\n> \n> I noticed there's still one direct call to spi_nor_read_sfdp() left in\n> spi_nor_parse_sfdp().\n> I tried changing that to spi_nor_read_sfdp_dma_unsafe(), but that didn't help.\n> \n> > --- a/drivers/mtd/spi-nor/spi-nor.c\n> > +++ b/drivers/mtd/spi-nor/spi-nor.c\n> > @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> > * @nor: pointer to a 'struct spi_nor'\n> > * @addr: offset in the SFDP area to start reading data from\n> > * @len: number of bytes to read\n> > - * @buf: buffer where the SFDP data are copied into\n> > + * @buf: buffer where the SFDP data are copied into (dma-safe memory)\n> > *\n> > * Whatever the actual numbers of bytes for address and dummy cycles are\n> > * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> > @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> > return ret;\n> > }\n> >\n> > +/**\n> > + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> > + * @nor: pointer to a 'struct spi_nor'\n> > + * @addr: offset in the SFDP area to start reading data from\n> > + * @len: number of bytes to read\n> > + * @buf: buffer where the SFDP data are copied into\n> > + *\n> > + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> > + * guaranteed to be dma-safe.\n> > + *\n> > + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> > + * otherwise.\n> > + */\n> > +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> > + size_t len, void *buf)\n> > +{\n> > + void *dma_safe_buf;\n> > + int ret;\n> > +\n> > + dma_safe_buf = kmalloc(len, GFP_KERNEL);\n> > + if (!dma_safe_buf)\n> > + return -ENOMEM;\n> > +\n> > + ret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> > + memcpy(buf, dma_safe_buf, len);\n> > + kfree(dma_safe_buf);\n> > +\n> > + return ret;\n> > +}\n> > +\n> > struct sfdp_parameter_header {\n> > u8 id_lsb;\n> > u8 minor;\n> > @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> > bfpt_header->length * sizeof(u32));\n> > addr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> > memset(&bfpt, 0, sizeof(bfpt));\n> > - err = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> > + err = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> > if (err < 0)\n> > return err;\n> >\n> > @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> > int i, err;\n> >\n> > /* Get the SFDP header. */\n> > - err = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> > + err = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> > if (err < 0)\n> > return err;\n> > \n> \n> Instead of having buffers on the stack, passing them around through multiple\n> call levels, and then kmalloc()ing a buffer, what about using the helpers in\n> instead, which take care of the issue through the\n> static bounce\n> buffer or kmalloc() themselves?\n\nAre you referring to spi_write_then_read()? If this is the case, I'm not\nsure we can use this because m25p80_read/write() can have more than 2\ntransfers.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"LmuhmMVP\"; \n\tdkim-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 3xnz4P6cGYz9sRY\n\tfor ;\n\tThu, 7 Sep 2017 21:39:01 +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 1dpv95-0001hR-4U; Thu, 07 Sep 2017 11:38:55 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpv8g-0001de-7L\n\tfor linux-mtd@lists.infradead.org; Thu, 07 Sep 2017 11:38:32 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid BA3B22085A; Thu, 7 Sep 2017 13:38:06 +0200 (CEST)","from bbrezillon (unknown [217.114.201.150])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 71ABC20830;\n\tThu, 7 Sep 2017 13:37:56 +0200 (CEST)"],"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\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=bi7CqGkPnQjrQziPGO2xxc59523OpFYjMcB+t75zwXE=;\n\tb=LmuhmMVP35i0mw\n\tyQDB8gzPWlg/KyMDdGaNbKZiREuwDP5QBE9t75jt1jSyWPmovE68jSMpPABfAwMkKFfCUnNd4gInq\n\tDwbVkB+SMHNl9lbxPK7kFYGtB3hR9w4YsO6Z8UrCp1pzKH4ctG0f/Vo/U+L4n8u1/LIw53pGznSNR\n\tDeAwBxvefWV4LpRVjkLsHPY5EPOjLcaqwGw4WveEEUll519o6sphijsSsTHRWy76yBGBIEfpZ0Kns\n\trQDZ6PcUlotyEXpiURjUHJ8+Hip1QwTtJNOy5wyjpg2uUBEdongzTJokF/jyojgHyBfYXszCbLylv\n\tdveCoClt+3y/uOFkyvkg==;","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Thu, 7 Sep 2017 13:37:56 +0200","From":"Boris Brezillon ","To":"Geert Uytterhoeven ","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","Message-ID":"<20170907133756.6c1f02f6@bbrezillon>","In-Reply-To":"","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>\n\t","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170907_043830_607115_FEA19826 ","X-CRM114-Status":"GOOD ( 26.85 )","X-Spam-Score":"-0.2 (/)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-0.2 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist\n\t[URIs: wedev4u.fr]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Richard Weinberger ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tLinux-Renesas ,\n\tMarek Vasut , Mark Brown , \n\tMTD Maling List ,\n\tCyrille Pitchen ,\n\tBrian Norris ,\n\tDavid Woodhouse ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1764676,"web_url":"http://patchwork.ozlabs.org/comment/1764676/","msgid":"","list_archive_url":null,"date":"2017-09-07T11:44:22","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":703,"url":"http://patchwork.ozlabs.org/api/people/703/","name":"Geert Uytterhoeven","email":"geert@linux-m68k.org"},"content":"Hi Boris,\n\nOn Thu, Sep 7, 2017 at 1:37 PM, Boris Brezillon\n wrote:\n> On Thu, 7 Sep 2017 10:00:50 +0200\n> Geert Uytterhoeven wrote:\n>> Instead of having buffers on the stack, passing them around through multiple\n>> call levels, and then kmalloc()ing a buffer, what about using the helpers in\n>> instead, which take care of the issue through the\n>> static bounce\n>> buffer or kmalloc() themselves?\n>\n> Are you referring to spi_write_then_read()? If this is the case, I'm not\n\nFor example. There are more of them.\n\n> sure we can use this because m25p80_read/write() can have more than 2\n> transfers.\n\nOK.More than two transfers may need special handling.\n\nGr{oetje,eeting}s,\n\n Geert\n\n--\nGeert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org\n\nIn personal conversations with technical people, I call myself a hacker. But\nwhen I'm talking to journalists I just say \"programmer\" or something like that.\n -- Linus Torvalds","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"UTvsZGg0\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=infradead.org header.i=@infradead.org\n\theader.b=\"HvxknxGD\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"A1BTMk68\"; 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 3xnzCj0KrRz9s2G\n\tfor ;\n\tThu, 7 Sep 2017 21:45:21 +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 1dpvFC-0004fv-Vd; Thu, 07 Sep 2017 11:45:14 +0000","from merlin.infradead.org ([2001:8b0:10b:1231::1])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpvEo-0004f4-TU\n\tfor linux-mtd@bombadil.infradead.org; Thu, 07 Sep 2017 11:44:51 +0000","from mail-pf0-x243.google.com ([2607:f8b0:400e:c00::243])\n\tby merlin.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dpvEm-000682-1M\n\tfor linux-mtd@lists.infradead.org; Thu, 07 Sep 2017 11:44:48 +0000","by mail-pf0-x243.google.com with SMTP id a2so4396232pfj.4\n\tfor ;\n\tThu, 07 Sep 2017 04:44:25 -0700 (PDT)","by 10.100.160.9 with HTTP; Thu, 7 Sep 2017 04:44:22 -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=7H59R+HUHEX5XfE+qsVRTRYT3PAUM7FChUMYhrBzE+M=;\n\tb=UTvsZGg0Gx0iDV\n\t/0zAENmKhxdvKbHWycckKQu8H+WXSXafCEuiOm3jb5Jq/BsE9TDVnLgtqNEPBM5xLYHwu1ViCeb2j\n\ta34qcdBzzzscMEBsBNXeN2DG5ZMbEjy0I8Imcx0xKneKtfMQYlOc/FvsttO8GZTZC2bFAt9uXc4Oq\n\tkW0Z+xv2BgbDzD5Ug6x5JBAAQGIbU+YYDmEWeO+P2eAd8DPdZUQXOlraiSlJTjiGd/vWDJ+l0cb0z\n\toYe7r0NdRJ8HEZbmU59QmCNEYL3T4xbAPtFuWOT0tO/FmdI1JJ0ajmACGq/wECoYlc9QhZHYIHt4H\n\tZdwqKK7Ca+joKuCRLSww==;","v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=merlin.20170209;\n\th=Content-Type:Cc:To:Subject:Message-ID:\n\tDate:From:References:In-Reply-To:Sender:MIME-Version:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:\n\tList-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;\n\tbh=+pm+UOHnt5kVcbmzjkWu4l8eXIpNhJ5UKkS6lvMLqf8=;\n\tb=HvxknxGDTnV8Nut7m6GYjcMyf\n\tDKPToZoViyDPs1UUp6ehpzxxgLsQ9IL56H45HOhzAKeDtRbm8xLVYHz+tm23Rkq+vZw5MkbStlXhw\n\tcWBGCUEY8d0jzUxLu3Mb220MWG/gsQ26aDYXZKpgMK9i9ZD2eVbtjOAxWbt9M/4YCuVgCSkchtpfF\n\tqTWnIDvp3fPXoMjA6qBaPeasMkbCeh7/uNJmIQFOTtdx8GhvTZKm/p7mP/YOC6OFHkIiyTh5ZXCUW\n\tyGz2Ee0Gw+QI7HJ2XQOPUznfC5Xq21BEjL+XqGO+jW0aFcZC6R89DFof9SvjsDamT1ka2l/IXfy6q\n\tfIdjfi/Qg==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:sender:in-reply-to:references:from:date:message-id\n\t:subject:to:cc;\n\tbh=+pm+UOHnt5kVcbmzjkWu4l8eXIpNhJ5UKkS6lvMLqf8=;\n\tb=A1BTMk68qIii/ubhG/jZR4N1tSHGveicsRuknRC4l4g0n7xklA+9KrB7DBX5jbqH5y\n\tzoyCUk3wuFkE+bu/9jeuPlc3V9eRBZ9K3qSx4aL0NMAeYxc5PhU/XKLPUnWtvjWGzljJ\n\tay/DX1ob80Se+CWtJ0+PuvpWF/YOOJuvGjXhZLEby0O1y4bXfzpkX/oWiNe69Sj+Gz1E\n\txF7HLs70TT+H2bc1jr93tzBeJ7ZiKk7jMve+k1kzjnN0D4SwaktEUt5sNsZP+DQ43SIb\n\tlqo1RdLJOOdxCdVbJcwqczw0b5Bkw1gKwCyYdgbZ4xtTtp2n21DaaMl7TtHWs53SRWcE\n\tEc9Q=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:sender:in-reply-to:references:from\n\t:date:message-id:subject:to:cc;\n\tbh=+pm+UOHnt5kVcbmzjkWu4l8eXIpNhJ5UKkS6lvMLqf8=;\n\tb=bLjv7s8guFmxI0iVtAWPtPh+q3UH8r84INQz7hbvV2Crfk6p2LIJI7c3ZK65QLuOdX\n\tNhPM6Xq/BCANuSiW5CbYxa3Ud1kmmx0W0EqjKk2QT4Nnkii9Mp5a327uSP8cdva0jAtl\n\tWWzN64BUmzUSov8yYfPLKrTQqyD131vQ7zawKZxk+4ymwp8h+XxeYxeIoLQzgASPewdN\n\t6ovYvYMMXBVmFK7K+IjEfcyWdxSQHq2aHQg+bLvOL+BvDTfcu16TH8br/0myaxDmCs/3\n\tcGpu+gXubov6iOb7KTu33Yi/EaNthdk9DN9rm2Xfazs699X+GRZMPhSdcXujS5hE7iYz\n\tc9sg==","X-Gm-Message-State":"AHPjjUgmiHJBSBOMji+VcAZ7QqmaT4vbOXDASabmMI1CDyXCk6W5p4sI\n\t/UPkZPV22bw/j8550IOsGhSzT1GlOw==","X-Google-Smtp-Source":"ADKCNb6TjazCqjEzkY7wtygo4HmDO0XVUBOCdRtJ2EJFJ/27H1J5WsL2RksIBYUDhwrh2Q3/sX5OcfMkV6+oYy4RXDw=","X-Received":"by 10.84.232.14 with SMTP id h14mr2707670plk.274.1504784663488; \n\tThu, 07 Sep 2017 04:44:23 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170907133756.6c1f02f6@bbrezillon>","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>\n\t\n\t<20170907133756.6c1f02f6@bbrezillon>","From":"Geert Uytterhoeven ","Date":"Thu, 7 Sep 2017 13:44:22 +0200","X-Google-Sender-Auth":"arSl0EteUyoqArwozea9ptn0_hE","Message-ID":"","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","To":"Boris Brezillon ","X-Spam-Note":"CRM114 invocation failed","X-Spam-Score":"-1.7 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on merlin.infradead.org summary:\n\tContent analysis details: (-1.7 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:243 listed in] [list.dnswl.org]\n\t0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level\n\tmail domains are different\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (geert.uytterhoeven[at]gmail.com)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and\n\tEnvelopeFrom freemail headers are different","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Richard Weinberger ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tLinux-Renesas ,\n\tMarek Vasut , Mark Brown , \n\tMTD Maling List ,\n\tCyrille Pitchen ,\n\tBrian Norris ,\n\tDavid Woodhouse ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1765920,"web_url":"http://patchwork.ozlabs.org/comment/1765920/","msgid":"<20170910110358.366ac1cc@bbrezillon>","list_archive_url":null,"date":"2017-09-10T09:03:58","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":63120,"url":"http://patchwork.ozlabs.org/api/people/63120/","name":"Boris Brezillon","email":"boris.brezillon@free-electrons.com"},"content":"On Thu, 7 Sep 2017 10:00:50 +0200\nGeert Uytterhoeven wrote:\n\n> Hi Cyrille,\n> \n> On Wed, Sep 6, 2017 at 11:45 PM, Cyrille Pitchen\n> wrote:\n> > spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> > When the m25p80 driver is used (pretty common case), nor->read() is then\n> > implemented by the m25p80_read() function, which is likely to initialize a\n> > 'struct spi_transfer' from its buf argument before appending this\n> > structure inside the 'struct spi_message' argument of spi_sync().\n> >\n> > Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> > 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> > three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> > memory as buf argument, hence not in a dma-safe area.\n> > Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> > given a kmalloc'ed buffer argument, hence dma-safe.\n> >\n> > So this patch fixes this issue by introducing a\n> > spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> > spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> > buffer.\n> >\n> > Reported-by: Geert Uytterhoeven \n> > Signed-off-by: Cyrille Pitchen \n> \n> While this patch got rid of the warning, it does not fix the SPI FLASH\n> identification\n> issue:\n> \n> m25p80 spi0.0: s25fl512s (0 Kbytes)\n> 3 ofpart partitions found on MTD device spi0.0\n> Creating 3 MTD partitions on \"spi0.0\":\n> 0x000000000000-0x000000040000 : \"loader\"\n> mtd: partition \"loader\" is out of reach -- disabled\n> 0x000000040000-0x000000080000 : \"system\"\n> mtd: partition \"system\" is out of reach -- disabled\n> 0x000000080000-0x000004000000 : \"user\"\n> mtd: partition \"user\" is out of reach -- disabled\n> \n> I noticed there's still one direct call to spi_nor_read_sfdp() left in\n> spi_nor_parse_sfdp().\n\nI think the remaining call site is valid because the caller allocates\nthe buffer it passes to spi_nor_parse_sfdp() with kmalloc().\n\n> I tried changing that to spi_nor_read_sfdp_dma_unsafe(), but that didn't help.\n\nOk, we're still working on that. Did you have time to test Cyrille's\ndebug patch?\n\nCyrille, can we add more consistency checks in the SFDP parser code to\ndetect devices exposing invalid SFPD pages? For example, a device size\nof 0 is impossible and could be easily detected when parsing the SFPD?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"RPfEcaSY\"; \n\tdkim-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 3xqlX41Qj4z9sNV\n\tfor ;\n\tSun, 10 Sep 2017 19:05:35 +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 1dqyB0-0005jR-G1; Sun, 10 Sep 2017 09:05:14 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqyAD-0005b1-Vi\n\tfor linux-mtd@lists.infradead.org; Sun, 10 Sep 2017 09:04:38 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 89354209BF; Sun, 10 Sep 2017 11:03:59 +0200 (CEST)","from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 4D43D209A7;\n\tSun, 10 Sep 2017 11:03:59 +0200 (CEST)"],"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\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=ulPueZbXglii5viHNOj4ugKdSHJDs6rXHXT/OqxnmjE=;\n\tb=RPfEcaSYHLqIX7\n\taqWfXA0mHKqGyRBfGRslQOTtkcxGMwbsYvIsJ9Yr30kueVAGe5CJWGy+aecBIX3C4cAvtLK0WchtA\n\t9aIUcQb19U2SQ/tEActrQONMj9I0U5XI7xJWVMDtAVcF8KqPpIfSgPQGAny8cmTq0ZZc6sSV7qcf/\n\tD6Xaahwl9KTlmeD5ppO2d08OE+VD84/knFooQWnacS5wY29vwJhkJ06yl8RxzgWxdKhT7utUCx0dS\n\tX+fNeGLSzlxgp9xYXXqhM508k00ZP2W+RHLXw8fNZmyXDN0wRvfi32CyXxJq1A2ar4X8PTVme96VU\n\tvBVwNu5TVJ6PegLYgpWA==;","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Sun, 10 Sep 2017 11:03:58 +0200","From":"Boris Brezillon ","To":"Geert Uytterhoeven ","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","Message-ID":"<20170910110358.366ac1cc@bbrezillon>","In-Reply-To":"","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>\n\t","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170910_020435_347397_023F4333 ","X-CRM114-Status":"GOOD ( 18.41 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Richard Weinberger ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tLinux-Renesas ,\n\tMarek Vasut , Mark Brown , \n\tMTD Maling List ,\n\tCyrille Pitchen ,\n\tBrian Norris ,\n\tDavid Woodhouse ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":1771357,"web_url":"http://patchwork.ozlabs.org/comment/1771357/","msgid":"<20170919221215.46625560@bbrezillon>","list_archive_url":null,"date":"2017-09-19T20:12:15","subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","submitter":{"id":63120,"url":"http://patchwork.ozlabs.org/api/people/63120/","name":"Boris Brezillon","email":"boris.brezillon@free-electrons.com"},"content":"On Wed, 6 Sep 2017 23:45:02 +0200\nCyrille Pitchen wrote:\n\n> spi_nor_read_sfdp() calls nor->read() to read the SFDP data.\n> When the m25p80 driver is used (pretty common case), nor->read() is then\n> implemented by the m25p80_read() function, which is likely to initialize a\n> 'struct spi_transfer' from its buf argument before appending this\n> structure inside the 'struct spi_message' argument of spi_sync().\n> \n> Besides the SPI sub-system states that both .tx_buf and .rx_buf members of\n> 'struct spi_transfer' must point into dma-safe memory. However, two of the\n> three calls of spi_nor_read_sfdp() were given pointers to stack allocated\n> memory as buf argument, hence not in a dma-safe area.\n> Hopefully, the third and last call of spi_nor_read_sfdp() was already\n> given a kmalloc'ed buffer argument, hence dma-safe.\n> \n> So this patch fixes this issue by introducing a\n> spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing\n> spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce\n> buffer.\n> \n> Reported-by: Geert Uytterhoeven \n> Signed-off-by: Cyrille Pitchen \n\nApplied.\n\nThanks,\n\nBoris\n\n> ---\n> \n> Compiled but not tested yet!\n> \n> drivers/mtd/spi-nor/spi-nor.c | 36 +++++++++++++++++++++++++++++++++---\n> 1 file changed, 33 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c\n> index cf1d4a15e10a..05254dd6a4a0 100644\n> --- a/drivers/mtd/spi-nor/spi-nor.c\n> +++ b/drivers/mtd/spi-nor/spi-nor.c\n> @@ -1784,7 +1784,7 @@ spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,\n> * @nor:\tpointer to a 'struct spi_nor'\n> * @addr:\toffset in the SFDP area to start reading data from\n> * @len:\tnumber of bytes to read\n> - * @buf:\tbuffer where the SFDP data are copied into\n> + * @buf:\tbuffer where the SFDP data are copied into (dma-safe memory)\n> *\n> * Whatever the actual numbers of bytes for address and dummy cycles are\n> * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always\n> @@ -1829,6 +1829,36 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,\n> \treturn ret;\n> }\n> \n> +/**\n> + * spi_nor_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.\n> + * @nor:\tpointer to a 'struct spi_nor'\n> + * @addr:\toffset in the SFDP area to start reading data from\n> + * @len:\tnumber of bytes to read\n> + * @buf:\tbuffer where the SFDP data are copied into\n> + *\n> + * Wrap spi_nor_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now not\n> + * guaranteed to be dma-safe.\n> + *\n> + * Return: -ENOMEM if kmalloc() fails, the return code of spi_nor_read_sfdp()\n> + * otherwise.\n> + */\n> +static int spi_nor_read_sfdp_dma_unsafe(struct spi_nor *nor, u32 addr,\n> +\t\t\t\t\tsize_t len, void *buf)\n> +{\n> +\tvoid *dma_safe_buf;\n> +\tint ret;\n> +\n> +\tdma_safe_buf = kmalloc(len, GFP_KERNEL);\n> +\tif (!dma_safe_buf)\n> +\t\treturn -ENOMEM;\n> +\n> +\tret = spi_nor_read_sfdp(nor, addr, len, dma_safe_buf);\n> +\tmemcpy(buf, dma_safe_buf, len);\n> +\tkfree(dma_safe_buf);\n> +\n> +\treturn ret;\n> +}\n> +\n> struct sfdp_parameter_header {\n> \tu8\t\tid_lsb;\n> \tu8\t\tminor;\n> @@ -2101,7 +2131,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,\n> \t\t bfpt_header->length * sizeof(u32));\n> \taddr = SFDP_PARAM_HEADER_PTP(bfpt_header);\n> \tmemset(&bfpt, 0, sizeof(bfpt));\n> -\terr = spi_nor_read_sfdp(nor, addr, len, &bfpt);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, addr, len, &bfpt);\n> \tif (err < 0)\n> \t\treturn err;\n> \n> @@ -2243,7 +2273,7 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,\n> \tint i, err;\n> \n> \t/* Get the SFDP header. */\n> -\terr = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);\n> +\terr = spi_nor_read_sfdp_dma_unsafe(nor, 0, sizeof(header), &header);\n> \tif (err < 0)\n> \t\treturn err;\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=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=\"sc66Ep4m\"; \n\tdkim-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 3xxYwC4rtbz9s81\n\tfor ;\n\tWed, 20 Sep 2017 06:13:15 +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 1duOtJ-0008JB-CH; Tue, 19 Sep 2017 20:13:09 +0000","from mail.free-electrons.com ([62.4.15.54])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1duOsy-00082b-FG\n\tfor linux-mtd@lists.infradead.org; Tue, 19 Sep 2017 20:13:07 +0000","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 580C620824; Tue, 19 Sep 2017 22:12:27 +0200 (CEST)","from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 13583209A3;\n\tTue, 19 Sep 2017 22:12:17 +0200 (CEST)"],"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\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=p75y8urkx06GNuxx2/tOwAxUmYTQPRWkqlBCCRsB/7U=;\n\tb=sc66Ep4mTobayu\n\tp6EJngkf4Pvu7SjRyh/iDb8Y3eqH7mNGx6WqhIeOA8q2TMRdqQvcxJFo/Ua6UEPXWQ1w61JtTmNG3\n\tGs9AMi2un7Sf5kGwMDbGBKZfK+pPs6rfdf+BGMKviuI1fX0dHHhHT5Hwv3kCb/E4UqiqwwYc0wexl\n\tJhmKItH3w55EPe7XTBz7Nl+FWzh9waqY9mZEwytlYE/BRqQm+VRx+t/2I25OR+zk+6j6gSr5GR05G\n\tgensu455MXqfmheJZZ8Mh1uFZOv+R+xWsK4pljLXfN+Vd3xAtRbN8bZKr9HXoued1iab54H2p9jeJ\n\tWXRHgDSRYh9QkXmISAFQ==;","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Tue, 19 Sep 2017 22:12:15 +0200","From":"Boris Brezillon ","To":"Cyrille Pitchen ","Subject":"Re: [PATCH] mtd: spi-nor: fix DMA unsafe buffer issue in\n\tspi_nor_read_sfdp()","Message-ID":"<20170919221215.46625560@bbrezillon>","In-Reply-To":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","References":"<20170906214502.26748-1-cyrille.pitchen@wedev4u.fr>","X-Mailer":"Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170919_131249_165859_FBA0F746 ","X-CRM114-Status":"GOOD ( 22.72 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"richard@nod.at, linux-kernel@vger.kernel.org, marek.vasut@gmail.com,\n\tlinux-mtd@lists.infradead.org, geert@linux-m68k.org,\n\tcomputersforpeace@gmail.com, dwmw2@infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}}]