Status Update
Comments
di...@google.com <di...@google.com> #2
FWIW, it's pretty easy to test this. I built the chromeos-6.1 kernel and put it on Kukui. When I picked CONFIG_ARM64_PSEUDO_NMI
and then added irqchip.gicv3_pseudo_nmi=1
to the kernel command line then the device didn't boot. When I added
mz...@google.com <mz...@google.com> #3
I assume this thing doesn't have an ITS to do MSIs? because it also seems to throw the LPI configuration under the bus, which is... unfortunate...
di...@google.com <di...@google.com> #4
I assume this thing doesn't have an ITS to do MSIs?
It doesn't seem to. I get no hits from:
git grep arm,gic-v3-its -- arch/arm64/boot/dts/mediatek/
mz...@google.com <mz...@google.com> #5
At least missing from the list:
- GICR_CTLR
- GICR_ISPENDR0
- GICR_ISACTIVER0
- GICR_NSACR
Note that the restore order is crucial so that no data get lost (secure config first, then interrupt state). I haven't checked the actual implementation.
di...@google.com <di...@google.com> #6
At least missing from the list [...]
OK, thanks for the heads up. I will leave it to someone who knows this stuff better to say how urgent getting this fixed it. This problem would basically affect all Mediatek Chromebooks ever shipped. While we could certainly do a firmware update for them if this is a critical issue, if nothing else we'll need to support booting recovery images from the read-only firmware which will never have this fixed.
di...@google.com <di...@google.com> #7
[...] if nothing else we'll need to support booting recovery images from the read-only firmware which will never have this fixed.
This also brings up the topic of detecting this problem from the kernel. I brought this up in
It looks like the best way would be to use SMCC calls, so ideally we'd use ARM_SMCCC_ARCH_SOC_ID
to detect that we're on an affected Mediatek SoC and then define some Mediatek-specific "SiP" (Silicon Partner) call to detect the workaround. Unfortunately, older Mediatek boards (like 8183) don't implement the ARM_SMCCC_ARCH_SOC_ID
call. :( I guess we may have to detect those CPUs with something like of_machine_is_compatible()
and then call the Mediatek-specific SiP call. Does that sound reasonable? I'll see if I can code something up.
mz...@google.com <mz...@google.com> #8
pNMI really is a debug feature. Why should it be enabled by default?
We keep it off by default because it is known to show how broken firmware is, specially on the mobile side of things (this MTK stuff is a shining example of getting it spectacularly wrong).
I really wouldn't expect a recovery image to force pNMI on, if ever.
di...@google.com <di...@google.com> #9
pNMI really is a debug feature. Why should it be enabled by default?
We want it enabled by default because we want to be able to do in-the-field NMI-based backtraces when the hardlockup detector detects a lockup. That will enable us to act on a lot more kernel crash reports that today are opaque because we don't have the call stack of the most important CPU in the system: the one that is locked up.
If it's really just these priority registers that need saving / restoring then it doesn't seem like it would be that huge of a deal.
di...@google.com <di...@google.com> #10
FWIW: I managed to get ahold of the latest Mediatek Chromebook I was aware of (8186) and I confirmed that the problem still exists there.
jw...@google.com <jw...@google.com> #11
First of all, does this save/restore happen only during system suspend/resume, or also in other cases (e.g. cpuidle)? Remember that we don't need to support system suspend/resume for recovery mode.
Also, if the feature is only used to provide extra debugging output for hardlockups, is that really relevant to recovery mode in the field? I mean, hopefully we don't have any hardlockups in such a controlled environment to begin with? And if we do, does it make a difference for the practical user experience if this works right or not (i.e. does the kernel actually recover from this lockup or does it just print out more debugging information before dying)? Remember that we don't get any crash reports from recovery mode either, so the only difference this could make is if it prevents the recovery process from being successful when it otherwise would be.
If we really need to figure out a way to check the running firmware version from the kernel and apply hacky quirks based on that we can try to come up with something, but I'd rather avoid that if at all possible. (The most straight-forward would probably be to parse /firmware/chromeos/firmware-version in the device tree.)
di...@google.com <di...@google.com> #12
First of all, does this save/restore happen only during system suspend/resume, or also in other cases (e.g. cpuidle)? Remember that we don't need to support system suspend/resume for recovery mode.
cpuidle. We can't even boot a recovery image with this buig.
Also, if the feature is only used to provide extra debugging output for hardlockups, is that really relevant to recovery mode in the field?
We don't need this for recover images. We just need it not to crash. If we simply enabled psuedo-NMIs unconditionally then they would be enabled in recovery images and we'd crash. It's not trivial to disable these just for recovery images.
If we really need to figure out a way to check the running firmware version
I ran out of time today, but I at least posted a WIP (I didn't even try to compile it) at mediatek,gicr-save-quirk-fixed
property into the GIC node if they get a fix.
di...@google.com <di...@google.com> #13
OK, I've posted up a series for the kernel. If this lands then at least the kernel won't crash and it'll be up to the firmware to fix the problem and then patch the device tree.
Somehow something got confused (not sure what yet) and the cover letter and the last patch have the same message ID. :( It still seems like these can be found at:
di...@google.com <di...@google.com> #14
v2 posted:
NOTE that 8186 is no longer supported by my patch series because Corsola isn't upstream yet. :(
di...@google.com <di...@google.com> #15
Also: any news about the firmware fix here?
di...@google.com <di...@google.com> #16
Marc landed the code and bindings patch (thanks!). I'll plan to wait until I see the DT patches land, pick everything FROMGIT, and then check to see where mt8186-corsola status is since my patch series didn't include that (it's not upstream yet). Still hoping to hear some status update for the firmware fix.
fe...@mediatek.corp-partner.google.com <fe...@mediatek.corp-partner.google.com> #17
As for save & restore the GICR_IPRIORITYR[x] registers, we have verified with WIP patch(
which just needs to add code in ATF, no needs to add any kernel workaround patches.
please help to double check and we will do upstream if no any other concern.
Best Regards
di...@google.com <di...@google.com> #18
please help to double check and we will do upstream if no any other concern.
Please also confirm that you've looked to see if any other registers are missing. Above Marc identified at least:
- GICR_CTLR
- GICR_ISPENDR0
- GICR_ISACTIVER0
- GICR_NSACR
You should also save/restore those plus double-check that no others are missing.
Once the save/restore is in ATF then you'll also need to provide a patch in the BIOS (in depthcharge, I think) that removes the quirk property from the device tree if it's there. You'll have to pick the patches in
yi...@google.com <yi...@google.com> #19
fe...@mediatek.corp-partner.google.com <fe...@mediatek.corp-partner.google.com> #20
The WIP patch 4542385 has been updated to add more registers save/restore and tested , please help to review
Best Regards
di...@google.com <di...@google.com> #21
I've uploaded kernel patches to relevant kernels. Notes:
Mediatek devices
This is what we have today:
SoC | kernel | Notes |
---|---|---|
MTK 8173 | 4.19 | Doesn't have GICv3 so won't get pseudo-NMI |
MTK 8183 | 5.10 | |
MTK 8186 | 5.15 | |
MTK 8192 | 5.4 | |
MTK 8195 | 5.10 |
kernel 5.4
Picking to chromeos-5.4 isn't all that clean. While we could do it, it probably makes sense to wait for 8192 to uprev and get the feature then. We should still fix the firmware in the meantime.
kernel 5.10
I posted the code to detect the quirk and the dts for 8183 and 8195.
https://crrev.com/c/4575426 - FROMGIT: arm64: dts: mediatek: mt8195: Add mediatek,broken-save-restore-fw to cherryhttps://crrev.com/c/4575425 - FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukuihttps://crrev.com/c/4575424 - FROMGIT: irqchip/gic: Correctly validate OF quirk descriptorshttps://crrev.com/c/4519371 - UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issueshttps://crrev.com/c/4575423 - UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FWhttps://crrev.com/c/4575422 - UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Describe GICv3 optional properties
If we're going to actually enable this feature, though, we should make sure we have all the upstream fixes, at least:
614ab80c9647 irqchip/gic-v3: Fix priority mask handling
6efb50923771 irqchip/gic-v3: Refactor ISB + EOIR at ack time
adf14453d2c0 irqchip/gic-v3: Ensure pseudo-NMIs have an ISB between ack and handling
kernel 5.15
I posted the code to detect the quirk and the dts for 8183 (because it was upstream) and 8186:
https://crrev.com/c/4575421 - CHROMIUM: arm64: dts: mediatek: mt8186: Add mediatek,broken-save-restore-fw to corsolahttps://crrev.com/c/4573420 - FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukuihttps://crrev.com/c/4573419 - FROMGIT: irqchip/gic: Correctly validate OF quirk descriptorshttps://crrev.com/c/4573418 - UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issueshttps://crrev.com/c/4573417 - UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
Of the above 3 patches, two came through stable but the last had conflicts. We need to resolve:
614ab80c9647 irqchip/gic-v3: Fix priority mask handling
kernel 6.1
I posted these, which were the ones that cleanly picked. mt8195 is in a weird state in the chromeos-6.1 tree and so it wasn't easy to pick conflict-free. Presumably if/when someone uprevs 8195 to chromeos-6.1 they'll see this fix upstream or in our 5.10 tree and get it.
https://crrev.com/c/4575432 - CHROMIUM: arm64: dts: mediatek: mt8186: Add mediatek,broken-save-restore-fw to corsolahttps://crrev.com/c/4575431 - FROMGIT: arm64: dts: mediatek: mt8192: Add mediatek,broken-save-restore-fw to asuradahttps://crrev.com/c/4575430 - FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukuihttps://crrev.com/c/4575429 - FROMGIT: irqchip/gic: Correctly validate OF quirk descriptorshttps://crrev.com/c/4575428 - UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issueshttps://crrev.com/c/4575427 - UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
we...@google.com <we...@google.com> #22
MT8195 uprev is scheduled for next year.
I think right now it would be more useful during the bring-up phase to get more information on mysterious hangs.
ap...@google.com <ap...@google.com> #23
Branch: chromeos-6.1
commit 0b11568653136f0e6871f2382bdd97387c5f9ca5
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:52 2023
CHROMIUM: arm64: dts: mediatek: mt8186: Add mediatek,broken-save-restore-fw to corsola
Firmware shipped on mt8186 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
UPSTREAM-TASK=b:213000788
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Id23d6aa00a713edbf3caf2d8b81a9d7ac43a1d32
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Yidi Lin <yidilin@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
ap...@google.com <ap...@google.com> #24
Branch: chromeos-6.1
commit c09b9155424d210977e0daa04eedc00c5915fc77
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:53 2023
FROMGIT: arm64: dts: mediatek: mt8192: Add mediatek,broken-save-restore-fw to asurada
Firmware shipped on mt8192 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
Fixes: 331fae2fc922 ("arm64: dts: mediatek: Introduce MT8192-based Asurada board family")
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link:
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
(cherry picked from commit d72cfbd6fcf7cd02084991eee47ecc9f4b4c1e69
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Ie7e600278ffbed55a1e5a58178203787b1449b35
Reviewed-on:
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi
ap...@google.com <ap...@google.com> #25
Branch: chromeos-6.1
commit e081c38913135102b02bbcbfc9bf79046cd9f2a0
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:52 2023
FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukui
Firmware shipped on mt8183 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board")
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link:
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
(cherry picked from commit 42127f578ebde652d1373e0233356fbd351675c4
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I525a2ed4260046d43c885ee1275e91707743df1c
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
ap...@google.com <ap...@google.com> #26
Branch: chromeos-6.1
commit e271e3e5da8dd6561430411690a5ca4075708259
Author: Marc Zyngier <maz@kernel.org>
Date: Tue May 30 11:01:22 2023
FROMGIT: irqchip/gic: Correctly validate OF quirk descriptors
When checking for OF quirks, make sure either 'compatible' or 'property'
is set, and give up otherwise.
This avoids non-OF quirks being randomly applied as they don't have any
of the OF data that need checking.
Cc: Douglas Anderson <dianders@chromium.org>
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues")
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit 91539341a3b6e9c868024a4292455dae36e6f58c
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I6fcac014ed9cc4f370383bfe59cef16846e8dfa7
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
M drivers/irqchip/irq-gic-common.c
ap...@google.com <ap...@google.com> #27
Branch: chromeos-6.1
commit eb3bc1cde6325cc64dd11e4b3f71456b001e8cc1
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:51 2023
UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues
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@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 44bd78dd2b8897f59b7e3963f088caadb7e4f047)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Cq-Depend: chromium:4575429
Change-Id: I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1
Reviewed-on:
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
M drivers/irqchip/irq-gic-common.c
M drivers/irqchip/irq-gic-common.h
M drivers/irqchip/irq-gic-v3.c
ap...@google.com <ap...@google.com> #28
Branch: chromeos-6.1
commit 650f7a9c07729cc7fabd0c4332cb616cf9b5eae1
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:50 2023
UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
When trying to turn on the "pseudo NMI" kernel feature in Linux, it
was discovered that all Mediatek-based Chromebooks that ever shipped
(at least ones with GICv3) had a firmware bug where they wouldn't save
certain GIC "GICR" registers properly. If a processor ever entered a
suspend/idle mode where the GICR registers lost state then they'd be
reset to their default state.
As a result of the bug, if you try to enable "pseudo NMIs" on the
affected devices then certain interrupts will unexpectedly get
promoted to be "pseudo NMIs" and cause crashes / freezes / general
mayhem.
ChromeOS is looking to start turning on "pseudo NMIs" in production to
make crash reports more actionable. To do so, we will release firmware
updates for at least some of the affected Mediatek Chromebooks.
However, even when we update the firmware of a Chromebook it's always
possible that a user will end up booting with old firmware. We need to
be able to detect when we're running with firmware that will crash and
burn if pseudo NMIs are enabled.
The current plan is:
* Update the device trees of all affected Chromebooks to include the
'mediatek,broken-save-restore-fw' property. The kernel can use this
to know not to enable certain features like "pseudo NMI". NOTE:
device trees for Chromebooks are never baked into the firmware but
are bundled with the kernel. A kernel will never be configured to
use "pseudo NMIs" and be bundled with an old device tree.
* When we get a fixed firmware for one of these Chromebooks, it will
patch the device tree to remove this property.
For some details, you can also see the public bug
<
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 43cd3ddbff3c1635d0e09fe5b09af48d39dbb9d7)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Iabe67a827e206496efec6beb5616d5a3b99c1e65
Reviewed-on:
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
M Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
ap...@google.com <ap...@google.com> #29
Branch: chromeos-5.15
commit db42af38816763ecf948c7b8eeac7d6aa4eaaac3
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:52 2023
CHROMIUM: arm64: dts: mediatek: mt8186: Add mediatek,broken-save-restore-fw to corsola
Firmware shipped on mt8186 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
UPSTREAM-TASK=b:213000788
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Id23d6aa00a713edbf3caf2d8b81a9d7ac43a1d32
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Yidi Lin <yidilin@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi
ap...@google.com <ap...@google.com> #30
Branch: chromeos-5.15
commit d49bac2f6f07dc5f552a250f65cafc985113e03d
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:52 2023
FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukui
Firmware shipped on mt8183 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board")
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link:
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
(cherry picked from commit 42127f578ebde652d1373e0233356fbd351675c4
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I525a2ed4260046d43c885ee1275e91707743df1c
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
ap...@google.com <ap...@google.com> #31
Branch: chromeos-5.15
commit c0e75cb6122ae787c2110d085473d1381f7cfdaa
Author: Marc Zyngier <maz@kernel.org>
Date: Tue May 30 11:01:22 2023
FROMGIT: irqchip/gic: Correctly validate OF quirk descriptors
When checking for OF quirks, make sure either 'compatible' or 'property'
is set, and give up otherwise.
This avoids non-OF quirks being randomly applied as they don't have any
of the OF data that need checking.
Cc: Douglas Anderson <dianders@chromium.org>
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues")
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit 91539341a3b6e9c868024a4292455dae36e6f58c
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I6fcac014ed9cc4f370383bfe59cef16846e8dfa7
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
M drivers/irqchip/irq-gic-common.c
ap...@google.com <ap...@google.com> #32
Branch: chromeos-5.15
commit d4fa676412a723561cecb62730538d03e4937271
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:51 2023
UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues
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@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 44bd78dd2b8897f59b7e3963f088caadb7e4f047)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Cq-Depend: chromium:4573419
Change-Id: I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1
Reviewed-on:
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
M drivers/irqchip/irq-gic-common.c
M drivers/irqchip/irq-gic-common.h
M drivers/irqchip/irq-gic-v3.c
ap...@google.com <ap...@google.com> #33
Branch: chromeos-5.15
commit 11cda9cc4a1ac84346f51125cfcf724632b79a38
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:50 2023
UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
When trying to turn on the "pseudo NMI" kernel feature in Linux, it
was discovered that all Mediatek-based Chromebooks that ever shipped
(at least ones with GICv3) had a firmware bug where they wouldn't save
certain GIC "GICR" registers properly. If a processor ever entered a
suspend/idle mode where the GICR registers lost state then they'd be
reset to their default state.
As a result of the bug, if you try to enable "pseudo NMIs" on the
affected devices then certain interrupts will unexpectedly get
promoted to be "pseudo NMIs" and cause crashes / freezes / general
mayhem.
ChromeOS is looking to start turning on "pseudo NMIs" in production to
make crash reports more actionable. To do so, we will release firmware
updates for at least some of the affected Mediatek Chromebooks.
However, even when we update the firmware of a Chromebook it's always
possible that a user will end up booting with old firmware. We need to
be able to detect when we're running with firmware that will crash and
burn if pseudo NMIs are enabled.
The current plan is:
* Update the device trees of all affected Chromebooks to include the
'mediatek,broken-save-restore-fw' property. The kernel can use this
to know not to enable certain features like "pseudo NMI". NOTE:
device trees for Chromebooks are never baked into the firmware but
are bundled with the kernel. A kernel will never be configured to
use "pseudo NMIs" and be bundled with an old device tree.
* When we get a fixed firmware for one of these Chromebooks, it will
patch the device tree to remove this property.
For some details, you can also see the public bug
<
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 43cd3ddbff3c1635d0e09fe5b09af48d39dbb9d7)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Iabe67a827e206496efec6beb5616d5a3b99c1e65
Reviewed-on:
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
M Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
ap...@google.com <ap...@google.com> #34
Branch: chromeos-5.10
commit b3d9986e39ae807a2f70e324065a87c39745e431
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:52 2023
FROMGIT: arm64: dts: mediatek: mt8183: Add mediatek,broken-save-restore-fw to kukui
Firmware shipped on mt8183 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board")
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link:
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
(cherry picked from commit 42127f578ebde652d1373e0233356fbd351675c4
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I525a2ed4260046d43c885ee1275e91707743df1c
Reviewed-on:
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
ap...@google.com <ap...@google.com> #35
Branch: chromeos-5.10
commit 6c0be5119c2634d271733ca08efa188134a24208
Author: Marc Zyngier <maz@kernel.org>
Date: Tue May 30 11:01:22 2023
FROMGIT: irqchip/gic: Correctly validate OF quirk descriptors
When checking for OF quirks, make sure either 'compatible' or 'property'
is set, and give up otherwise.
This avoids non-OF quirks being randomly applied as they don't have any
of the OF data that need checking.
Cc: Douglas Anderson <dianders@chromium.org>
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 44bd78dd2b88 ("irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues")
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit 91539341a3b6e9c868024a4292455dae36e6f58c
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: I6fcac014ed9cc4f370383bfe59cef16846e8dfa7
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
M drivers/irqchip/irq-gic-common.c
ap...@google.com <ap...@google.com> #36
Branch: chromeos-5.10
commit 825d270c8ffd5ccd787399e0142b86cb869ad31b
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:51 2023
UPSTREAM: irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues
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@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 44bd78dd2b8897f59b7e3963f088caadb7e4f047)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Cq-Depend: chromium:4575424
Change-Id: I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1
Reviewed-on:
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
M drivers/irqchip/irq-gic-common.c
M drivers/irqchip/irq-gic-common.h
M drivers/irqchip/irq-gic-v3.c
ap...@google.com <ap...@google.com> #37
Branch: chromeos-5.10
commit bc04f2df0f4e903e7bed8169404f6c6580c722d3
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:50 2023
UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
When trying to turn on the "pseudo NMI" kernel feature in Linux, it
was discovered that all Mediatek-based Chromebooks that ever shipped
(at least ones with GICv3) had a firmware bug where they wouldn't save
certain GIC "GICR" registers properly. If a processor ever entered a
suspend/idle mode where the GICR registers lost state then they'd be
reset to their default state.
As a result of the bug, if you try to enable "pseudo NMIs" on the
affected devices then certain interrupts will unexpectedly get
promoted to be "pseudo NMIs" and cause crashes / freezes / general
mayhem.
ChromeOS is looking to start turning on "pseudo NMIs" in production to
make crash reports more actionable. To do so, we will release firmware
updates for at least some of the affected Mediatek Chromebooks.
However, even when we update the firmware of a Chromebook it's always
possible that a user will end up booting with old firmware. We need to
be able to detect when we're running with firmware that will crash and
burn if pseudo NMIs are enabled.
The current plan is:
* Update the device trees of all affected Chromebooks to include the
'mediatek,broken-save-restore-fw' property. The kernel can use this
to know not to enable certain features like "pseudo NMI". NOTE:
device trees for Chromebooks are never baked into the firmware but
are bundled with the kernel. A kernel will never be configured to
use "pseudo NMIs" and be bundled with an old device tree.
* When we get a fixed firmware for one of these Chromebooks, it will
patch the device tree to remove this property.
For some details, you can also see the public bug
<
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 43cd3ddbff3c1635d0e09fe5b09af48d39dbb9d7)
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Iabe67a827e206496efec6beb5616d5a3b99c1e65
Reviewed-on:
Reviewed-by: Sean Paul <sean@poorly.run>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
M Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
ap...@google.com <ap...@google.com> #38
Branch: chromeos-5.10
commit 42f8fc5b6a8c66c47f24e01aae5862c3b94724b9
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon May 15 13:13:54 2023
FROMGIT: arm64: dts: mediatek: mt8195: Add mediatek,broken-save-restore-fw to cherry
Firmware shipped on mt8195 Chromebooks is affected by the GICR
save/restore issue as described by the patch ("dt-bindings:
interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/
broken FW"). Add the quirk property.
Fixes: 5eb2e303ec6b ("arm64: dts: mediatek: Introduce MT8195 Cherry platform's Tomato")
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link:
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
(cherry picked from commit ea6c5f21efecbaa3a14cb21c5bc0e23c84473a11
git://
BUG=b:281831288, b:197061987
TEST=Pseudo NMIs are disabled on MTK devices
Change-Id: Ia0b6ebbaa351e3cd67e201355b9ae67783c7d718
Reviewed-on:
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Yidi Lin <yidilin@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
M arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
ap...@google.com <ap...@google.com> #39
Branch: chromeos-5.10
commit e1fbef4c7d1bbb1591016df2b073e7fd98206bdd
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date: Wed Jun 09 16:51:08 2021
UPSTREAM: dt-bindings: interrupt-controller: arm,gic-v3: Describe GICv3 optional properties
Describe the optional GICv3 properties:
- clocks
- clock-names
- power-domains
- resets
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link:
(cherry picked from commit 4e08a559a18c1b6424e56859c74adb4b29c17318)
BUG=b:281831288, b:197061987
TEST=Future patches easier to pick
Change-Id: Ic248e25042a769291845ce2bd85e6157352b1140
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on:
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
M Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
di...@google.com <di...@google.com> #40
Ugh, shouldn't have deleted the CLs merged. Sigh. Oh well, I guess not that important.
In any cased, all of the quirk stuff has landed in the various kernels. Marc has given a +1 to the ATF change:
https://crrev.com/c/4542385 - add more gic registers save&restore to support kernel NMI
So I guess next steps:
- I think we need to get the ATF change landed to upstream ATF.
- Once this is in upstream ATF, then I guess we pick it from there to our ATF.
- Once this is in our ATF, then Mediatek needs to write the depthcharge code to remove the GIC quirk from the kernel's device tree.
- Once we have the code in Top-of-Tree, then we need to pick it to relevant firmware branches.
- I don't think this is urgent enough to warrant a firmware spin on its own, but any time a given Mediatek SoC does a firmware spin then they'll get the fix.
Once the above is all done, we can close this and continue tracking turning on pseudo NMI for backtrace in
ja...@mediatek.corp-partner.google.com <ja...@mediatek.corp-partner.google.com> #43
Regarding
yi...@google.com <yi...@google.com> #44
Re
ap...@google.com <ap...@google.com> #45
Branch: main
commit 939d323a42d44ba584f78a37a6e7e67de92b2326
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #46
Branch: main
commit 2ba7c971aaea6a0cd1e01b6c93f9507db15c18e1
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 13:06:26 2023
geralt: Remove quirk property from GIC FDT
As CL:4542385 is merged, now MTK ATF can save/restore GICR registers
properly. Currently Geralt does not enable pseudo NMI now. We still can
add the FDT fixup and remove the quirk.
BRANCH=none
BUG=b:281831288
TEST=Add `mediatek,broken-save-restore-fw` to the kernel side manually
and see the quirk been removed after booting up.
Change-Id: If6765a353285d1d520236f63e5c3a387c4507517
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
M src/board/geralt/board.c
yi...@google.com <yi...@google.com> #47
I created
ap...@google.com <ap...@google.com> #48
Branch: firmware-corsola-15194.B
commit 74b220109ae29268c2eec89c22471df9fc9d5328
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #49
Branch: firmware-cherry-14454.B
commit db97eb27f2f3b3efdaa628d48ca1097b9d340be2
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #50
Branch: firmware-asurada-13885.B
commit d9ecc147549a9796e83bd1846801763f9f2f5d31
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #51
Branch: firmware-corsola-15194.B
commit 74b220109ae29268c2eec89c22471df9fc9d5328
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #52
Branch: firmware-cherry-14454.B
commit db97eb27f2f3b3efdaa628d48ca1097b9d340be2
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
ap...@google.com <ap...@google.com> #53
Branch: firmware-corsola-15194.B
commit 74b220109ae29268c2eec89c22471df9fc9d5328
Author: Yidi Lin <yidilin@chromium.org>
Date: Wed Jul 05 12:54:55 2023
devicetree: Add property removal support
Add support for removing a property from a given device tree node.
BRANCH=none
BUG=b:281831288
TEST=Add 'mediatek,broken-save-restore-fw' to the kernel side manually
and check the quirk been removed after booting up.
Change-Id: Ie2273c7d3d00aa84ad0fd8fb41424833d5b9263f
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on:
Reviewed-by: Yu-Ping Wu <yupingso@chromium.org>
Commit-Queue: Yu-Ping Wu <yupingso@chromium.org>
(cherry picked from commit 939d323a42d44ba584f78a37a6e7e67de92b2326)
Reviewed-on:
Commit-Queue: Chen-Tsung Hsieh <chentsung@chromium.org>
Reviewed-by: Chen-Tsung Hsieh <chentsung@chromium.org>
M src/base/device_tree.c
M src/base/device_tree.h
Description
It appears that Mediatek's ATF doesn't save/restore the GICR_IPRIORITYR[x] registers. This causes problems when the kernel starts trying to use them, like the pseudoNMI. See b/197061987 .
For reference, the function that Mediatek seems to be using to save GIC state is:
As you can see, it does save a bunch of stuff, but not the priority.
We should fix Mediatek's ATF implementation. Ideally, it should call the standard functions like
gicv3_rdistif_save()
andgicv3_rdistif_init_restore()
As a workaround in the Linux kernelhttps://crrev.com/c/4519877 seems to work, but upstream may not accept something like this. We can continue discussion about that in b/197061987 . Even if the kernel does manage to land a workaround, though, we should still fix ATF.