[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d0e2a08e-79d6-03e8-09a2-bb634fa3c23c@marcan.st>
Date: Mon, 28 Feb 2022 00:33:54 +0900
From: Hector Martin <marcan@...can.st>
To: Marc Zyngier <maz@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Rob Herring <robh+dt@...nel.org>,
Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Mark Kettenis <mark.kettenis@...all.nl>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 3/7] irqchip/apple-aic: Add Fast IPI support
On 25/02/2022 23.39, Marc Zyngier wrote:
> On Thu, 24 Feb 2022 13:07:37 +0000,
>> if (!(pending & irq_bit) &&
>> - (atomic_read(per_cpu_ptr(&aic_vipi_enable, cpu)) & irq_bit))
>> - send |= AIC_IPI_SEND_CPU(cpu);
>> + (atomic_read(per_cpu_ptr(&aic_vipi_enable, cpu)) & irq_bit)) {
>> + if (static_branch_likely(&use_fast_ipi))
>> + aic_ipi_send_fast(cpu);
>
> OK, this is suffering from the same issue that GICv3 has, which is
> that memory barriers don't provide order against sysregs. You need a
> DSB for that, which is a pain. Something like this:
Doesn't the control flow here guarantee the ordering? atomic_read() must
complete before the sysreg is written since there is a control flow
dependency, and the prior atomic/barrier dance ensures that read is
ordered properly with everything that comes before it.
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists