From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18B8DC433EF for ; Mon, 28 Mar 2022 09:49:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239954AbiC1Jur (ORCPT ); Mon, 28 Mar 2022 05:50:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239941AbiC1Jup (ORCPT ); Mon, 28 Mar 2022 05:50:45 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0F5F41F9E; Mon, 28 Mar 2022 02:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=/93dChLt+Za1uKCUhSTu2aRMCha+vAJZKphFzk7McsE=; t=1648460942; x=1649670542; b=GrQqsPGmXslqKPkkMv5L9TKn0aHOqHUDd7Mwgbobfr+0/wj ZfRjwz5YxIiiphH2lJt0/j4nocADL6fH/wGwU0+eI/w/2NOg6NhhOGFUtGK+kLkkJ2jVdMxCuTmFS J3wqwMkDf3QphTt5Jx5M/CJzEsRRhwX2YRo4mRBNobtPwgt/VyA/7JtAhpxcAUyiFGkeUz7b9ZaAG DxIUHDdw/HVcbQ8Xjd8AyY2Ry+4ecO6/1wxFkPV8y2e24sPYClwRmqXlOOdyDtXQc8RzEzsZNUb7t KGzPMRop5JNPlDKyDrX4Lh3CslI/XWA8uWx9DKPodItgWYXUmO+/e8lHJgyLgxxA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1nYlzJ-001WuR-EZ; Mon, 28 Mar 2022 11:48:37 +0200 Message-ID: Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP From: Johannes Berg To: Halil Pasic Cc: Linus Torvalds , Maxime Bizon , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Robin Murphy , Christoph Hellwig , Oleksandr Natalenko , Marek Szyprowski , Kalle Valo , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Olha Cherevyk , iommu , linux-wireless , Netdev , Linux Kernel Mailing List , Greg Kroah-Hartman , stable Date: Mon, 28 Mar 2022 11:48:36 +0200 In-Reply-To: <20220327051502.63fde20a.pasic@linux.ibm.com> References: <1812355.tdWV9SEqCh@natalenko.name> <20220324055732.GB12078@lst.de> <4386660.LvFx2qVVIh@natalenko.name> <81ffc753-72aa-6327-b87b-3f11915f2549@arm.com> <878rsza0ih.fsf@toke.dk> <4be26f5d8725cdb016c6fdd9d05cfeb69cdd9e09.camel@freebox.fr> <20220324163132.GB26098@lst.de> <871qyr9t4e.fsf@toke.dk> <31434708dcad126a8334c99ee056dcce93e507f1.camel@freebox.fr> <298f4f9ccad7c3308d3a1fd8b4b4740571305204.camel@sipsolutions.net> <20220327051502.63fde20a.pasic@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sun, 2022-03-27 at 05:15 +0200, Halil Pasic wrote: > > The key here is "sync_sg API, all the parameters must be the same > as those passed into the single mapping API", but I have to admit, > I don't understand the *single* in here. > Hah. So I wasn't imagining things after all. However, as the rest of the thread arrives, this still means it's all broken ... :) > The intended meaning of the > last sentence is that one can do partial sync by choose > dma_hande_sync, size_sync such that dma_handle_mapping <= dma_handle_sync > < dma_handle_mapping + size_mapping and dma_handle_sync + size_sync <= > dma_handle_mapping + size_mapping. But the direction has to remain the > same. Right. > BTW, the current documented definition of the direction is about the > data transfer direction between memory and the device, and how the CPU > is interacting with the memory is not in scope. A quote form the > documentation. > > """ > ======================= ============================================= > DMA_NONE no direction (used for debugging) > DMA_TO_DEVICE data is going from the memory to the device > DMA_FROM_DEVICE data is coming from the device to the memory > DMA_BIDIRECTIONAL direction isn't known > ======================= ============================================= > """ > (Documentation/core-api/dma-api.rst) > > My feeling is, that re-defining the dma direction is not a good idea. But > I don't think my opinion has much weight here. However, this basically means that the direction argument to the flush APIs are completely useless, and we do have to define something new/else... johannes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C099AC43217 for ; Mon, 28 Mar 2022 09:49:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 542C64062A; Mon, 28 Mar 2022 09:49:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9unwUiIcVcr; Mon, 28 Mar 2022 09:49:04 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp2.osuosl.org (Postfix) with ESMTPS id A1EE3404B4; Mon, 28 Mar 2022 09:49:03 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 65DBBC001D; Mon, 28 Mar 2022 09:49:03 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 873BCC0012 for ; Mon, 28 Mar 2022 09:49:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5FAAA402C4 for ; Mon, 28 Mar 2022 09:49:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=sipsolutions.net Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3byAXyVoCmG for ; Mon, 28 Mar 2022 09:49:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by smtp4.osuosl.org (Postfix) with ESMTPS id EC68F4032F for ; Mon, 28 Mar 2022 09:49:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=/93dChLt+Za1uKCUhSTu2aRMCha+vAJZKphFzk7McsE=; t=1648460941; x=1649670541; b=f41zugckrB2OqXauAT9sfc852LXFz3Tai61DGZPQdaY13M1 ogVz3Dp/nhTuxFsrIA3peAM4o5k1eDD1oFwi4GuL8vF/oOmAu/2t1KhUj/LXQRi2Rg4NVQgA8eXDV Zmou+4a6qfxPG/vQrsB/mhObs5uAvQ1ePo8biVx/TrxnDac1LPDj0AU4Fmt5JQiltkK+5SekPmnlg uoKhXAl5B2Xf2bjme0Brkj7kvjgKpTt0unHvVoHMIcEV73Rkq2OlUs1YmaaNN9eYjlg1Oi+knUpXl iP2gq2269xIymjVv2eqAP8baeEE7d4mVTV8F76dc/JOQZn4chb85oDWzrP/cVV4w==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1nYlzJ-001WuR-EZ; Mon, 28 Mar 2022 11:48:37 +0200 Message-ID: Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP From: Johannes Berg To: Halil Pasic Date: Mon, 28 Mar 2022 11:48:36 +0200 In-Reply-To: <20220327051502.63fde20a.pasic@linux.ibm.com> References: <1812355.tdWV9SEqCh@natalenko.name> <20220324055732.GB12078@lst.de> <4386660.LvFx2qVVIh@natalenko.name> <81ffc753-72aa-6327-b87b-3f11915f2549@arm.com> <878rsza0ih.fsf@toke.dk> <4be26f5d8725cdb016c6fdd9d05cfeb69cdd9e09.camel@freebox.fr> <20220324163132.GB26098@lst.de> <871qyr9t4e.fsf@toke.dk> <31434708dcad126a8334c99ee056dcce93e507f1.camel@freebox.fr> <298f4f9ccad7c3308d3a1fd8b4b4740571305204.camel@sipsolutions.net> <20220327051502.63fde20a.pasic@linux.ibm.com> User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 X-malware-bazaar: not-scanned Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Greg Kroah-Hartman , Robin Murphy , Kalle Valo , linux-wireless , Oleksandr Natalenko , stable , "David S. Miller" , iommu , Olha Cherevyk , Jakub Kicinski , Maxime Bizon , Netdev , Paolo Abeni , Linus Torvalds , Christoph Hellwig , Linux Kernel Mailing List X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Sun, 2022-03-27 at 05:15 +0200, Halil Pasic wrote: > > The key here is "sync_sg API, all the parameters must be the same > as those passed into the single mapping API", but I have to admit, > I don't understand the *single* in here. > Hah. So I wasn't imagining things after all. However, as the rest of the thread arrives, this still means it's all broken ... :) > The intended meaning of the > last sentence is that one can do partial sync by choose > dma_hande_sync, size_sync such that dma_handle_mapping <= dma_handle_sync > < dma_handle_mapping + size_mapping and dma_handle_sync + size_sync <= > dma_handle_mapping + size_mapping. But the direction has to remain the > same. Right. > BTW, the current documented definition of the direction is about the > data transfer direction between memory and the device, and how the CPU > is interacting with the memory is not in scope. A quote form the > documentation. > > """ > ======================= ============================================= > DMA_NONE no direction (used for debugging) > DMA_TO_DEVICE data is going from the memory to the device > DMA_FROM_DEVICE data is coming from the device to the memory > DMA_BIDIRECTIONAL direction isn't known > ======================= ============================================= > """ > (Documentation/core-api/dma-api.rst) > > My feeling is, that re-defining the dma direction is not a good idea. But > I don't think my opinion has much weight here. However, this basically means that the direction argument to the flush APIs are completely useless, and we do have to define something new/else... johannes _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu