Re: [PATCH v7 08/11] arm_mpam: prepare mon_sel locking for MPAM-Fb
Ben Horgan <[email protected]> Mon, 3 Aug 2026 18:24:23 +0100
| Newsgroups | org.kernel.vger.linux-acpi,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Andre, On 7/31/26 18:03, Andre Przywara wrote: > The MSC MON_SEL register needs to be accessed from hardirq for the overflow > interrupt, and when taking an IPI to access these registers on platforms > where MSCs are not accesible from every CPU. This makes an irqsave > spinlock the obvious lock to protect these registers. On systems with > MPAM-Fb mailbox MSC access it must be able to sleep, meaning a mutex must > be used. So MPAM-Fb platforms cannot support an overflow interrupt easily. > Clearly these two methods can't exist for one MSC at the same time. > > Change the mon_sel locking wrapper function to only use a spinlock when > the MSC is accessed directly via MMIO. In case of MPAM-Fb, we use a > mutex, but only if we are in a sleepable context. If that's not the > case, we return an error. This should not happen, as MPAM-Fb by design > does not require an MSC access to happen from a specific CPU, so there > is no need for any IPIs or preemption disabling to satisfy CPU > constraints. And since overflow interrupts are not supported at the moment > anyway, we also wouldn't meet the other case. > Bailing out early is already happening in rare occasions today. > > Signed-off-by: Andre Przywara <[email protected]> > Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Ben Horgan <[email protected]> Thanks, Ben