From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 5B67E145B10; Mon, 22 Apr 2024 10:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713782363; cv=none; b=ELBhBsI1X6Gm/FcwuzJOYNsBw+KaF65ViajQBjb+Xq0jJAyoN+g96uzxRtTpOt9VTu9nqu9bNch1u60i9mu9w07/5sG+LdDnCm39GJBG3LDSsgNU1LSKi80fDasvWo27FY0s3+q98R/tekM6Ef3TJ8z5AqVyrmzhjgQHABDFYcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713782363; c=relaxed/simple; bh=JqE3ylYWKarL5FDsaFXHHjgdDBTPGkxZWyvz1pBSwRY=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HlsEwhNn0H3WbeX4EvqEUjY8+4ebAzISurwyUcSE8gsxqEYx2G+Jh+bt5nX8Il0tzbsbKhRJQ3Gz179nx3QgaJOQJ+eP1v+bUc6MJT0N/XjExfGWKYjO5tTyZtobIvDu0MsfPGLytbZ3bbFWN0ogf6r6AViwzxmKOd17SxhzeBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VNMBM0NFfz6JBRQ; Mon, 22 Apr 2024 18:36:59 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 928E1140CB1; Mon, 22 Apr 2024 18:39:12 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 22 Apr 2024 11:39:11 +0100 Date: Mon, 22 Apr 2024 11:39:10 +0100 From: Jonathan Cameron To: Thomas Gleixner , Peter Zijlstra , , , , , , , , , Russell King , "Rafael J . Wysocki" , Miguel Luis , "James Morse" , Salil Mehta , Jean-Philippe Brucker , Catalin Marinas , Will Deacon , CC: Ingo Molnar , Borislav Petkov , "Dave Hansen" , , , Marc Zyngier Subject: Re: [PATCH v7 10/16] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Message-ID: <20240422113839.00000cde@huawei.com> In-Reply-To: <20240418135412.14730-11-Jonathan.Cameron@huawei.com> References: <20240418135412.14730-1-Jonathan.Cameron@huawei.com> <20240418135412.14730-11-Jonathan.Cameron@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500005.china.huawei.com (7.191.163.240) On Thu, 18 Apr 2024 14:54:06 +0100 Jonathan Cameron wrote: > From: James Morse > > 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 will > complicate 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 > Reviewed-by: Gavin Shan > Signed-off-by: Russell King (Oracle) > Reviewed-by: Jonathan Cameron > Signed-off-by: Jonathan Cameron I've been focused on the ACPI aspects until now, but now realize that this and the next patch should have included the GIC maintainer in the to list. I'll fix that for future versions, but for now +CC Marc. > --- > v7: No change > --- > drivers/irqchip/irq-gic-v3.c | 13 ++----------- > 1 file changed, 2 insertions(+), 11 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 6fb276504bcc..10af15f93d4d 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2415,19 +2415,10 @@ 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 > */ > - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > + if (acpi_gicc_is_usable(gicc) && 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) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A7767C4345F for ; Mon, 22 Apr 2024 10:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+N3nd6HvqcjCN/FTzstd8/yrwawm3uCvCMIJ+rNzkuM=; b=ewOljSEyQqt4Ph JghK+Ki8v0tQnTCsTfkShqgmb3Md89kGXbEadl+yipWHIl5EBQef318UPXRypxr+3bIE1IF78YDjg rjZ+w6oYeJzoQOZWtwCN4KK22/5Bqdm8+Qqs4lCUKCA/gHagcfKvASn7N7tEEzvu9rmtTla36WkCA 3sbMNqBeVwuSoNI68ulAKo+UCf+/Tb+fL7nuVgI4OPuAdWYQL4uTti114DJuBKzLaTEN24FVgYnyk XOCXv141WG8C5diEHWU7KKDCTQhxEcM06qsq2ylh2Zz9xo6eSrCTMCzq0ZXqOu4MoRoBAcsHpoBfO bkYLq/KxYQbQYVj5SjNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryr59-0000000DBs7-0EKS; Mon, 22 Apr 2024 10:39:31 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryr55-0000000DBnM-3sT0 for linux-arm-kernel@lists.infradead.org; Mon, 22 Apr 2024 10:39:29 +0000 Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VNMBM0NFfz6JBRQ; Mon, 22 Apr 2024 18:36:59 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 928E1140CB1; Mon, 22 Apr 2024 18:39:12 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 22 Apr 2024 11:39:11 +0100 Date: Mon, 22 Apr 2024 11:39:10 +0100 From: Jonathan Cameron To: Thomas Gleixner , Peter Zijlstra , , , , , , , , , Russell King , "Rafael J . Wysocki" , Miguel Luis , "James Morse" , Salil Mehta , Jean-Philippe Brucker , Catalin Marinas , Will Deacon , CC: Ingo Molnar , Borislav Petkov , "Dave Hansen" , , , Marc Zyngier Subject: Re: [PATCH v7 10/16] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Message-ID: <20240422113839.00000cde@huawei.com> In-Reply-To: <20240418135412.14730-11-Jonathan.Cameron@huawei.com> References: <20240418135412.14730-1-Jonathan.Cameron@huawei.com> <20240418135412.14730-11-Jonathan.Cameron@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240422_033928_299662_6D0C5BCE X-CRM114-Status: GOOD ( 26.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 18 Apr 2024 14:54:06 +0100 Jonathan Cameron wrote: > From: James Morse > > 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 will > complicate 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 > Reviewed-by: Gavin Shan > Signed-off-by: Russell King (Oracle) > Reviewed-by: Jonathan Cameron > Signed-off-by: Jonathan Cameron I've been focused on the ACPI aspects until now, but now realize that this and the next patch should have included the GIC maintainer in the to list. I'll fix that for future versions, but for now +CC Marc. > --- > v7: No change > --- > drivers/irqchip/irq-gic-v3.c | 13 ++----------- > 1 file changed, 2 insertions(+), 11 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 6fb276504bcc..10af15f93d4d 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -2415,19 +2415,10 @@ 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 > */ > - if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address) { > + if (acpi_gicc_is_usable(gicc) && 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) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel