Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7642800rdb; Thu, 4 Jan 2024 03:12:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IH0AoX8jHFVy72P3Ab1jFf/YkRvk17Csu0y3XuEt6mupu8rf2xvC7GA4mcRycy1wzKg4umq X-Received: by 2002:a05:6214:e64:b0:680:3ac:2415 with SMTP id jz4-20020a0562140e6400b0068003ac2415mr472906qvb.120.1704366761547; Thu, 04 Jan 2024 03:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704366761; cv=none; d=google.com; s=arc-20160816; b=wc7HLIo5ifunLDTSqCOCxchuocAvNEmBLmcuyS7mvBZ8fuXwj7NcR7OT8trn3cfvMi NYLMFt3eOJ5iIOxp+NIQ161CWL/QGhoh42E/9G0TBD6/DExT2PzA2YSTMmNbSQREL79G KqBfcXYGvp2bEAfU/qodHmbEPYCnjwn92DoU7v1qF2azSJJut3goKxebnTS29znEIYtC q4w73La8MpqPqG8tE6erAshDAFp0951ZcT9YeBb6+irWWlQCLRL2JlWwHj/vKELCAM0+ ZNJd9GH8haevaLEl8Nb+jc7MSS1fNbfZ5jglXdZuIElpcQ+AvMghCSlvDhuFBthXRhTp gb+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date:dkim-signature; bh=7xfnyeElrexA0N3ydLBuxmf9xc1UusNTPtI1Jg6GcSU=; fh=nqCAEgswBK1U9iwPhscgUX0IxdupzXoW0ixSwhUY1RU=; b=bYsdsQHpIQR2YhFsSRLUWlkwQiv8ssA8pyUKf6tALBJUYcux4zoawgWXObNnOcsFhf 1Mca9cMgKGFL5pzSyBEmvoaHkcyKhbMuCoFhdE+nzRrsATzw0jNFAuXGy3n5FjOaAu7P JiK2UNUcrLOhZrN/7pUCczsHhDvlS/eWFjdKuTbmnXJ5KLpX+1e4R+0/kndhMIjXGPFg C/c47Wv+9mgRvYE/TxEuPd3cn4KSY8ugzXAQIAgZCrIhMizhp5AV7WutxdvXgGgjGqdb g5RjuyR+gQ5HVnjY3yoP3/eEXDwuiY4KkFxuV6CRI7X9unHIus3eYQiBD+2RjSLmd1mM 9Xwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="r1G5Uiv/"; spf=pass (google.com: domain of linux-kernel+bounces-16567-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16567-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id t3-20020a0ce2c3000000b0067f0aa02082si31363017qvl.268.2024.01.04.03.12.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 03:12:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16567-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="r1G5Uiv/"; spf=pass (google.com: domain of linux-kernel+bounces-16567-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16567-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id EF25E1C2128F for ; Thu, 4 Jan 2024 11:12:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A2015210F2; Thu, 4 Jan 2024 11:12:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r1G5Uiv/" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D05B1210E8; Thu, 4 Jan 2024 11:12:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BD4DC433C8; Thu, 4 Jan 2024 11:12:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704366751; bh=ZTYlcyfMaa3S3C+3fVCkNuI7tbLxpzFHsI1DErMHbmc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=r1G5Uiv/WQdfy8fNqdt5yEW68k/doK+XAT06xU5w251XH5yBWIvyIQEGq5mbOzTCV Qe3pPsj5P3o3Q6xdXjyhek3InYKVDQv2GMnfpJ9+AjmTpAS2X9nUQ85MJYQQL5mmYL DSqbMfsnlsm6tPJu1SxRriSpbVe6vjKJ+Xa/7mQBIvrH/gYEbOKezsLLU6Es9zmLiu aKv7DGe0fe5fbH0KZ1p1wnU5WI3S/6KLsJll9/dTRyiszw8mj9+1GfQvXwpStlXDvD jF/oP061KaATAIWn+Ypih4EMcXTyMQEQZjSIJYnKjpUhUMOPUMolKwQCkKQ973wXwV /EwLAWI+kdR3g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rLLeG-008mAO-SY; Thu, 04 Jan 2024 11:12:29 +0000 Date: Thu, 04 Jan 2024 11:12:28 +0000 Message-ID: <86il499wtf.wl-maz@kernel.org> From: Marc Zyngier To: Lorenzo Pieralisi Cc: linux-kernel@vger.kernel.org, Robin Murphy , Mark Rutland , "Rafael J. Wysocki" , linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev, Fang Xiang , Robert Moore Subject: Re: [PATCH v4 3/3] irqchip/gic-v3: Enable non-coherent redistributors/ITSes ACPI probing In-Reply-To: <20231227110038.55453-4-lpieralisi@kernel.org> References: <20230905104721.52199-1-lpieralisi@kernel.org> <20231227110038.55453-1-lpieralisi@kernel.org> <20231227110038.55453-4-lpieralisi@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: lpieralisi@kernel.org, linux-kernel@vger.kernel.org, robin.murphy@arm.com, mark.rutland@arm.com, rafael@kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev, fangxiang3@xiaomi.com, robert.moore@intel.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 27 Dec 2023 11:00:38 +0000, Lorenzo Pieralisi wrote: > > The GIC architecture specification defines a set of registers > for redistributors and ITSes that control the sharebility and > cacheability attributes of redistributors/ITSes initiator ports > on the interconnect (GICR_[V]PROPBASER, GICR_[V]PENDBASER, > GITS_BASER). > > Architecturally the GIC provides a means to drive shareability > and cacheability attributes signals and related IWB/OWB/ISH barriers IWB/OWB *barriers*? Unless you're talking about something else, IWB/OWB refers to cacheability, and only that. > but it is not mandatory for designs to wire up the corresponding > interconnect signals that control the cacheability/shareability > of transactions. > > Redistributors and ITSes interconnect ports can be connected to > non-coherent interconnects that are not able to manage the > shareability/cacheability attributes; this implicitly makes > the redistributors and ITSes non-coherent observers. > > So far, the GIC driver on probe executes a write to "probe" for > the redistributors and ITSes registers shareability bitfields > by writing a value (ie InnerShareable - the shareability domain the > CPUs are in) and check it back to detect whether the value sticks or > not; this hinges on a GIC programming model behaviour that predates the > current specifications, that just define shareability bits as writeable > but do not guarantee that writing certain shareability values > enable the expected behaviour for the redistributors/ITSes > memory interconnect ports. > > To enable non-coherent GIC designs on ACPI based systems, parse the MADT > GICC/GICR/ITS subtables non-coherent flags to determine whether the > respective components are non-coherent observers and force the shareability > attributes to be programmed into the redistributors and ITSes registers. > > An ACPI global function (acpi_get_madt_revision()) is added to retrieve > the MADT revision, in that it is essential to check the MADT revision > before checking for flags that were added with MADT revision 7 so that > if the kernel is booted with ACPI tables (MADT rev < 7) it skips parsing > the newly added flags (that should be zeroed reserved values for MADT > versions < 7 but they could turn out to be buggy and should be ignored). > > Signed-off-by: Lorenzo Pieralisi > Cc: Robin Murphy > Cc: Mark Rutland > Cc: "Rafael J. Wysocki" > Cc: Marc Zyngier > --- > drivers/acpi/processor_core.c | 21 +++++++++++++++++++++ > drivers/irqchip/irq-gic-common.h | 8 ++++++++ > drivers/irqchip/irq-gic-v3-its.c | 4 ++++ > drivers/irqchip/irq-gic-v3.c | 9 +++++++++ > include/linux/acpi.h | 3 +++ > 5 files changed, 45 insertions(+) > > diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c > index b203cfe28550..c253d151275e 100644 > --- a/drivers/acpi/processor_core.c > +++ b/drivers/acpi/processor_core.c > @@ -215,6 +215,27 @@ phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id) > return rv; > } > > +u8 __init acpi_get_madt_revision(void) > +{ > + static u8 madt_revision __initdata; > + static bool madt_read __initdata; > + struct acpi_table_header *madt = NULL; > + > + if (!madt_read) { > + madt_read = true; Huh. Why do we need this hack? What's the issue with accessing the MADT? Can it disappear from under our feet? While we're walking it? > + > + acpi_get_table(ACPI_SIG_MADT, 0, &madt); > + if (!madt) > + return madt_revision; What does this mean? Can we have a revision 0 of MADT? > + > + madt_revision = madt->revision; > + > + acpi_put_table(madt); > + } > + > + return madt_revision; > +} > + > static phys_cpuid_t map_mat_entry(acpi_handle handle, int type, u32 acpi_id) > { > struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; > diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h > index f407cce9ecaa..8dffee95f7e8 100644 > --- a/drivers/irqchip/irq-gic-common.h > +++ b/drivers/irqchip/irq-gic-common.h > @@ -6,6 +6,7 @@ > #ifndef _IRQ_GIC_COMMON_H > #define _IRQ_GIC_COMMON_H > > +#include > #include > #include > #include > @@ -29,6 +30,13 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks, > void gic_enable_of_quirks(const struct device_node *np, > const struct gic_quirk *quirks, void *data); > > +#ifdef CONFIG_ACPI > +static inline bool gic_acpi_non_coherent_flag(u32 flags, u32 mask) > +{ > + return (acpi_get_madt_revision() >= 7) && (flags & mask); > +} Given that this checks *any* flag (or a combination of flags), the name of the helper is extremely misleading. Also, GICC flags are not necessarily tied to revision 7 of MADT. To be honest, I don't think this helper bring much, and I'd rather see an explicit check (or 3) for the revision in the driver code. > +#endif > + > #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0) > #define RDIST_FLAGS_RD_TABLES_PREALLOCATED (1 << 1) > #define RDIST_FLAGS_FORCE_NON_SHAREABLE (1 << 2) > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 9a7a74239eab..8d088fca65a1 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -5578,6 +5578,10 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header, > goto node_err; > } > > + if (gic_acpi_non_coherent_flag(its_entry->flags, > + ACPI_MADT_ITS_NON_COHERENT)) > + its->flags |= ITS_FLAGS_FORCE_NON_SHAREABLE; > + > err = its_probe_one(its); > if (!err) > return 0; > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 98b0329b7154..48e02838fdc8 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2356,6 +2356,11 @@ gic_acpi_parse_madt_redist(union acpi_subtable_headers *header, > pr_err("Couldn't map GICR region @%llx\n", redist->base_address); > return -ENOMEM; > } > + > + if (gic_acpi_non_coherent_flag(redist->flags, > + ACPI_MADT_GICR_NON_COHERENT)) > + gic_data.rdists.flags |= RDIST_FLAGS_FORCE_NON_SHAREABLE; > + > gic_request_region(redist->base_address, redist->length, "GICR"); > > gic_acpi_register_redist(redist->base_address, redist_base); > @@ -2380,6 +2385,10 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header, > return -ENOMEM; > gic_request_region(gicc->gicr_base_address, size, "GICR"); > > + if (gic_acpi_non_coherent_flag(gicc->flags, > + ACPI_MADT_GICC_NON_COHERENT)) > + gic_data.rdists.flags |= RDIST_FLAGS_FORCE_NON_SHAREABLE; > + > gic_acpi_register_redist(gicc->gicr_base_address, redist_base); > return 0; > } > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 54189e0e5f41..a292f2bdb693 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -283,6 +283,9 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id) > return phys_id == PHYS_CPUID_INVALID; > } > > + > +u8 __init acpi_get_madt_revision(void); > + > /* Validate the processor object's proc_id */ > bool acpi_duplicate_processor_id(int proc_id); > /* Processor _CTS control */ Thanks, M. -- Without deviation from the norm, progress is not possible.