Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp197286imn; Fri, 29 Jul 2022 04:26:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vk0gXnrs02fQQq6qmSXUiMuj5u1oqkCP4LJy8UFl08dCwXKetq0LPpLDWXwnOO7ViNRLKI X-Received: by 2002:aa7:9ae3:0:b0:528:d881:9ff with SMTP id y3-20020aa79ae3000000b00528d88109ffmr3153766pfp.66.1659094010757; Fri, 29 Jul 2022 04:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659094010; cv=none; d=google.com; s=arc-20160816; b=cjWx+dBHAN4yR+hg+3ViJEDld4pSfv5kfm0gD0NwOttSkivtqicN40daP+NINWPudN zTEZgXuXBOVJ0kAMuo8U/SvCNwTIKSc19d5H+u0K7CgY3cCjaJU8CgorAaWX46CIW+kP EZY/9LM/xZ79TtaVYUvOfqeWcWFFvU+djNTL+ul6NVYTXmrj4qaGXxkV0tC65oYWbbt2 ctiZEvPwqEan3WsZAsVtn52UdlD7LNmX5wqh0/Qjjr2kUeDVhig2a/I+j9GeXayfubXO 4p6pHV8Da9lgr7NpLQYaw7KVsXrGWgC0U/j7LT2D9zn6XrKoI6vu/9VSD52wlVp4wNO4 XtbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:references:in-reply-to :message-id:date:subject:cc:to:from; bh=lIykWUCki/DArVf+kbWM/GwbLmbGftbawprBKo8CAH0=; b=JBiY912LFLiHzKSI/cxPtcEmGeBUZlsTj/LXLvOLNAmxW23cs1z+3FR68ckxWDtPb0 2X1aIrnUpqO0rtGfBr2fwsTIzfIplNC9tlajiu8CekAejWgw/8mfITADTAW/RRAD+g/h eGIG+pQyLdpE+n5XqGgtkaY9PtSDPP/FWZVMpdIVAb1jk2k5SFLP+YyirDjRNCBG41vj ezToUfqXGYPxIXunEnkMo7ALnY8KaeKE1AWdwFEgc4/xXh7iLnlgroxjLBcon9YFyyY5 N4wOT/hNwMPFGqeETYpEFZl1x5GYd3zsH+B9d37DjDIrM2Rua4TlIQCYhzLNr9Dn7G25 fwbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o1-20020a634e41000000b0041a2b1878acsi3750027pgl.230.2022.07.29.04.26.35; Fri, 29 Jul 2022 04:26:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235729AbiG2LIy (ORCPT + 99 others); Fri, 29 Jul 2022 07:08:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231428AbiG2LIw (ORCPT ); Fri, 29 Jul 2022 07:08:52 -0400 X-Greylist: delayed 532 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 29 Jul 2022 04:08:52 PDT Received: from mail.thorsis.com (mail.thorsis.com [92.198.35.195]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 062456F7DE; Fri, 29 Jul 2022 04:08:51 -0700 (PDT) From: Alexander Dahl To: linux-mtd@lists.infradead.org Cc: Tudor Ambarus , miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, peda@axentia.se, nicolas.ferre@microchip.com, alexandre.belloni@bootlin.com, claudiu.beznea@microchip.com, bbrezillon@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] mtd: rawnand: atmel: Unmap streaming DMA mappings Date: Fri, 29 Jul 2022 12:59:55 +0200 Message-ID: <2099405.mp5hVA6q5l@ada> In-Reply-To: <20220728074014.145406-1-tudor.ambarus@microchip.com> References: <20220728074014.145406-1-tudor.ambarus@microchip.com> Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Clacks-Overhead: GNU Terry Pratchett X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Tudor, Am Donnerstag, 28. Juli 2022, 09:40:14 CEST schrieb Tudor Ambarus: > Every dma_map_single() call should have its dma_unmap_single() counterpart, > because the DMA address space is a shared resource and one could render the > machine unusable by consuming all DMA addresses. > > Cc: stable@vger.kernel.org > Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") > Signed-off-by: Tudor Ambarus > --- > drivers/mtd/nand/raw/atmel/nand-controller.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c > b/drivers/mtd/nand/raw/atmel/nand-controller.c index > 6ef14442c71a..330d2dafdd2d 100644 > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c > @@ -405,6 +405,7 @@ static int atmel_nand_dma_transfer(struct > atmel_nand_controller *nc, > > dma_async_issue_pending(nc->dmac); > wait_for_completion(&finished); > + dma_unmap_single(nc->dev, buf_dma, len, dir); > > return 0; Acked-by: Alexander Dahl After studying https://www.kernel.org/doc/html/latest/core-api/dma-api-howto.html this seems like the correct thing to do to me. I was made aware of this patch in IRC, after discussing a strange lzo decompression and/or page reading error with Richard after upgrading from kernel v5.2.21-rt13 to v5.15.49-rt47. Now testing this on top of 5.15.49-rt47 on two boards, both with Microchip sama5d27c 128MiB SiP and Spansion S34ML02G1 raw nand flash. Will report later. Thanks and greets Alex