Re: [PATCH v2 2/5] irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues

[Marc Zyngier]

On Tue, 16 May 2023 14:23:52 +0100,
AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx> 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 <jwerner@xxxxxxxxxxxx>
> > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> 
> 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.