Message ID | 20230913163823.7880-30-james.morse@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9ecd:0:b0:3f2:4152:657d with SMTP id t13csp1220146vqx; Wed, 13 Sep 2023 09:51:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6v31tH40ChOFvppWXpU/+Zl4Tnhxt7Tl3QWC4N6ncWWB+j0leXbkvQzUu7GzK1cihRwvG X-Received: by 2002:a17:902:f542:b0:1bd:dbec:8673 with SMTP id h2-20020a170902f54200b001bddbec8673mr9297133plf.11.1694623907598; Wed, 13 Sep 2023 09:51:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694623907; cv=none; d=google.com; s=arc-20160816; b=JSQeWW752TaZAZFyfFJDeitHo/BvtLi5Bg5kYP+Fm04uE+iHYDVskp0nLXOjawTgh9 eUC5bQKMTyT5BXZNed0WUVCV1ck4qu4SW/MJrJO/uhnmgOspKuHjMlwRbgnlsdqRtqvp VueoWQd6tjDbz2LbzwEELgGcEZZRc0nDbYbCgHCOh3krCy40b5ufUWuggUXPcP3QssIY nbxn0nVchFKS1WQxSC8NxRfhqglwLShi20iDHFkZrrJewX+HTrNu1jZjvWMIstAJaewq 0MX+YCJgXN2qWU600CJHsgKGqM/0X3rG2asU2E8USosvrecArb65/fG9SPdLhqTenIfg 1TVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=smaW/o8bd+rKbnDSaMbVWU9xJol1PXqasCCdXHQGEUg=; fh=2nhVWB0fZ+8YH0lLFpnF/Mo8eq+n1VMLe+b+IpvS0g0=; b=q3I5xKQZQrylkDIjTx8gXNPENoFrJhzsrWNpuNMYIU6TaPudDQYWYIGbiKvUkwLpoC yB2SWfoDCSZXe4Dq/PPO1wRbtM6pv65W3D0HWMZhy6bjkbYNlnZDEcuH7pnatDRkpVG9 EF1+gXuelH2kKxlowfm2uGWWGjn2emBSV/LrbAVpFMhW1yi9DCujlJlCXYCUSvm9aH/f 9KMyX+4GotUW8TGKAS1TBMfCFZMZpvXVcVFbHy5Ii+8YphvnKzCtygPVCGJFBSQFqC7r HYfuCG35uvv3A1YeL5GNJ6sbUaerN+ngMplYFkyiirWpfXlTSPser7LRovior4lrBwa/ /GUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id u2-20020a170902714200b001bee6def27dsi10126725plm.235.2023.09.13.09.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Sep 2023 09:51:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id C405C8057E5D; Wed, 13 Sep 2023 09:41:54 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231142AbjIMQlx (ORCPT <rfc822;pwkd43@gmail.com> + 35 others); Wed, 13 Sep 2023 12:41:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231273AbjIMQlE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Sep 2023 12:41:04 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6477A2733; Wed, 13 Sep 2023 09:39:51 -0700 (PDT) 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 505AE139F; Wed, 13 Sep 2023 09:40:28 -0700 (PDT) Received: from merodach.members.linode.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 55C453F5A1; Wed, 13 Sep 2023 09:39:49 -0700 (PDT) From: James Morse <james.morse@arm.com> To: linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, kvmarm@lists.linux.dev Cc: x86@kernel.org, Salil Mehta <salil.mehta@huawei.com>, Russell King <linux@armlinux.org.uk>, Jean-Philippe Brucker <jean-philippe@linaro.org>, jianyong.wu@arm.com, justin.he@arm.com Subject: [RFC PATCH v2 29/35] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Date: Wed, 13 Sep 2023 16:38:17 +0000 Message-Id: <20230913163823.7880-30-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230913163823.7880-1-james.morse@arm.com> References: <20230913163823.7880-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Sep 2023 09:41:54 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1776941958425613046 X-GMAIL-MSGID: 1776941958425613046 |
Series |
ACPI/arm64: add support for virtual cpuhotplug
|
|
Commit Message
James Morse
Sept. 13, 2023, 4:38 p.m. UTC
gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions().
It should only count the number of enabled redistributors, but it
also tries to sanity check the GICC entry, currently returning an
error if the Enabled bit is set, but the gicr_base_address is zero.
Adding support for the online-capable bit to the sanity check
complicates it, for no benefit. The existing check implicitly
depends on gic_acpi_count_gicr_regions() previous failing to find
any GICR regions (as it is valid to have gicr_base_address of zero if
the redistributors are described via a GICR entry).
Instead of complicating the check, remove it. Failures that happen
at this point cause the irqchip not to register, meaning no irqs
can be requested. The kernel grinds to a panic() pretty quickly.
Without the check, MADT tables that exhibit this problem are still
caught by gic_populate_rdist(), which helpfully also prints what
went wrong:
| CPU4: mpidr 100 has no re-distributor!
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/irqchip/irq-gic-v3.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
Comments
On Wed, 13 Sep 2023 16:38:17 +0000 James Morse <james.morse@arm.com> wrote: > gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions(). > It should only count the number of enabled redistributors, but it > also tries to sanity check the GICC entry, currently returning an > error if the Enabled bit is set, but the gicr_base_address is zero. > > Adding support for the online-capable bit to the sanity check > complicates it, for no benefit. The existing check implicitly > depends on gic_acpi_count_gicr_regions() previous failing to find > any GICR regions (as it is valid to have gicr_base_address of zero if > the redistributors are described via a GICR entry). > > Instead of complicating the check, remove it. Failures that happen > at this point cause the irqchip not to register, meaning no irqs > can be requested. The kernel grinds to a panic() pretty quickly. > > Without the check, MADT tables that exhibit this problem are still > caught by gic_populate_rdist(), which helpfully also prints what > went wrong: > | CPU4: mpidr 100 has no re-distributor! > > Signed-off-by: James Morse <james.morse@arm.com> > --- > drivers/irqchip/irq-gic-v3.c | 18 ++++++------------ > 1 file changed, 6 insertions(+), 12 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 72d3cdebdad1..0f54811262eb 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2415,21 +2415,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header, > > /* > * If GICC is enabled and has valid gicr base address, then it means > - * GICR base is presented via GICC > + * GICR base is presented via GICC. The redistributor is only known to > + * be accessible if the GICC is marked as enabled. If this bit is not > + * set, we'd need to add the redistributor at runtime, which isn't > + * supported. > */ > - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > + if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address) Going in circles... > acpi_data.enabled_rdists++; > - return 0; > - } > > - /* > - * It's perfectly valid firmware can pass disabled GICC entry, driver > - * should not treat as errors, skip the entry instead of probe fail. > - */ > - if (!acpi_gicc_is_usable(gicc)) > - return 0; > - > - return -ENODEV; > + return 0; > } > > static int __init gic_acpi_count_gicr_regions(void)
On 9/14/23 02:38, James Morse wrote: > gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions(). > It should only count the number of enabled redistributors, but it > also tries to sanity check the GICC entry, currently returning an > error if the Enabled bit is set, but the gicr_base_address is zero. > > Adding support for the online-capable bit to the sanity check > complicates it, for no benefit. The existing check implicitly > depends on gic_acpi_count_gicr_regions() previous failing to find > any GICR regions (as it is valid to have gicr_base_address of zero if > the redistributors are described via a GICR entry). > > Instead of complicating the check, remove it. Failures that happen > at this point cause the irqchip not to register, meaning no irqs > can be requested. The kernel grinds to a panic() pretty quickly. > > Without the check, MADT tables that exhibit this problem are still > caught by gic_populate_rdist(), which helpfully also prints what > went wrong: > | CPU4: mpidr 100 has no re-distributor! > > Signed-off-by: James Morse <james.morse@arm.com> > --- > drivers/irqchip/irq-gic-v3.c | 18 ++++++------------ > 1 file changed, 6 insertions(+), 12 deletions(-) > With below nits resolved: Reviewed-by: Gavin Shan <gshan@redhat.com> > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 72d3cdebdad1..0f54811262eb 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2415,21 +2415,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header, > > /* > * If GICC is enabled and has valid gicr base address, then it means > - * GICR base is presented via GICC > + * GICR base is presented via GICC. The redistributor is only known to > + * be accessible if the GICC is marked as enabled. If this bit is not > + * set, we'd need to add the redistributor at runtime, which isn't > + * supported. > */ > - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > + if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address) > acpi_data.enabled_rdists++; > - return 0; > - } > if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > - /* > - * It's perfectly valid firmware can pass disabled GICC entry, driver > - * should not treat as errors, skip the entry instead of probe fail. > - */ > - if (!acpi_gicc_is_usable(gicc)) > - return 0; > - > - return -ENODEV; > + return 0; > } > > static int __init gic_acpi_count_gicr_regions(void) Thanks, Gavin
On 9/19/23 13:39, Gavin Shan wrote: > > On 9/14/23 02:38, James Morse wrote: >> gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions(). >> It should only count the number of enabled redistributors, but it >> also tries to sanity check the GICC entry, currently returning an >> error if the Enabled bit is set, but the gicr_base_address is zero. >> >> Adding support for the online-capable bit to the sanity check >> complicates it, for no benefit. The existing check implicitly >> depends on gic_acpi_count_gicr_regions() previous failing to find >> any GICR regions (as it is valid to have gicr_base_address of zero if >> the redistributors are described via a GICR entry). >> >> Instead of complicating the check, remove it. Failures that happen >> at this point cause the irqchip not to register, meaning no irqs >> can be requested. The kernel grinds to a panic() pretty quickly. >> >> Without the check, MADT tables that exhibit this problem are still >> caught by gic_populate_rdist(), which helpfully also prints what >> went wrong: >> | CPU4: mpidr 100 has no re-distributor! >> >> Signed-off-by: James Morse <james.morse@arm.com> >> --- >> drivers/irqchip/irq-gic-v3.c | 18 ++++++------------ >> 1 file changed, 6 insertions(+), 12 deletions(-) >> > > With below nits resolved: > > Reviewed-by: Gavin Shan <gshan@redhat.com> > >> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c >> index 72d3cdebdad1..0f54811262eb 100644 >> --- a/drivers/irqchip/irq-gic-v3.c >> +++ b/drivers/irqchip/irq-gic-v3.c >> @@ -2415,21 +2415,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header, >> /* >> * If GICC is enabled and has valid gicr base address, then it means >> - * GICR base is presented via GICC >> + * GICR base is presented via GICC. The redistributor is only known to >> + * be accessible if the GICC is marked as enabled. If this bit is not >> + * set, we'd need to add the redistributor at runtime, which isn't >> + * supported. >> */ >> - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { >> + if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address) >> acpi_data.enabled_rdists++; >> - return 0; >> - } > > if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > Please ignore this since acpi_gicc_is_usable() is changed to cover the bit ACPI_MADT_GICC_CPU_CAPABLE in next patch, which means "(gicc->flags & ACPI_MADT_ENABLED)" is needed here. > >> - /* >> - * It's perfectly valid firmware can pass disabled GICC entry, driver >> - * should not treat as errors, skip the entry instead of probe fail. >> - */ >> - if (!acpi_gicc_is_usable(gicc)) >> - return 0; >> - >> - return -ENODEV; >> + return 0; >> } >> static int __init gic_acpi_count_gicr_regions(void) Thanks, Gavin
On Thu, Sep 14, 2023 at 04:02:23PM +0100, Jonathan Cameron wrote: > On Wed, 13 Sep 2023 16:38:17 +0000 > James Morse <james.morse@arm.com> wrote: > > > gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions(). > > It should only count the number of enabled redistributors, but it > > also tries to sanity check the GICC entry, currently returning an > > error if the Enabled bit is set, but the gicr_base_address is zero. > > > > Adding support for the online-capable bit to the sanity check > > complicates it, for no benefit. The existing check implicitly > > depends on gic_acpi_count_gicr_regions() previous failing to find > > any GICR regions (as it is valid to have gicr_base_address of zero if > > the redistributors are described via a GICR entry). > > > > Instead of complicating the check, remove it. Failures that happen > > at this point cause the irqchip not to register, meaning no irqs > > can be requested. The kernel grinds to a panic() pretty quickly. > > > > Without the check, MADT tables that exhibit this problem are still > > caught by gic_populate_rdist(), which helpfully also prints what > > went wrong: > > | CPU4: mpidr 100 has no re-distributor! > > > > Signed-off-by: James Morse <james.morse@arm.com> > > --- > > drivers/irqchip/irq-gic-v3.c | 18 ++++++------------ > > 1 file changed, 6 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > > index 72d3cdebdad1..0f54811262eb 100644 > > --- a/drivers/irqchip/irq-gic-v3.c > > +++ b/drivers/irqchip/irq-gic-v3.c > > @@ -2415,21 +2415,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header, > > > > /* > > * If GICC is enabled and has valid gicr base address, then it means > > - * GICR base is presented via GICC > > + * GICR base is presented via GICC. The redistributor is only known to > > + * be accessible if the GICC is marked as enabled. If this bit is not > > + * set, we'd need to add the redistributor at runtime, which isn't > > + * supported. > > */ > > - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > > + if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address) > > Going in circles... It does seem that way. Are you suggesting something should change here? Thanks.
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 72d3cdebdad1..0f54811262eb 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -2415,21 +2415,15 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header, /* * If GICC is enabled and has valid gicr base address, then it means - * GICR base is presented via GICC + * GICR base is presented via GICC. The redistributor is only known to + * be accessible if the GICC is marked as enabled. If this bit is not + * set, we'd need to add the redistributor at runtime, which isn't + * supported. */ - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { + if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address) acpi_data.enabled_rdists++; - return 0; - } - /* - * It's perfectly valid firmware can pass disabled GICC entry, driver - * should not treat as errors, skip the entry instead of probe fail. - */ - if (!acpi_gicc_is_usable(gicc)) - return 0; - - return -ENODEV; + return 0; } static int __init gic_acpi_count_gicr_regions(void)