Re: [PATCH v3 13/16] arm_mpam: prepare mon_sel locking for MPAM-Fb

[Andre Przywara]

Hi,

On 7/10/26 21:14, Jonathan Cameron wrote:
> On Fri, 10 Jul 2026 16:45:17 +0200
> Andre Przywara <andre.przywara@xxxxxxx> 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 MSC are not accesible from every CPU. This makes an irqsave
> > spinlock the obvious lock to protect these registers. On systems with SCMI
> > mailboxes it must be able to sleep, meaning a mutex must be used. The
> > SCMI platforms can't support an overflow interrupt.
> > Clearly these two 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.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
>
> I've not been paying attention to this topic, so I might come back
> with some more feedback after I've had time to think about it a bit!
> So trivial stuff only for now.
>
> >   
> >   static inline void mpam_mon_sel_lock_init(struct mpam_msc *msc)
> >   {
> >   	raw_spin_lock_init(&msc->_mon_sel_lock);
> > +	mutex_init(&msc->mon_sel_mutex);
>
> I'm not that fussed, but maybe add a call to mutex_destroy().
> Most likely it'll never help catch anything in this code though..

I figured I can follow the rest of the code and extract the dev pointer 
from struct mpam_msc, then use devm_mutex_init().

Cheers,
Andre

> >   }
> >   
> >   /* Bits for mpam features bitmaps */