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 D159FC433EF for ; Mon, 28 Mar 2022 09:49:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239946AbiC1Juq (ORCPT ); Mon, 28 Mar 2022 05:50:46 -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: netdev@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