Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp47795pxb; Tue, 12 Jan 2021 19:38:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJwPoz7TJmyX0z7g3paGzbqy8AeGAUgx5bV6V+MvGLS2WnkZSRlt0LLq6/ld/CICRWNoLKm4 X-Received: by 2002:a17:906:ce51:: with SMTP id se17mr98441ejb.314.1610509134639; Tue, 12 Jan 2021 19:38:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610509134; cv=none; d=google.com; s=arc-20160816; b=YT2M0jti4sFgqY2w7fqI52nZgM/d+nEBqIkDWvlbKrA/BtMWSzDUqgtYCC/SZRxSiN k5JatFvGyFzkc15eOPVgJLad5a5IMykZz+6CuIt4A5BQw6/dhwNqVAaBBN/x3rCq+UK2 fLVrwP4oJbvDHJJl/u9srT8F/r7lUttw8mL6F7bMjHKLv+IKQEmCOvQdN+doDvPV00kv 3UuwJuyDrYcLlFb77Ur3oB1abUixMyOC4CAItkqdgpLxgkrMC/X0YQuL9gFMKwt+QeCh ovAlvXtXOYr+rkelH28RRGVdOxeytHIiLG0K1SyGzLC94Qd1lwmm71U4MVRemQHayM/6 MQYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ZvRBK1U9gWCZpr+bKCYLCrCxrQH/BTbKklQ4t2gcRuk=; b=PUFXIMliyvICHL2MFSQVQonIxPrmLif/mTHOi/NjImlT8bYwo3U71EOk0GPFvuKqRt 5GibwhK6x1e/tr/xltniJe+RLa+s6urjBrDT6hMl2a3jNmBf5M0Znn5UUK122XVB6zik YWBKJJ8UF/ywOlq44LBTB8y5BAO98FCDrn+d8SA3jNIAtgL5/+mnORmHHoNTuDGgVkM9 dg+rcceyODbhiC07VI5h0VNaXo3Lmg3uHiMbaGPfA7I4RqAFtsrSpA3fApcA4rNb6aJ0 JtrXNuP23UcDw69jbGZw5fMhUs9qzrDvH0OgE8hVZWqXE5MvrpSvammka211uLc1vSdr tguA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lw27si351906ejb.35.2021.01.12.19.38.31; Tue, 12 Jan 2021 19:38:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727117AbhAMBx4 (ORCPT + 99 others); Tue, 12 Jan 2021 20:53:56 -0500 Received: from foss.arm.com ([217.140.110.172]:56656 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbhAMBxz (ORCPT ); Tue, 12 Jan 2021 20:53:55 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E760101E; Tue, 12 Jan 2021 17:53:09 -0800 (PST) Received: from [10.57.56.43] (unknown [10.57.56.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2E913F719; Tue, 12 Jan 2021 17:53:03 -0800 (PST) Subject: Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool To: Konrad Rzeszutek Wilk , Claire Chang Cc: Rob Herring , mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org, "list@263.net:IOMMU DRIVERS" , Joerg Roedel , joro@8bytes.org, will@kernel.org, Frank Rowand , boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org, Christoph Hellwig , Marek Szyprowski , grant.likely@arm.com, xypron.glpk@gmx.de, Thierry Reding , mingo@kernel.org, bauerman@linux.ibm.com, peterz@infradead.org, Greg KH , Saravana Kannan , rafael.j.wysocki@intel.com, heikki.krogerus@linux.intel.com, Andy Shevchenko , rdunlap@infradead.org, dan.j.williams@intel.com, Bartosz Golaszewski , linux-devicetree , lkml , linuxppc-dev@lists.ozlabs.org, "list@263.net:IOMMU DRIVERS" , Joerg Roedel , iommu@lists.linux-foundation.org, xen-devel@lists.xenproject.org, Tomasz Figa , Nicolas Boichat References: <20210106034124.30560-1-tientzu@chromium.org> <20210106034124.30560-3-tientzu@chromium.org> <20210106185241.GA109735@localhost.localdomain> <20210107175740.GA16519@char.us.oracle.com> From: Robin Murphy Message-ID: <41b466d0-0271-2d84-0623-4c877fcffe32@arm.com> Date: Wed, 13 Jan 2021 01:53:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210107175740.GA16519@char.us.oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-07 17:57, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote: >> Hi Greg and Konrad, >> >> This change is intended to be non-arch specific. Any arch that lacks DMA access >> control and has devices not behind an IOMMU can make use of it. Could you share >> why you think this should be arch specific? > > The idea behind non-arch specific code is it to be generic. The devicetree > is specific to PowerPC, Sparc, and ARM, and not to x86 - hence it should > be in arch specific code. Sorry, but that's an absurd argument. By the same token you'd equally have to claim that bits of, say, the Broadcom WiFi driver (not to mention dozens of others) should be split out into arch code, since not all platforms use the devicetree parts, nor the ACPI parts, nor the PCI parts... There is nothing architecture-specific about using devicetree as a system description - AFAIK there *are* a handful of x86 platforms that use it, besides even more architectures than you've listed above. It has long been the policy that devicetree-related code for a particular subsystem should just live within that subsystem. Sometimes if there's enough of it it gets collected together into its own file - e.g. drivers/pci/of.c - otherwise it tends to just get #ifdef'ed - e.g. of_spi_parse_dt(), or the other DMA reserved-memory consumers that already exist as Florian points out. Besides, there are far more platforms that enable CONFIG_OF than enable CONFIG_SWIOTLB, so by that metric the whole of the SWIOTLB code itself is even less "generic" than any DT parsing :P Robin.