Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3238380ybg; Mon, 28 Oct 2019 09:35:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqzSIBkir1ucAyjJQuSFZRJNqbAfWqy6VZaTVaqmtMpPRLgojfaKS6qE2PrkUvbcJ6xQbLmB X-Received: by 2002:a05:6402:304c:: with SMTP id bu12mr19908608edb.230.1572280500940; Mon, 28 Oct 2019 09:35:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572280500; cv=none; d=google.com; s=arc-20160816; b=YQG079/EKEUT2LpFQ58t8lJ11L2LEfou5xzCEvIZ3t6FLGiCCTlEJBnLvexolWvkMW VZlIUkt9/rsJzaSaRh1PQI9rv61SEYbbjcO1U9g+Q1nZnM4BsUBeq0da4E8roBPkdzKI iKF72lJN64Aesi+OEiANH0eFwpu5kbS63muSw/hj6rb2jwDWm+6RB2ZG8SV7KYPyB22N Jf9RoWgulig9FmEtOdjosbWra89jcscshGovwrGpSCdI2vb65ujpBoRyLhmm6r/voKVF +YvrzbmZSu6bnPR2bFvUbQuL8vi4ZJHdolmkuR7kGfJQlhLP80HjfEu5nxvC8u/qtw3S sHHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=765UUP5m/P8bFKmpPe6pBKG9C/NPUgaW457b9otHS7c=; b=fCQdk003y2/Duc23ZPZPK98qIuBnPJFHxb+SfaCVoZKY3deIdz2XPo5FIYa3FiJBkN INYt5rdnzNynfsQD/fsInl5Z6s1O8/qPZrW+Jw11w6TRQTeHU6PXsIshcahkGzST2hTu +gjSU3r4MZSVlFJ7UoBWHLG4clTJqe0mWRi6UTRWnZtHfYvc9YV9nXnKOIN/ux0kNSNg ljrIDhdyi7H/LEDnS2uXw/UoHacxl6xD9m2/RMP+QPOEulv0yz8NRQkFqTrNbIaujfE4 L0x699CqGaMgKxHo1GCHRIyAbMyuNaoU+secBVtPdfb7H2oqBoy/WsKsEFDCekTWpK9J SRSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7si8181101edc.342.2019.10.28.09.34.37; Mon, 28 Oct 2019 09:35:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733022AbfJ1Hl7 (ORCPT + 99 others); Mon, 28 Oct 2019 03:41:59 -0400 Received: from verein.lst.de ([213.95.11.211]:33125 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730952AbfJ1Hl7 (ORCPT ); Mon, 28 Oct 2019 03:41:59 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 5AF8668C65; Mon, 28 Oct 2019 08:41:56 +0100 (CET) Date: Mon, 28 Oct 2019 08:41:56 +0100 From: Christoph Hellwig To: isaacm@codeaurora.org Cc: Christoph Hellwig , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, joro@8bytes.org, m.szyprowski@samsung.com, robin.murphy@arm.com, will@kernel.org, pratikp@codeaurora.org, lmark@codeaurora.org Subject: Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE Message-ID: <20191028074156.GB20443@lst.de> References: <1572050616-6143-1-git-send-email-isaacm@codeaurora.org> <20191026053026.GA14545@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 26, 2019 at 03:12:57AM -0700, isaacm@codeaurora.org wrote: > On 2019-10-25 22:30, Christoph Hellwig wrote: >> The definition makes very little sense. > Can you please clarify what part doesn’t make sense, and why? It looks like complete garbage to me. That might just be because it uses tons of terms I've never heard of of and which aren't used anywhere in the DMA API. It also might be because it doesn't explain how the flag might actually be practically useful. > This is > really just an extension of this patch that got mainlined, so that clients > that use the DMA API can use IOMMU_QCOM_SYS_CACHE as well: > https://patchwork.kernel.org/patch/10946099/ >> Any without a user in the same series it is a complete no-go anyway. > IOMMU_QCOM_SYS_CACHE does not have any current users in the mainline, nor > did it have it in the patch series in which it got merged, yet it is still > present? Furthermore, there are plans to upstream support for one of our > SoCs that may benefit from this, as seen here: > https://www.spinics.net/lists/iommu/msg39608.html. Which means it should have never been merged. As a general policy we do not add code to the Linux kernel without actual users.