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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87o85kk1ko.wl-maz@kernel.org>
Date:   Mon, 13 Dec 2021 14:43:19 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Hector Martin <marcan@...can.st>
Cc:     linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
        Will Deacon <will@...nel.org>, 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 Sun, 12 Dec 2021 07:30:20 +0000,
Hector Martin <marcan@...can.st> wrote:
> 
> On 01/12/2021 22.49, 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.
> > 
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > ---
> >   drivers/irqchip/irq-apple-aic.c | 14 ++++++++++++++
> >   1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c
> > index 3759dc36cc8f..30ca80ccda8b 100644
> > --- a/drivers/irqchip/irq-apple-aic.c
> > +++ b/drivers/irqchip/irq-apple-aic.c
> > @@ -177,6 +177,8 @@ struct aic_irq_chip {
> >   	void __iomem *base;
> >   	struct irq_domain *hw_domain;
> >   	struct irq_domain *ipi_domain;
> > +	struct cpumask ecore_mask;
> > +	struct cpumask pcore_mask;
> >   	int nr_hw;
> >   	int ipi_hwirq;
> >   };
> > @@ -200,6 +202,11 @@ static void aic_ic_write(struct aic_irq_chip *ic, u32 reg, u32 val)
> >   	writel_relaxed(val, ic->base + reg);
> >   }
> >   +static bool __is_pcore(u64 mpidr)
> > +{
> > +	return MPIDR_AFFINITY_LEVEL(mpidr, 2) == 1;
> > +}
> > +
> >   /*
> >    * IRQ irqchip
> >    */
> > @@ -833,6 +840,13 @@ static int __init aic_of_ic_init(struct device_node *node, struct device_node *p
> >   		return -ENODEV;
> >   	}
> >   +	for_each_possible_cpu(i) {
> > +		if (__is_pcore(cpu_logical_map(i)))
> > +			cpumask_set_cpu(i, &irqc->pcore_mask);
> > +		else
> > +			cpumask_set_cpu(i, &irqc->ecore_mask);
> > +	}
> > +
> >   	set_handle_irq(aic_handle_irq);
> >   	set_handle_fiq(aic_handle_fiq);
> >   
> 
> I'm okay with this approach, but if we want to be more explicit about
> the affinities, maybe something like apple,pmu-irq-index in the CPU
> nodes? Then we can either start at a higher FIQ offset for these (in
> case we need to add more FIQs in the future), or just make up a new
> AIC_PMU top level interrupt type and start at 0.

I'm actually worried that we'll need more of these "asymmetric FIQs"
in the future, and that the PMU-specific hack won't scale.

Do you know of any other per-CPU device that could differ between
small and big cores? This would certainly help guiding my
implementation between a device specific hack (the PMU irq index) or
something more generic (interrupt specifier containing the affinity
and following the AICv2 scheme).

Thanks,

	M.

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