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 8B314C433EF for ; Mon, 28 Mar 2022 09:51:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240002AbiC1Jw6 (ORCPT ); Mon, 28 Mar 2022 05:52:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240015AbiC1Jwu (ORCPT ); Mon, 28 Mar 2022 05:52:50 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4D504F477; Mon, 28 Mar 2022 02:51:09 -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=nJO5E5YD857Be4i83ypHN59i/VCIHMrXJalTXZF8ChM=; t=1648461070; x=1649670670; b=yK20yxadnBzN8+9B1mQwJU3zPiDgzvgZdc6u8IMOow3L36F JN7CgNZvilXkGCxHZF3v6gt8pCZRES6bh4hP4gsxSuNeSuEJCG3DTpkSLLQ9dscCS0MqHoSvmjibe nCyBHIPgyrCibtGVlDv45CQbNwt0wJityVt1jRZzfomB8sptqE7XqKUm03wjBAz6RdsyTf2jJkVYH oV+6U/yWl/7iZIAwTENCotrfMAEnsWrdPzvBdMpZksjbjyldCmVxKdPyb0723wZd3ZBIxgzE24ZjO 6pQTptAn6sIMyGZU+iIuB1eHqvW9/BWUPuw7+62LJoQe1pnnvcmoLmOSNGemSIvA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1nYm1Y-001X37-2H; Mon, 28 Mar 2022 11:50:56 +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:50:54 +0200 In-Reply-To: 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 Mon, 2022-03-28 at 11:48 +0200, Johannes Berg wrote: > > However, this basically means that the direction argument to the flush > APIs are completely useless, and we do have to define something > new/else... > No I worded that badly - the direction isn't useless, but thinking of it in terms of a buffer property rather than data movement is inaccurate. So then if we need something else to indicate how data was expected to be moved, the direction argument becomes useless, since it's not a buffer property but rather a temporal thing on a specific place that expected certain data movement. 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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 81AA1C433EF for ; Mon, 28 Mar 2022 09:51:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1893B82C21; Mon, 28 Mar 2022 09:51:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7oNAHdY22h1; Mon, 28 Mar 2022 09:51:12 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 12C6782C7C; Mon, 28 Mar 2022 09:51:12 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id D6F66C001D; Mon, 28 Mar 2022 09:51:11 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id ACCCFC0012 for ; Mon, 28 Mar 2022 09:51:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A73534062A for ; Mon, 28 Mar 2022 09:51:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=sipsolutions.net 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 e1tXaow5rE0n for ; Mon, 28 Mar 2022 09:51:09 +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 smtp2.osuosl.org (Postfix) with ESMTPS id C0AD4404B4 for ; Mon, 28 Mar 2022 09:51:09 +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=nJO5E5YD857Be4i83ypHN59i/VCIHMrXJalTXZF8ChM=; t=1648461069; x=1649670669; b=C05y9be4r1d/3L6NqqZFyYj52dYAFACJYDaB6ts5vEaDQDp D9Zg59Tpl+r4IzEJq5sLQaLX3cEIkrTJi40xM60dccElUJXhzOx7Tizj9AFi8CoTGoVzHPELU3Hai Q835EpOHBgSln4HUo9Sf4+9pRof4kG8EZpL62DZPCLUKpylBtKZDwjgia2iFccmw6UF+BLfkLtA59 MLX0RjyIfhYbX3o/J110PHMOD4JoGw9Sb3qrTKB0MxBTaAnUdAbC5AsCNeoWTT0JFyIDLplD8TS2L PG/tEcspmTcGclxxYCY5SEPkbWx9rqNPAVYgIljkYLDKUw1P4YRSTfpU14UBrBsA==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1nYm1Y-001X37-2H; Mon, 28 Mar 2022 11:50:56 +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:50:54 +0200 In-Reply-To: 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 Mon, 2022-03-28 at 11:48 +0200, Johannes Berg wrote: > > However, this basically means that the direction argument to the flush > APIs are completely useless, and we do have to define something > new/else... > No I worded that badly - the direction isn't useless, but thinking of it in terms of a buffer property rather than data movement is inaccurate. So then if we need something else to indicate how data was expected to be moved, the direction argument becomes useless, since it's not a buffer property but rather a temporal thing on a specific place that expected certain data movement. johannes _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu