linux-kernel - Re: [PATCH v6 7/7] arm64: dts: mediatek: Initial mt8365-evk support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 1 Jan 2023 22:57:58 +0100
From:   Bernhard Rosenkränzer <bero@...libre.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        matthias.bgg@...il.com, krzysztof.kozlowski+dt@...aro.org,
        robh+dt@...nel.org, gregkh@...uxfoundation.org,
        chunfeng.yun@...iatek.com, linus.walleij@...aro.org,
        lee@...nel.org, tglx@...utronix.de,
        angelogioacchino.delregno@...labora.com
Subject: Re: [PATCH v6 7/7] arm64: dts: mediatek: Initial mt8365-evk support

On Fri, Dec 30, 2022 at 11:41 PM Marc Zyngier <maz@...nel.org> wrote:
> > +             gic: interrupt-controller@...0000 {
> > +                     compatible = "arm,gic-v3";
> > +                     #interrupt-cells = <4>;
>
> Why 4 cells? All the SPIs routed via sysirq are perfectly happy with 3
> cells, and all the PPIs have 0 for the 4th cell (none of them use any
> form of partitioning that'd require 4 cells). So where is this coming
> from?

It's coming from the SoC vendor kernel (and went unnoticed because it
happens to work).
Will send an updated version that does the right thing instead. I've
been running it most of the day, so far looking good.

> > +                     interrupt-parent = <&gic>;
> > +                     interrupt-controller;
> > +                     reg = <0 0x0c000000 0 0x80000>, <0 0x0c080000 0 0x80000>;
> > +
>
> The first region is obviously wrong (512kB for the distributor?
> that's... most generous, but the architecture states that it is 64kB,
> and that's wasteful enough).
>
> This is also missing the GICC/GICH/GICV regions that Cortex-A53
> implements, and that must be provided as per the binding.

This was also taken from the vendor kernel; unfortunately neiter the
datasheet for the SoC not the vendor kernel specifies the addresses
for GICC/GICH/GICV.
I've "guessed" based on what's in similar SoCs (MT8183, MT7986a) in
v7; this seems to work (boots, kvm initializes hyp mode properly).

ttyl
bero