Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp788445pxb; Wed, 15 Sep 2021 13:14:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQ1lMXJwyzuPIfn4EOi6lKX/wAIvAF2BS7QEkNBXhW6VtTL9lKIvjiYFDTD9sI1ORhCuMC X-Received: by 2002:a05:6402:34c6:: with SMTP id w6mr1992901edc.97.1631736888724; Wed, 15 Sep 2021 13:14:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631736888; cv=none; d=google.com; s=arc-20160816; b=jM4H2oOSMQ+VHi37i4t+jpWqjHJj7qRjFzPCnq2LvnmImHekaZ0GfGVnyWwRyiRtT5 oMQLUSAJ1LJx2eRGUurjSq801zGZwPOp5QKG3p31usCH83VyZ6kFx7B99/hyRFkdWIR+ vDDCc5G+Ok+iUC4t7CjHufO/srUUX/lvdYYo36lffQS3otYJGIFD8Xo2q+nZkt23q25L KsyykuB61pI8xX0yRdNpkiPM1p0OJ4SPa+PjK+4Z65NsxqT2Ue2oNyBUxPJbkCH1UTBJ EbNWdnNE+3wzGyngFi6ysoI/piCUGnrYqyjRLv9pMIQTBvQQLf0ifUlUDfG6PBIpNbfL 9iQg== 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=+F4Z+9KZo5iEPfZH/RpdDwSxez6kFp3yf5p6nThg4cY=; b=p357TCeMJXZSph/mLBW8YvXzvBJwM/Vzq3Pb/vsGAbjtHrbzkB0LxtBhjVCkw2Oxe/ sCWBx8aIelysUpfRkp0k633ED5UXXY1kiFNDUGTvekiA6aYemX66WWjwXS4wFg/OYk5C TpkfQDCGxzj9zIsKk/xOkpT3hQj8c34jmO2Mhw8Jt+9qHYXeCvyQl5v/rfdXv4He7zzp LTHSSAYVZf63YH+UD1ffuMiwiOrr95Edy/GIiZQ6Y6+jVZ4UlfsHuXC+AS+lAJSws8pQ oEK384SBjtbE3VPYwAOIaimNsWhEj4um7RUh0SYyyk/hPbKpcwSoSaze8Y83K2zTXGMd S0lg== 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 x8si1266843edd.9.2021.09.15.13.14.24; Wed, 15 Sep 2021 13:14:48 -0700 (PDT) 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 S231562AbhIOUOX (ORCPT + 99 others); Wed, 15 Sep 2021 16:14:23 -0400 Received: from foss.arm.com ([217.140.110.172]:58648 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231487AbhIOUOW (ORCPT ); Wed, 15 Sep 2021 16:14:22 -0400 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 BCD926D; Wed, 15 Sep 2021 13:13:02 -0700 (PDT) Received: from [10.57.15.112] (unknown [10.57.15.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5518B3F59C; Wed, 15 Sep 2021 13:13:01 -0700 (PDT) Subject: Re: [PATCH] ACPI/IORT: Add 'smmu=off' command line option To: Yao Hongbo Cc: zhangliguang@linux.alibaba.com, alikernel-developer@linux.alibaba.com, will@kernel.org, lorenzo.pieralisi@arm.com, guohanjun@huawei.com, sudeep.holla@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20210915120046.62936-1-yaohongbo@linux.alibaba.com> From: Robin Murphy Message-ID: Date: Wed, 15 Sep 2021 21:12:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210915120046.62936-1-yaohongbo@linux.alibaba.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-09-15 13:00, Yao Hongbo wrote: > Add a generic command line option to disable arm smmu drivers. > iommu.passthrough can only bypass the IOMMU for DMA, but > sometimes we need to ignore all available SMMUs. Please elaborate on "sometimes" - what's the use-case for this which can't already be achieved by other means like module_blacklist, switching kernel images, ACPI table overrides, and so on? > This patch is only used for acpi on arm64. And yet the documentation implies that it works for all arm64 systems :/ And furthermore, why? If it's genuinely useful to disable SMMUs on ACPI-based systems, surely it must be equally useful to disable SMMUs on DT-based systems? > Signed-off-by: Yao Hongbo > --- > Documentation/admin-guide/kernel-parameters.txt | 4 ++++ > drivers/acpi/arm64/iort.c | 18 +++++++++++++++++- > 2 files changed, 21 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 91ba391f..6cffd91 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5198,6 +5198,10 @@ > smart2= [HW] > Format: [,[,...,]] > > + smmu= [ARM64] > + Format: {off} > + off: Disable arm smmu driver. There are at least two Arm SMMU drivers; as a user I might be wondering about the ambiguity there. > + > smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices > smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port > smsc-ircc2.ircc_sir= [HW] SIR base I/O port > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index 3b23fb7..70f92e7 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -40,6 +40,22 @@ struct iort_fwnode { > static LIST_HEAD(iort_fwnode_list); > static DEFINE_SPINLOCK(iort_fwnode_lock); > > +static bool acpi_smmu_disabled; > + > +static int __init acpi_smmu_parse(char *str) > +{ > + if (!str) > + return -EINVAL; > + > + if (!strncmp(str, "off", 3)) { > + acpi_smmu_disabled = true; > + pr_info("SMMU disabled\n"); > + } > + > + return 0; > +} > +__setup("smmu=", acpi_smmu_parse); > + > /** > * iort_set_fwnode() - Create iort_fwnode and use it to register > * iommu data in the iort_fwnode_list > @@ -1596,7 +1612,7 @@ static void __init iort_init_platform_devices(void) > iort_enable_acs(iort_node); > > ops = iort_get_dev_cfg(iort_node); > - if (ops) { > + if (ops && !acpi_smmu_disabled) { This will also effectively disable PMCGs, which is an undocumented side-effect, and not necessarily desirable - PMCG functionality is largely orthogonal, and may potentially be used to monitor traffic even when the associated SMMU instance is disabled. TBH there's really nothing SMMU-specific about this at all. I know I've had a number of debugging situations where it would have been handy to have a way to prevent a specific built-in driver from binding automatically during boot, so if you really have got a compelling reason to need it for SMMU, then you could still implement it generically in a way that everyone could benefit from. Thanks, Robin. > fwnode = acpi_alloc_fwnode_static(); > if (!fwnode) > return; >