Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp3711622rdg; Wed, 18 Oct 2023 04:01:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE2RSZ3A8ln2u4SjJQqtltu2oFtAPrC+eIMjbS49qbTOjWIVAGA7KQoNV3Pk1uDYx3FeppI X-Received: by 2002:a17:903:230a:b0:1c7:3558:721a with SMTP id d10-20020a170903230a00b001c73558721amr5624342plh.58.1697626914458; Wed, 18 Oct 2023 04:01:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697626914; cv=none; d=google.com; s=arc-20160816; b=RhUDGoEzWcs8+bz7dxIBkI4tm6s/9ahR0E8JuKeMO9Si5NgoyosWpzXYpBmL18PP1A Tvcr9hX0KAghClS5mraQRvcovlLhCBPkkpArikdrn467/KVCWU9RHYP13koByBhJAplI IoqSckJc21FjcP+kjz6QTRV1JaCLGxahcaZRsTDAnbDzAwaSXPvzv2pId1zlAYxWxzDi ++wusFHmJ4DV23A0/6fjGJhHopxYMRjR+wSzg66u4lFf/jjO0f0AgomGPZSiyxQ8rHs3 d/W/ZdFeXuYU7gL6yOvhWlXR5T2tkMTgs18umSwgDCu32PXCGU8D8RF/kLqzZ3aD1364 rZnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=GjYoCvxQWdkPJaqlZTMzJhmYSWjS350k2Nz7vztIs58=; fh=0jTSe8S5u2Q8+XnE/2HvohBWJsMP3fYCGiwJeuyFYEk=; b=jA8HRSWjIrrt/0JHda5OXz5fUANOfcLsRxHcRcToxBbs4EKsBl0Sourev2XlNBoyKX 24pSG0b6B1iUVKTSyKnl6rhRWZwt7pgPWAtRgdVvB4crRKr2dA/ZJwYyLDCDdph/tZ0U zRnM9ScQMVA11WKLlwc0vLq9GUTJ+PKL6jYzviKi0iBhvhMuMIhLL5rBYCYesmvCuQLz /GC3hTXQTDjpBrtIAxkXB6fwevPbRgHM2q4unHN5kneCd9pWDPhV9K9tOTKTtqNSiE3G Qjw9WVUj8j8erpEO/zd0xEfPAijCaMrDjSbcjP0gqZqnPi/JTjg9ITAxJSvUYwCxKzNI lWxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id ot12-20020a17090b3b4c00b002790e9120ccsi1328761pjb.61.2023.10.18.04.01.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 04:01:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (Postfix) with ESMTP id ABFF48114ECE; Wed, 18 Oct 2023 04:01:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230075AbjJRLBm (ORCPT + 99 others); Wed, 18 Oct 2023 07:01:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230001AbjJRLBj (ORCPT ); Wed, 18 Oct 2023 07:01:39 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9844BB8 for ; Wed, 18 Oct 2023 04:01:37 -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 C495A2F4; Wed, 18 Oct 2023 04:02:17 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.67.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A6D953F762; Wed, 18 Oct 2023 04:01:34 -0700 (PDT) Date: Wed, 18 Oct 2023 12:01:32 +0100 From: Mark Rutland To: Douglas Anderson Cc: Marc Zyngier , Catalin Marinas , Will Deacon , Chen-Yu Tsai , Amit Daniel Kachhap , AngeloGioacchino Del Regno , James Morse , Joey Gouly , Mark Brown , Matthias Brugger , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH 1/3] arm64: Disable GiC priorities on Mediatek devices w/ firmware issues Message-ID: References: <20231006151547.1.Ide945748593cffd8ff0feb9ae22b795935b944d6@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231006151547.1.Ide945748593cffd8ff0feb9ae22b795935b944d6@changeid> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 18 Oct 2023 04:01:52 -0700 (PDT) On Fri, Oct 06, 2023 at 03:15:51PM -0700, Douglas Anderson wrote: > In commit 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on > Mediatek devices w/ firmware issues") we added a method for detecting > Mediatek devices with broken firmware and disabled pseudo-NMI. While > that worked, it didn't address the problem at a deep enough level. > > The fundamental issue with this broken firmware is that it's not > saving and restoring several important GICR registers. The current > list is believed to be: > * GICR_NUM_IPRIORITYR > * GICR_CTLR > * GICR_ISPENDR0 > * GICR_ISACTIVER0 > * GICR_NSACR > > Pseudo-NMI didn't work because it was the only thing (currently) in > the kernel that relied on the broken registers, so forcing pseudo-NMI > off was an effective fix. However, it could be observed that calling > system_uses_irq_prio_masking() on these systems still returned > "true". That caused confusion and led to the need for > commit a07a59415217 ("arm64: smp: avoid NMI IPIs with broken MediaTek > FW"). It's worried that the incorrect value returned by > system_uses_irq_prio_masking() on these systems will continue to > confuse future developers. > > Let's fix the issue a little more completely by disabling IRQ > priorities at a deeper level in the kernel. Once we do this we can > revert some of the other bits of code dealing with this quirk. > > Signed-off-by: Douglas Anderson > --- > > arch/arm64/kernel/cpufeature.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 2806a2850e78..e35efab8efa9 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2094,9 +2094,30 @@ static int __init early_enable_pseudo_nmi(char *p) > } > early_param("irqchip.gicv3_pseudo_nmi", early_enable_pseudo_nmi); > > +static bool are_gic_priorities_broken(void) > +{ > + bool is_broken = false; > + struct device_node *np; > + > + /* > + * Detect broken Mediatek firmware that doesn't properly save and > + * restore GIC priorities. > + */ > + np = of_find_compatible_node(NULL, NULL, "arm,gic-v3"); > + if (np) { > + is_broken = of_property_read_bool(np, "mediatek,broken-save-restore-fw"); > + of_node_put(np); > + } > + > + return is_broken; > +} I'm definitely in favour of detecting this in the cpucap, but I think it'd be better to parse the DT once on the boot CPU rather than on each CPU every time it's brought up. I think if we add something like: #ifdef CONFIG_ARM64_PSEUDO_NMI static void detect_system_supports_pseudo_nmi(void) { struct device_node *np; if (!enable_pseudo_nmi) return; /* * Detect broken Mediatek firmware that doesn't properly save and * restore GIC priorities. */ np = of_find_compatible_node(NULL, NULL, "arm,gic-v3"); if (np && of_property_read_bool(np, "mediatek,broken-save-restore-fw")) { pr_info("Pseudo-NMI disabled due to Mediatek Chromebook GICR save problem"); enable_pseudo_nmi = false; } of_node_put(np); } #endif /* CONFIG_ARM64_PSEUDO_NMI */ static inline void detect_system_supports_pseudo_nmi(void) { } #endif ... then we can call that from init_cpu_features() before we call setup_boot_cpu_capabilities(), and then the existing logic in can_use_gic_priorities() should just work as that returns the value of enable_pseudo_nmi. Note: of_node_put(NULL) does nothing, like kfree(NULL), so it's fine for that to be called in the !np case. Would you be happy to fold that in? I'm happy with a Suggested-by tag if so. :) Mark