[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87frktoo16.ffs@tglx>
Date: Tue, 04 Feb 2025 14:08:37 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Anup Patel <apatel@...tanamicro.com>
Cc: Marc Zyngier <maz@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Sascha
Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team
<kernel@...gutronix.de>, Andrew Lunn <andrew@...n.ch>, Gregory Clement
<gregory.clement@...tlin.com>, Sebastian Hesselbarth
<sebastian.hesselbarth@...il.com>, Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>, Atish Patra
<atishp@...shpatra.org>, Andrew Jones <ajones@...tanamicro.com>, Sunil V L
<sunilvl@...tanamicro.com>, Anup Patel <anup@...infault.org>,
linux-riscv@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, imx@...ts.linux.dev, Anup Patel
<apatel@...tanamicro.com>
Subject: Re: [PATCH v3 01/10] irqchip/riscv-imsic: Handle non-atomic MSI
updates for device
On Tue, Feb 04 2025 at 13:23, Anup Patel wrote:
> Device having non-atomic MSI update might see an intermediate
> state when changing target IMSIC vector from one CPU to another.
>
> To handle such intermediate device state, update MSI address
> and MSI data through separate MSI writes to the device.
As pointed out in the other mail, this intermediate step does not fix
the issue. It requires that the MSI message write happens on the
original target CPU so that an interrupt which is raised on that
intermediate vector can be observed.
Thanks,
tglx
Powered by blists - more mailing lists