linux-kernel - Re: [PATCH v2] Add support for Realtek RTL838x/RTL839x switch SoCs

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] [day] [month] [year] [list]

Message-ID: <87eejbpjpp.wl-maz@kernel.org>
Date:   Sun, 27 Dec 2020 11:33:06 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Bert Vermeulen <bert@...t.com>
Cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Rob Herring <robh+dt@...nel.org>,
        Paul Burton <paulburton@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Damien Le Moal <damien.lemoal@....com>,
        Mateusz Holenko <mholenko@...micro.com>,
        Stafford Horne <shorne@...il.com>,
        Pawel Czarnecki <pczarnecki@...ernships.antmicro.com>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Cédric Le Goater <clg@...d.org>,
        Shawn Guo <shawnguo@...nel.org>, Joel Stanley <joel@....id.au>,
        Leonard Crestez <leonard.crestez@....com>,
        Peng Fan <peng.fan@....com>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2] Add support for Realtek RTL838x/RTL839x switch SoCs

Bert,

On Sat, 26 Dec 2020 15:02:21 +0000,
Bert Vermeulen <bert@...t.com> wrote:
> 
> On 12/23/20 5:18 PM, Marc Zyngier wrote:
> >> +	/* Set up interrupt routing */
> >> +	writel(RTL8380_IRR0_SETTING, REG(RTL8380_IRR0));
> >> +	writel(RTL8380_IRR1_SETTING, REG(RTL8380_IRR1));
> >> +	writel(RTL8380_IRR2_SETTING, REG(RTL8380_IRR2));
> >> +	writel(RTL8380_IRR3_SETTING, REG(RTL8380_IRR3));
> > 
> > What is this doing?
> 
> It's fairly evident considering the comments -- routing of secondary
> IRQs onto the CPU IRQs.

The term "interrupt routing" is normally used when there is multiple
possible targets for a given interrupt, in general a SMP system. Given
that your toy SoC seems to be UP, using "interrupt routing" in this
context is anything *but* evident.

Moreover, since this "routing" is obviously SW controlled, how is that
going to work when the next system has a different mapping between
internal and external interrupts?

> But as to packing this into DTS I'm not sure.
> 
> DTS syntax being what it is, this would inevitably get more complex
> and harder to understand. Do you have an example where this is done in
> a better way?

The DT syntax is a lot clearer than the seemingly random bunch of
writes above, and has the invaluable advantage of being decoupled from
the driver code. If, as I suspect, the same IP block has been
copy-pasted across multiple implementations with different interrupt
mappings, we'll end up with an explosion of board-specific files,
which is exactly the problem DT has been tasked to solve.

If the DT model is not suitable for your particular use case, please
explain what doesn't work, and people will be more than eager to help.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.