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: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
Signed-off-by: Douglas Anderson <[email protected]>
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index a44aae4ab953..6df9ad8f658f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -463,6 +463,7 @@ gic: interrupt-controller@c000000 {
reg = <0 0x0c000000 0 0x40000>,
<0 0x0c040000 0 0x200000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ mediatek,gicr-save-quirk;
ppi-partitions {
ppi_cluster0: interrupt-partition-0 {
--
2.40.1.606.ga4b1b128d6-goog
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,gicr-save-quirk" 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".
Signed-off-by: Douglas Anderson <[email protected]>
---
drivers/irqchip/irq-gic-common.c | 8 ++++++--
drivers/irqchip/irq-gic-common.h | 1 +
drivers/irqchip/irq-gic-v3.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index a610821c8ff2..de47b51cdadb 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -16,7 +16,11 @@ void gic_enable_of_quirks(const struct device_node *np,
const struct gic_quirk *quirks, void *data)
{
for (; quirks->desc; quirks++) {
- if (!of_device_is_compatible(np, quirks->compatible))
+ if (quirks->compatible &&
+ !of_device_is_compatible(np, quirks->compatible))
+ continue;
+ if (quirks->property &&
+ !of_property_read_bool(np, quirks->property))
continue;
if (quirks->init(data))
pr_info("GIC: enabling workaround for %s\n",
@@ -28,7 +32,7 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
void *data)
{
for (; quirks->desc; quirks++) {
- if (quirks->compatible)
+ if (quirks->compatible || quirks->property)
continue;
if (quirks->iidr != (quirks->mask & iidr))
continue;
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index 27e3d4ed4f32..3db4592cda1c 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -13,6 +13,7 @@
struct gic_quirk {
const char *desc;
const char *compatible;
+ const char *property;
bool (*init)(void *data);
u32 iidr;
u32 mask;
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 6fcee221f201..161cc8957e8b 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -39,6 +39,7 @@
#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996 (1ULL << 0)
#define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539 (1ULL << 1)
+#define FLAGS_WORKAROUND_MTK_GICR_SAVE (1ULL << 2)
#define GIC_IRQ_TYPE_PARTITION (GIC_IRQ_TYPE_LPI + 1)
@@ -1720,6 +1721,15 @@ static bool gic_enable_quirk_msm8996(void *data)
return true;
}
+static bool gic_enable_quirk_mtk_gicr(void *data)
+{
+ struct gic_chip_data *d = data;
+
+ d->flags |= FLAGS_WORKAROUND_MTK_GICR_SAVE;
+
+ return true;
+}
+
static bool gic_enable_quirk_cavium_38539(void *data)
{
struct gic_chip_data *d = data;
@@ -1792,6 +1802,11 @@ static const struct gic_quirk gic_quirks[] = {
.compatible = "qcom,msm8996-gic-v3",
.init = gic_enable_quirk_msm8996,
},
+ {
+ .desc = "GICv3: Mediatek Chromebook GICR save problem",
+ .property = "mediatek,gicr-save-quirk",
+ .init = gic_enable_quirk_mtk_gicr,
+ },
{
.desc = "GICv3: HIP06 erratum 161010803",
.iidr = 0x0204043b,
@@ -1834,6 +1849,11 @@ static void gic_enable_nmi_support(void)
if (!gic_prio_masking_enabled())
return;
+ if (gic_data.flags & FLAGS_WORKAROUND_MTK_GICR_SAVE) {
+ pr_warn("Skipping NMI enable due to firmware issues\n");
+ return;
+ }
+
ppi_nmi_refs = kcalloc(gic_data.ppi_nr, sizeof(*ppi_nmi_refs), GFP_KERNEL);
if (!ppi_nmi_refs)
return;
--
2.40.1.606.ga4b1b128d6-goog
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,gicr-save-quirk' 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
<https://issuetracker.google.com/281831288>
Signed-off-by: Douglas Anderson <[email protected]>
---
.../bindings/interrupt-controller/arm,gic-v3.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index 92117261e1e1..8c251caae537 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -166,6 +166,12 @@ properties:
resets:
maxItems: 1
+ mediatek,gicr-save-quirk:
+ type: boolean
+ description:
+ Asserts that the firmware on this device has issues saving and restoring
+ GICR registers when CPUs are powered off.
+
dependencies:
mbi-ranges: [ msi-controller ]
msi-controller: [ mbi-ranges ]
--
2.40.1.606.ga4b1b128d6-goog
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: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile")
Signed-off-by: Douglas Anderson <[email protected]>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5169779d01df..39545172fce5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -709,6 +709,7 @@ gic: interrupt-controller@c000000 {
<0 0x0c400000 0 0x2000>, /* GICC */
<0 0x0c410000 0 0x1000>, /* GICH */
<0 0x0c420000 0 0x2000>; /* GICV */
+ mediatek,gicr-save-quirk;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
ppi-partitions {
--
2.40.1.606.ga4b1b128d6-goog
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.
Fixes: 2e78620b1350 ("arm64: dts: Add MediaTek MT8186 dts and evaluation board and Makefile")
Signed-off-by: Douglas Anderson <[email protected]>
---
arch/arm64/boot/dts/mediatek/mt8186.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
index 5e83d4e9efa4..09fbd8f9ea52 100644
--- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
@@ -336,6 +336,7 @@ gic: interrupt-controller@c000000 {
reg = <0 0x0c000000 0 0x40000>,
<0 0x0c040000 0 0x200000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ mediatek,gicr-save-quirk;
ppi-partitions {
ppi_cluster0: interrupt-partition-0 {
--
2.40.1.606.ga4b1b128d6-goog
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: 48489980e27e ("arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile")
Signed-off-by: Douglas Anderson <[email protected]>
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 5c30caf74026..8931c59c69f4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -412,6 +412,7 @@ gic: interrupt-controller@c000000 {
reg = <0 0x0c000000 0 0x40000>,
<0 0x0c040000 0 0x200000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ mediatek,gicr-save-quirk;
ppi-partitions {
ppi_cluster0: interrupt-partition-0 {
--
2.40.1.606.ga4b1b128d6-goog
Reviewed-by: Julius Werner <[email protected]>
Reviewed-by: Julius Werner <[email protected]>
Reviewed-by: Julius Werner <[email protected]>
Reviewed-by: Julius Werner <[email protected]>
Reviewed-by: Julius Werner <[email protected]>
Reviewed-by: Julius Werner <[email protected]>
On Thu, 11 May 2023 23:05:35 +0100,
Douglas Anderson <[email protected]> wrote:
>
> 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,gicr-save-quirk' 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.
Since you're in control of distributing the FW together with the
kernel, I assume you're also in control of the command line. Why can't
that firmware pass the option enabling the pseudo-NMI support,
dispensing ourselves from all of this?
>
> For some details, you can also see the public bug
> <https://issuetracker.google.com/281831288>
>
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
>
> .../bindings/interrupt-controller/arm,gic-v3.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> index 92117261e1e1..8c251caae537 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> @@ -166,6 +166,12 @@ properties:
> resets:
> maxItems: 1
>
> + mediatek,gicr-save-quirk:
I think this deserves something *much* stronger that outlines what is
wrong, because this is not just a quirk. This is a failure to even
remotely grasp the requirements of the architecture (and to use
standard, public code that would have done it correctly). Something
like "mediatek,broken-save-restore-fw" would be more adequate.
> + type: boolean
> + description:
> + Asserts that the firmware on this device has issues saving and restoring
> + GICR registers when CPUs are powered off.
Nit: not the the CPUs, but the GIC redistributors.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Thu, 11 May 2023 23:05:37 +0100,
Douglas Anderson <[email protected]> wrote:
>
> 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: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile")
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5169779d01df..39545172fce5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -709,6 +709,7 @@ gic: interrupt-controller@c000000 {
> <0 0x0c400000 0 0x2000>, /* GICC */
> <0 0x0c410000 0 0x1000>, /* GICH */
> <0 0x0c420000 0 0x2000>; /* GICV */
> + mediatek,gicr-save-quirk;
Is that something you can safely generalise at the SoC level? Are
these SoC solely used on Chromebooks, and/or without any hope of
seeing any alternative FW being already in use?
M.
--
Without deviation from the norm, progress is not possible.
Hi Julius,
On 12/05/2023 00:37, Julius Werner wrote:
> Reviewed-by: Julius Werner <[email protected]>
For the future please don't delete the patch itself if you give a tag, just
leave it as it is (and don't top-post your tag :) )
Regards,
Matthias
Hi,
On Fri, May 12, 2023 at 1:02 AM Marc Zyngier <[email protected]> wrote:
>
> On Thu, 11 May 2023 23:05:35 +0100,
> Douglas Anderson <[email protected]> wrote:
> >
> > 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,gicr-save-quirk' 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.
>
> Since you're in control of distributing the FW together with the
> kernel, I assume you're also in control of the command line. Why can't
> that firmware pass the option enabling the pseudo-NMI support,
> dispensing ourselves from all of this?
I considered the option, but it gets really awkward. Specifically:
1. We can't have old firmwares "take away" the kernel command line
option enabling pseudoNMI, obviously.
2. Having new firmware inject `irqchip.gicv3_pseudo_nmi=1` into the
kernel command line feels really awkward from an abstraction point of
view. This bakes into the firmware an implementation detail about how
something is implemented / enabled in the kernel, which feels wrong.
In general I'm not a fan of needing the kernel command line argument
to begin with and I'd hope that eventually it could go away.
3. Having the firmware inject `irqchip.gicv3_pseudo_nmi=1` into the
kernel command line also makes it awkward when you consider
non-affected boards. On Qualcomm boards, Rockchip boards, and x86
boards we want to enable pseudo NMI without needing to spin the
firmware to have it add this option. ...so we have to add this option
to the "default" command line for every board _except_ affected
Mediatek boards? Is this weird convention something that our build
system carries as we move to newer Mediatek SoCs that aren't affected?
What if we want a single build for Mediatek and Qulcomm boards (which
is something that has been bandied about, even if we haven't done it
yet).
Considering all the above, I think trying to use the
`irqchip.gicv3_pseudo_nmi=1` like this wouldn't fly.
> > For some details, you can also see the public bug
> > <https://issuetracker.google.com/281831288>
> >
> > Signed-off-by: Douglas Anderson <[email protected]>
> > ---
> >
> > .../bindings/interrupt-controller/arm,gic-v3.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > index 92117261e1e1..8c251caae537 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
> > @@ -166,6 +166,12 @@ properties:
> > resets:
> > maxItems: 1
> >
> > + mediatek,gicr-save-quirk:
>
> I think this deserves something *much* stronger that outlines what is
> wrong, because this is not just a quirk. This is a failure to even
> remotely grasp the requirements of the architecture (and to use
> standard, public code that would have done it correctly). Something
> like "mediatek,broken-save-restore-fw" would be more adequate.
Sure, I'll rename it in the next spin. Unless we get into a big
discussion somewhere else in this patch, I'll plan that for early next
week.
> > + type: boolean
> > + description:
> > + Asserts that the firmware on this device has issues saving and restoring
> > + GICR registers when CPUs are powered off.
>
> Nit: not the the CPUs, but the GIC redistributors.
Ah, good point. I'll update.
Hi,
On Fri, May 12, 2023 at 1:13 AM Marc Zyngier <[email protected]> wrote:
>
> On Thu, 11 May 2023 23:05:37 +0100,
> Douglas Anderson <[email protected]> wrote:
> >
> > 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: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile")
> > Signed-off-by: Douglas Anderson <[email protected]>
> > ---
> >
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 5169779d01df..39545172fce5 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -709,6 +709,7 @@ gic: interrupt-controller@c000000 {
> > <0 0x0c400000 0 0x2000>, /* GICC */
> > <0 0x0c410000 0 0x1000>, /* GICH */
> > <0 0x0c420000 0 0x2000>; /* GICV */
> > + mediatek,gicr-save-quirk;
>
> Is that something you can safely generalise at the SoC level? Are
> these SoC solely used on Chromebooks, and/or
Hmmm, I thought I checked to make sure that the only users of these
upstream were Chromebooks, but I just double-checked and I obviously
was blind yesterday. You're right that I need to fix this. I will move
these to:
mt8195-cherry.dtsi
mt8192-asurada.dtsi
mt8183-kukui.dtsi
...it looks as if the common "baseboard" dtsi for mt8186 Chromebooks
hasn't been upstreamed yet, so we'll have to keep an eye on that and
make sure it gets the property.
When I spin this series early next week I'll make that change.
> without any hope of
> seeing any alternative FW being already in use?
I haven't seen anyone try to fully replace the firmware of a
Chromebook in the past. It would be a lot of work, certainly. More
common, I'd think, would be someone chaining an extra level of loader
between the existing firmware and the OS. I _think_ I've seen people
use a stripped down U-Boot for this. However, the "resident" firmware
would still be the one that the Chromebook ships with.
Certainly someone could prove me wrong and re-implement the firmware
on one of these Chromebooks. That person would need to follow the same
convention or accept that their kernel won't be enabling pseudoNMIs.
-Doug
Il 12/05/23 00:05, Douglas Anderson ha scritto:
> 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: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile")
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5169779d01df..39545172fce5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -709,6 +709,7 @@ gic: interrupt-controller@c000000 {
> <0 0x0c400000 0 0x2000>, /* GICC */
> <0 0x0c410000 0 0x1000>, /* GICH */
> <0 0x0c420000 0 0x2000>; /* GICV */
> + mediatek,gicr-save-quirk;
Nit: Can you please move this after interrupts?
Thanks,
Angelo
>
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> ppi-partitions {