From nobody Mon Feb 9 01:16:44 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D0FC12F5C5B for ; Fri, 11 Jul 2025 18:38:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752259088; cv=none; b=NySdkWUeqx8bldNw3ZyZqodSh0+CtmEKoB5KlFe+S3xtUSLCZQkeB8hqWhhD6Wk7blPz6XtCcy5h1S8U3zHYKo2/mk1w2pcypbHlEizh2LfIGNVRIOEBVUDxTYTK671/lahaX5kiq7/LiDLiIsAuuGd6/KcMknAohUhXKqW+GJI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752259088; c=relaxed/simple; bh=PRQRxwjNemBtoCZvDMCdZfl3sCMtxUidnJ27lwLZdbI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=raWteJvDDpDBy+hYVHrMvIKVG/Nxd/myVY7izShf525ZKJzYhvSpELg06RCIvQFyCcklxyOTu+9p4RyQlXtyL70lJpfjF/po5dpShXDVIkZephGhOsAOxMiDWWYw8N/6ErI3qDdZF8OKnT60xY05lxWCrYFuSQi9nMFEiQPAgP0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B7D592247; Fri, 11 Jul 2025 11:37:55 -0700 (PDT) Received: from merodach.members.linode.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4F8273F694; Fri, 11 Jul 2025 11:38:03 -0700 (PDT) From: James Morse To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Rob Herring , Ben Horgan , Rohit Mathew , Shanker Donthineni , Zeng Heng , Lecopzer Chen , Carl Worth , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Koba Ko , James Morse Subject: [RFC PATCH 19/36] arm_mpam: Add helpers for managing the locking around the mon_sel registers Date: Fri, 11 Jul 2025 18:36:31 +0000 Message-Id: <20250711183648.30766-20-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20250711183648.30766-1-james.morse@arm.com> References: <20250711183648.30766-1-james.morse@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The MSC MON_SEL register needs to be accessed from hardirq context by the PMU drivers, making 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. Clearly these two can't exist at the same time. Add helpers for the MON_SEL locking. The outer lock must be taken in a pre-emptible context before the inner lock can be taken. On systems with SCMI mailboxes where the MON_SEL accesses must sleep - the inner lock will fail to be 'taken' if the caller is unable to sleep. This will allow the PMU driver to fail without having to check the interface type of each MSC. Signed-off-by: James Morse --- drivers/platform/arm64/mpam/mpam_internal.h | 57 ++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) diff --git a/drivers/platform/arm64/mpam/mpam_internal.h b/drivers/platform= /arm64/mpam/mpam_internal.h index eb5cc6775d54..42a454d5f914 100644 --- a/drivers/platform/arm64/mpam/mpam_internal.h +++ b/drivers/platform/arm64/mpam/mpam_internal.h @@ -68,10 +68,19 @@ struct mpam_msc { =20 /* * mon_sel_lock protects access to the MSC hardware registers that are - * affeted by MPAMCFG_MON_SEL. + * affected by MPAMCFG_MON_SEL, and the mbwu_state. + * Both the 'inner' and 'outer' must be taken. + * For real MMIO MSC, the outer lock is unnecessary - but keeps the + * code common with: + * Firmware backed MSC need to sleep when accessing the MSC, which + * means some code-paths will always fail. For these MSC the outer + * lock is providing the protection, and the inner lock fails to + * be taken if the task is unable to sleep. + * * If needed, take msc->probe_lock first. */ struct mutex outer_mon_sel_lock; + bool outer_lock_held; raw_spinlock_t inner_mon_sel_lock; unsigned long inner_mon_sel_flags; =20 @@ -81,6 +90,52 @@ struct mpam_msc { struct mpam_garbage garbage; }; =20 +static inline bool __must_check mpam_mon_sel_inner_lock(struct mpam_msc *m= sc) +{ + /* + * The outer lock may be taken by a CPU that then issues an IPI to run + * a helper that takes the inner lock. lockdep can't help us here. + */ + WARN_ON_ONCE(!msc->outer_lock_held); + + if (msc->iface =3D=3D MPAM_IFACE_MMIO) { + raw_spin_lock_irqsave(&msc->inner_mon_sel_lock, msc->inner_mon_sel_flags= ); + return true; + } + + /* Accesses must fail if we are not pre-emptible */ + return !!preemptible(); +} + +static inline void mpam_mon_sel_inner_unlock(struct mpam_msc *msc) +{ + WARN_ON_ONCE(!msc->outer_lock_held); + + if (msc->iface =3D=3D MPAM_IFACE_MMIO) + raw_spin_unlock_irqrestore(&msc->inner_mon_sel_lock, msc->inner_mon_sel_= flags); +} + +static inline void mpam_mon_sel_outer_lock(struct mpam_msc *msc) +{ + mutex_lock(&msc->outer_mon_sel_lock); + msc->outer_lock_held =3D true; +} + +static inline void mpam_mon_sel_outer_unlock(struct mpam_msc *msc) +{ + msc->outer_lock_held =3D false; + mutex_unlock(&msc->outer_mon_sel_lock); +} + +static inline void mpam_mon_sel_lock_held(struct mpam_msc *msc) +{ + WARN_ON_ONCE(!msc->outer_lock_held); + if (msc->iface =3D=3D MPAM_IFACE_MMIO) + lockdep_assert_held_once(&msc->inner_mon_sel_lock); + else + lockdep_assert_preemption_enabled(); +} + struct mpam_class { /* mpam_components in this class */ struct list_head components; --=20 2.39.5