linux-kernel - Re: [PATCH v2 3/8] irqchip/apple-aic: Add cpumasks for E and P cores

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87zgphlkdx.wl-maz@kernel.org>
Date:   Fri, 03 Dec 2021 16:32:10 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Will Deacon <will@...nel.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dougall <dougallj@...il.com>, kernel-team@...roid.com
Subject: Re: [PATCH v2 3/8] irqchip/apple-aic: Add cpumasks for E and P cores

On Wed, 01 Dec 2021 16:08:13 +0000,
Mark Rutland <mark.rutland@....com> wrote:
> 
> On Wed, Dec 01, 2021 at 01:49:04PM +0000, Marc Zyngier wrote:
> > In order to be able to tell the core IRQ code about the affinity
> > of the PMU interrupt in later patches, compute the cpumasks of the
> > P and E cores at boot time.
> > 
> > This relies on the affinity scheme used by the vendor, which seems
> > to work for the couple of SoCs that are out in the wild.
> 
> ... but may change at any arbitrary point in future?

Crystal balls are in short supply, sorry! ;-)

> Can we please put the affinity in the DT, like we do for other SoCs and
> devices?
> 
> I don't think we should treat this HW specially in this regard; we certaintly
> don't want other folk hard-coding system topology in their irqchip driver, and
> it should be possible to do something like the ppi-partitions binding, no?

The PPI partition is totally overkill here. What it deals with is
multiple devices sharing a single PPI across the system.

Here, we can invent our own interrupt number, so the sharing is
avoided by construction (the joy of not having an interrupt controller
the first place!).

I'm happy to stick the affinity in the DT (after all, it is likely
that other devices on these systems have the same requirements) and
have it consumed by the irqchip driver. I only need to find a way that
doesn't completely invalidate the existing binding...

	M.

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