Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp837526rwd; Tue, 16 May 2023 08:16:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7Obw2d4bY/Hye3PrJiVuQRXN9+EN5jQXkwa1s07CGGnUncJO6e8xP7n5o6Ngr+WoloEzQw X-Received: by 2002:a05:6a20:8429:b0:107:3db4:1666 with SMTP id c41-20020a056a20842900b001073db41666mr1135938pzd.23.1684250190104; Tue, 16 May 2023 08:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684250190; cv=none; d=google.com; s=arc-20160816; b=oHUfmxHmoe24ZjsPnVcLQAQvBbaZ1CBZk9KgzHLXlrfnepy9oY+vfuU5ghN8+9M5ls kYeK+xHaMpCOj0Zx9RLQPByOjO9O/e7c2R0MV649Mutkc7MZirbcNY6BrUXd1t7NV6Dn QA6wuQT61310wD2G0uIiCAryNLIYpEVEPpT6hDWcHViTsTCdUEJ2bEjp1zdgx9UtDIhD hvO1d7Xl0L8iC+osr6MI28/kLPKBVWypFkvP5hjbQfwNvfPIfqo73g1PuoHunT9uiP9Y Bnydx6VAMrSIPPbAA2hDXxpppM7rRFhXQOqOK6Ka7srjMQX6nlwYHuVylvXfCBhlRnv5 1VMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=FjvR70t5lyaH1e9tj41LLQquNKMyWCnDqCJwFXVcI4o=; b=xG8IHnHvpQJ49Fo9E5/1TLnJEFKJS/1wJKHx7TgLcunzv4wrCG/emtvbk1cZ6GhHDt RkzzL1SY7WQVPqMaTxUCJL8B01yDCUQlDNXlSujlYxk0n8h4P/dCerLdPtz8kILuOHzL yJyID0sLtxW0I1uLrQ4NDjVB9qmSrtijyaixUKBGXGbalnoXZTEe+uSem4xqlcsEmUj+ CRFj7DbNrURlIDCD8KsnlwFY/AOjh6yCSln5RMpB1Ew3AHzkmqLG6Kki/UxtFafOtvEG DCwxZLCHQloVPPYhy0pP02YGotNXAfmSTEbTgaVHYxdot1XK1NqDLvYmNziCGZI0lTJ0 iAzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YEhtFhZU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f27-20020a63755b000000b0052cbd7cff1dsi18545355pgn.708.2023.05.16.08.16.14; Tue, 16 May 2023 08:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YEhtFhZU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234007AbjEPO55 (ORCPT + 99 others); Tue, 16 May 2023 10:57:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233744AbjEPO5z (ORCPT ); Tue, 16 May 2023 10:57:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39E3F4487; Tue, 16 May 2023 07:57:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7F1D2630E5; Tue, 16 May 2023 14:57:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4065C433EF; Tue, 16 May 2023 14:57:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684249070; bh=i6M5/UI5gYYrcQo2Y00Z1kbdlK8gGZF19QqQZFugTaY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YEhtFhZUuBANto1gfEjvX685M5ITtH5A8Hkf8vV39QSsHuzhU8vKYjUbZ8lCkLiN4 ud3NZe8HIg1njVTzWb1OlWZlpO+hM8Bgw3HpdOx0HrRYpM8c1WVipVSBh3gBBWCweQ Ta+DgY/lKHPhxpAb+EbuPuOf7/NqnPO5bT2pwWx9g4IYDSDwHm/SUFO8P94SkM34el izYq72jex2oZi+2qTV83qA1F6J1NTAZ1reh1Nj4JjVkqu5MoKziBRbyqXrbhfCJMN7 TNfZr7w+RhBN2SoCsaawo2yXgAND8CoWWhORmmqZ5NqMYDn0PziOEAi/+SUSTBBqSa ufyG6pXKGgH9A== 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 1pyw7Y-00FZt0-H1; Tue, 16 May 2023 15:57:48 +0100 Date: Tue, 16 May 2023 15:57:48 +0100 Message-ID: <865y8smihf.wl-maz@kernel.org> From: Marc Zyngier To: AngeloGioacchino Del Regno Cc: Douglas Anderson , Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Allen-KH Cheng , linux-mediatek@lists.infradead.org, Eddie Huang , Hsin-Hsiung Wang , wenst@chromium.org, yidilin@chromium.org, Tinghan Shen , jwerner@chromium.org, Weiyi Lu , Ben Ho , Seiya Wang , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/5] irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues In-Reply-To: <3cc683e7-28aa-7b6e-1499-3aca953294cc@collabora.com> References: <20230515131353.v2.cover@dianders> <20230515131353.v2.2.I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1@changeid> <3cc683e7-28aa-7b6e-1499-3aca953294cc@collabora.com> 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/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: angelogioacchino.delregno@collabora.com, dianders@chromium.org, tglx@linutronix.de, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, allen-kh.cheng@mediatek.com, linux-mediatek@lists.infradead.org, eddie.huang@mediatek.com, hsin-hsiung.wang@mediatek.com, wenst@chromium.org, yidilin@chromium.org, tinghan.shen@mediatek.com, jwerner@chromium.org, weiyi.lu@mediatek.com, Ben.Ho@mediatek.com, seiya.wang@mediatek.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 May 2023 14:23:52 +0100, AngeloGioacchino Del Regno wrote: > > Il 15/05/23 22:13, Douglas Anderson ha scritto: > > Some Chromebooks with Mediatek SoCs have a problem where the firmware > > doesn't properly save/restore certain GICR registers. Newer > > Chromebooks should fix this issue and we may be able to do firmware > > updates for old Chromebooks. At the moment, the only known issue with > > these Chromebooks is that we can't enable "pseudo NMIs" since the > > priority register can be lost. Enabling "pseudo NMIs" on Chromebooks > > with the problematic firmware causes crashes and freezes. > > > > Let's detect devices with this problem and then disable "pseudo NMIs" > > on them. We'll detect the problem by looking for the presence of the > > "mediatek,broken-save-restore-fw" property in the GIC device tree > > node. Any devices with fixed firmware will not have this property. > > > > Our detection plan works because we never bake a Chromebook's device > > tree into firmware. Instead, device trees are always bundled with the > > kernel. We'll update the device trees of all affected Chromebooks and > > then we'll never enable "pseudo NMI" on a kernel that is bundled with > > old device trees. When a firmware update is shipped that fixes this > > issue it will know to patch the device tree to remove the property. > > > > In order to make this work, the quick detection mechanism of the GICv3 > > code is extended to be able to look for properties in addition to > > looking at "compatible". > > > > Reviewed-by: Julius Werner > > Signed-off-by: Douglas Anderson > > I don't like firmware removing properties from my devicetrees and I'd like this > issue to get addressed in another way (use a scratch register? and check it in > Linux drivers to determine if the issue is not present: if scratch contains BIT(x), > do not parse the quirk) but that's a different discussion which is a bit out of > context for this patch, so: So what you're advocating for is that we have another flag somewhere that says the same thing. Stored where? Accessible how? On top of having to check for DT, ACPI, and SOC_ID interfaces, you want YAFM (Yet Another Fixing Method)? Thanks, but no, thanks. M. -- Without deviation from the norm, progress is not possible.