From: Dave Martin <Dave.Martin@arm•com>
To: James Morse <james.morse@arm•com>
Cc: linux-kernel@vger•kernel.org,
linux-arm-kernel@lists•infradead.org, linux-acpi@vger•kernel.org,
devicetree@vger•kernel.org,
D Scott Phillips OS <scott@os•amperecomputing.com>,
carl@os•amperecomputing.com, lcherian@marvell•com,
bobo.shaobowang@huawei•com, tan.shaopeng@fujitsu•com,
baolin.wang@linux•alibaba.com,
Jamie Iles <quic_jiles@quicinc•com>,
Xin Hao <xhao@linux•alibaba.com>,
peternewman@google•com, dfustini@baylibre•com,
amitsinght@marvell•com, David Hildenbrand <david@redhat•com>,
Koba Ko <kobak@nvidia•com>,
Shanker Donthineni <sdonthineni@nvidia•com>,
fenghuay@nvidia•com, baisheng.gao@unisoc•com,
Jonathan Cameron <jonathan.cameron@huawei•com>,
Rob Herring <robh@kernel•org>,
Rohit Mathew <rohit.mathew@arm•com>,
Rafael Wysocki <rafael@kernel•org>, Len Brown <lenb@kernel•org>,
Lorenzo Pieralisi <lpieralisi@kernel•org>,
Hanjun Guo <guohanjun@huawei•com>,
Sudeep Holla <sudeep.holla@arm•com>,
Krzysztof Kozlowski <krzk+dt@kernel•org>,
Conor Dooley <conor+dt@kernel•org>,
Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
Greg Kroah-Hartman <gregkh@linuxfoundation•org>,
Danilo Krummrich <dakr@kernel•org>,
Ben Horgan <ben.horgan@arm•com>
Subject: Re: [PATCH 12/33] arm_mpam: Add the class and component structures for ris firmware described
Date: Tue, 9 Sep 2025 12:28:13 +0100 [thread overview]
Message-ID: <aMAPTVqb7fLfFH6R@e133380.arm.com> (raw)
In-Reply-To: <ff73df9c-8e77-471d-b0fb-205701b4d6d3@arm.com>
Hi,
On Mon, Sep 08, 2025 at 06:57:41PM +0100, James Morse wrote:
> Hi Dave,
>
> On 01/09/2025 12:09, Dave Martin wrote:
> >> Subject: arm_mpam: Add the class and component structures for ris firmware described
> >
> > Mangled subject line?
>
> order words hard is.
>
>
> > There is a fair intersection between the commit message and what the
> > patch does, but they don't quite seem to match up.
> >
> > Some key issues like locking / object lifecycle management
> > and DT parsing (a bit of which, it appears, lives here too) are not
> > mentioned at all.
>
> I don't think everything needs mentioning - you have the diff for that.This should capture
> the motivation, what you have and what you need to find, the grouping etc.
>
>
> > In lieu of a complete rewrite, it might be best to discard the
> > explanation of the various object types. The comment in the code
> > speaks for itself, and looks clearer.
>
> Fair enough,
OK
[...]
> >> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> >> index 71a1fb1a9c75..5baf2a8786fb 100644
> >> --- a/drivers/resctrl/mpam_devices.c
> >> +++ b/drivers/resctrl/mpam_devices.c
> >> @@ -20,7 +20,6 @@
> >
> > [...]
> >
> >> @@ -35,11 +34,483 @@
> >> static DEFINE_MUTEX(mpam_list_lock);
> >> static LIST_HEAD(mpam_all_msc);
> >>
> >> -static struct srcu_struct mpam_srcu;
> >> +struct srcu_struct mpam_srcu;
>
> > Why expose this here? This patch makes no use of the exposed symbol.
>
> The mpam_resctrl code needs to take it when it walks these lists. I don't want to change
> it then because its just additional churn.
I guess this is harmless, but it's no help to the kernel, or to
reviewers...
[...]
> >> +/*
> >> + * An MSC is a physical container for controls and monitors, each identified by
[...]
> >> + * The same MSC may exist under different class->component->vmsc paths, but the
> >> + * RIS index will be unique.
> >> + */
> >
> > This description of the structures and how they relate to each other
> > seems OK (bearing in mind that I am already familiar with this stuff --
> > I can't speak for other people).
>
> Great!
OK
[...]
> >> +static void mpam_ris_destroy(struct mpam_msc_ris *ris)
> >> +{
> >> + struct mpam_vmsc *vmsc = ris->vmsc;
> >> + struct mpam_msc *msc = vmsc->msc;
> >> + struct platform_device *pdev = msc->pdev;
> >> + struct mpam_component *comp = vmsc->comp;
> >> + struct mpam_class *class = comp->class;
> >> +
> >> + lockdep_assert_held(&mpam_list_lock);
> >> +
> >> + cpumask_andnot(&comp->affinity, &comp->affinity, &ris->affinity);
> >> + cpumask_andnot(&class->affinity, &class->affinity, &ris->affinity);
> >
> > This is not the inverse of the cpumask_or()s in mpam_ris_create_locked(),
> > unless the the ris associated with each class and each component have
> > strictly disjoint affinity masks. Is that checked anywhere, or should
> > it be impossible by construction?
>
> They should be disjoint. These bitmaps are built from firmware description of the cache
> hierarchy. I don't think its possible to describe a situation where there are overlaps.
>
> You can build a nonsense cache hierarchy, e.g. where CPU-0's L3 is CPU-6's L2, but if you
> do the scheduler is going to complain when it tries to chose the scheduler domains. I
> think this should be filed under "you've got bigger problems". There is a check that
> catches this in mpam_resctrl_pick_caches(), to see that all the CPUs are accounted for,
> which is to avoid tasks that get lucky with task-placement managing to escape their
> resource limit.
I guess that makes sense.
If the firmware description is formally a tree structure then it should
be impossible to end up with overlapping affinity masks.
Since this doesn't bite us until teardown-time in any case, I think
this probably doesn't need to be checked explicitly, unless we observe
actual problems.
A comment documenting this assumption may be worth having.
> > But, thinking about it:
> >
> > I wonder why we ever really need to do the teardown. If we get an
> > error interrupt then we can just go into a sulk, spam dmesg a bit, put
> > the hardware into the most vanilla state that we can, and refuse to
> > manipulate it further. But this only happens in the case of a software
> > or hardware *bug* (or, in a future world where we might implement
> > virtualisation, an uncontainable MPAM error triggered by a guest -- for
> > which tearing down the host MPAM would be an overreaction).
>
> The good news is guests can't escape the PARTID virtualisation that the CPU does, so any
> mess a guest manages to make is confined to that guest's PARTID range.
>
>
> > Trying to cleanly tear the MPAM driver down after such an error seems a
> > bit futile.
> >
> > The MPAM resctrl glue could eventually be made into a module (though
> > not needed from day 1) -- which would allow for unloading resctrlfs if
> > that is eventually module-ised. I think this wouldn't require the MPAM
> > devices backend to be torn down at any point, though (?)
>
> It would certainly be optional. kernfs->resctrl->mpam is the reason all this has to be
> built-in. If that changes I'd aim for this to be a module.
>
> All this free()ing was added so that the driver doesn't end up sitting on memory when it
> isn't providing any usable feature. I have seen a platform where the error interrupt goes
I guess that's reasonable, but this is only applies to hardware that
has MPAM but where it is either broken, or where it is unsuitable for
running Linux but Linux has been deployed on it anyway while still
leaving the ACPI tables intact. This does not violate any
specification, but it seems of marginal benefit to introduce a load of
complexity just to safe a few K in this situation. (Or do we get stuck,
unable to free the config and mbwu_state arrays? Those don't count as
large on a server-class system, but they are about the "a few K"
magnitude.)
(Not that I'm not saying that teardown is something we shouldn't do --
rather, my point is: do we really need to do it now if it is subtle and
complex to make it work, or can this be a later addition?)
> off during boot, (I suspect firmware configures an out-of-range PARTID). On such a
> platform any memory that isn't free()d is a waste.
>
> But I agree its a small amount of memory.
>
>
> > If we can simplify or eliminate the teardown, does it simplify the
> > locking at all? The garbage collection logic can also be dispensed
> > with if there is never any garbage.
>
> It wouldn't simplify the locking, only remove that deferred free()ing which is needed
> because of SRCU.
My point was that there is no need to defend against concurrent removal
if list entries if list entries are never removed.
> > Since MSCs etc. never disappear from the hardware, it feels like it
> > ought not to be necessary ever to remove items from any of these lists
> > except when trying to do a teardown (?)
>
> Unbinding the driver from an MSC is another case where this may be triggered via
> mpam_msc_drv_remove(). If you look at the whole thing, mpam_ris_destroy() pokes
> mpam_resctrl_teardown_class() to see if resctrl needs to be torn down.
>
> I don't anticipate folk actually needing to do that. One Reasons is for VFIO - but this
> kind of stuff has a performance impact on the hypervisor, so its unlikely to ever allow a
> guest direct access to this kind of thing. Another reason is to load a more specific
> driver, which sounds unlikely.
>
>
> Ultimately this memory free-ing code is here because its the right thing to do.
> I'd prefer to keep it as making this a loadable module would mean we have to do this.
I don't disagree with that: it is messy to retrofit teardown if it was
never considered in the initial design.
I guess that this all comes from my uncertainty about the object
lifecycles and locking behaviour.
I would still prefer to see this documented. If the the documentation
would be too unwieldy or infrasible to write, this would suggest that
the code would benefit from simplification...
For the probe phase, or for teardown, I'm really not sure why it would
break anything to have a single Big MPAM Lock (however inelegant).
For the run phase (when resctrl and other clients of the driver are
able to use the driver), the discovered system properties and the
mappings onto resctrl resources are all static, and we don't seem to
need all this RCU stuff.
> > (Putting the hardware into a quiecent state is not the same thing as
> > tearing down the data structures -- we do want to quiesce MPAM when
> > shutting down the kernel, as least for the kexec scenario.)
>
> > [...]
> >
> >> +static int mpam_ris_create_locked(struct mpam_msc *msc, u8 ris_idx,
> >> + enum mpam_class_types type, u8 class_id,
> >> + int component_id, gfp_t gfp)
> >> +{
> >> + int err;
> >> + struct mpam_vmsc *vmsc;
> >> + struct mpam_msc_ris *ris;
> >> + struct mpam_class *class;
> >> + struct mpam_component *comp;
> >> +.
> >> + lockdep_assert_held(&mpam_list_lock);
> >> +
> >> + if (test_and_set_bit(ris_idx, msc->ris_idxs))
> >> + return -EBUSY;
> >
> > Is it impossible by construction to get in here with an out-of-range
> > ris_idx?
> >
> > To avoid the callers (i.e., ACPI) needing to understand the internal
> > limitations of this code, maybe it is worth having a check here (even
> > if technically redundant).
>
> It's possible - but only if you mess up the firmware tables.
> I'll add a check for this as its easy enough.
OK, suits me.
Cheers
---Dave
next prev parent reply other threads:[~2025-09-09 17:15 UTC|newest]
Thread overview: 200+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 15:29 [PATCH 00/33] arm_mpam: Add basic mpam driver James Morse
2025-08-22 15:29 ` [PATCH 01/33] cacheinfo: Expose the code to generate a cache-id from a device_node James Morse
2025-08-27 10:46 ` Dave Martin
2025-08-27 17:11 ` James Morse
2025-08-28 14:08 ` Dave Martin
2025-08-22 15:29 ` [PATCH 02/33] drivers: base: cacheinfo: Add helper to find the cache size from cpu+level James Morse
2025-08-24 17:25 ` Krzysztof Kozlowski
2025-08-27 17:11 ` James Morse
2025-08-27 10:46 ` Dave Martin
2025-08-27 17:11 ` James Morse
2025-08-28 14:10 ` Dave Martin
2025-09-05 16:19 ` Dave Martin
2025-08-22 15:29 ` [PATCH 03/33] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-08-26 14:45 ` Ben Horgan
2025-08-28 15:56 ` James Morse
2025-08-27 10:48 ` Dave Martin
2025-08-28 15:57 ` James Morse
2025-09-05 16:24 ` Dave Martin
2025-09-10 19:29 ` James Morse
2025-08-22 15:29 ` [PATCH 04/33] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-08-27 10:49 ` Dave Martin
2025-08-28 15:57 ` James Morse
2025-09-09 10:06 ` Dave Martin
2025-08-22 15:29 ` [PATCH 05/33] ACPI / PPTT: Find cache level by cache-id James Morse
2025-08-23 12:14 ` Markus Elfring
2025-08-28 15:57 ` James Morse
2025-08-27 9:25 ` Ben Horgan
2025-08-28 15:57 ` James Morse
2025-08-27 10:50 ` Dave Martin
2025-08-28 15:58 ` James Morse
2025-09-05 16:27 ` Dave Martin
2025-09-10 19:29 ` James Morse
2025-08-22 15:29 ` [PATCH 06/33] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-08-27 10:53 ` Dave Martin
2025-08-28 15:58 ` James Morse
2025-09-09 10:14 ` Dave Martin
2025-09-10 19:29 ` James Morse
2025-08-22 15:29 ` [PATCH 07/33] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-08-27 8:53 ` Ben Horgan
2025-08-28 15:58 ` James Morse
2025-08-29 8:20 ` Ben Horgan
2025-08-27 11:01 ` Dave Martin
2025-09-04 17:28 ` James Morse
2025-09-09 10:26 ` Dave Martin
2025-08-22 15:29 ` [PATCH 08/33] ACPI / MPAM: Parse the MPAM table James Morse
2025-08-23 10:55 ` Markus Elfring
2025-09-04 17:28 ` James Morse
2025-08-27 16:05 ` Dave Martin
2025-09-04 17:28 ` James Morse
2025-09-05 16:38 ` Dave Martin
2025-09-10 19:19 ` James Morse
2025-08-22 15:29 ` [PATCH 09/33] dt-bindings: arm: Add MPAM MSC binding James Morse
2025-08-27 16:22 ` Dave Martin
2025-09-05 9:11 ` James Morse
2025-09-09 11:02 ` Dave Martin
2025-08-22 15:29 ` [PATCH 10/33] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-08-22 19:15 ` Markus Elfring
2025-08-22 19:55 ` Markus Elfring
2025-08-23 6:41 ` Greg Kroah-Hartman
2025-08-27 13:03 ` Ben Horgan
2025-09-05 18:48 ` James Morse
2025-09-08 10:54 ` Ben Horgan
2025-08-27 15:39 ` Rob Herring
2025-08-27 16:16 ` Rob Herring
2025-09-05 18:52 ` James Morse
2025-09-05 18:52 ` James Morse
2025-09-01 9:11 ` Ben Horgan
2025-09-05 18:49 ` James Morse
2025-09-01 11:21 ` Dave Martin
2025-09-05 18:49 ` James Morse
2025-09-08 15:25 ` Dave Martin
2025-09-10 19:19 ` James Morse
2025-08-22 15:29 ` [PATCH 11/33] arm_mpam: Add support for memory controller MSC on DT platforms James Morse
2025-08-22 15:29 ` [PATCH 12/33] arm_mpam: Add the class and component structures for ris firmware described James Morse
2025-08-28 1:29 ` Fenghua Yu
2025-09-08 17:57 ` James Morse
2025-09-01 11:09 ` Dave Martin
2025-09-08 17:57 ` James Morse
2025-09-09 11:28 ` Dave Martin [this message]
2025-09-10 19:19 ` James Morse
2025-08-22 15:29 ` [PATCH 13/33] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-08-29 8:42 ` Ben Horgan
2025-09-08 17:57 ` James Morse
2025-09-09 11:36 ` Shaopeng Tan (Fujitsu)
2025-09-10 19:31 ` James Morse
2025-08-22 15:29 ` [PATCH 14/33] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-08-27 16:08 ` Rob Herring
2025-09-08 17:58 ` James Morse
2025-09-05 16:40 ` Dave Martin
2025-09-09 16:56 ` James Morse
2025-09-09 14:23 ` Dave Martin
2025-08-22 15:29 ` [PATCH 15/33] arm_mpam: Probe MSCs to find the supported partid/pmg values James Morse
2025-08-28 13:12 ` Ben Horgan
2025-09-09 16:56 ` James Morse
2025-09-10 9:01 ` Ben Horgan
2025-09-08 16:29 ` Dave Martin
2025-09-09 16:57 ` James Morse
2025-08-22 15:29 ` [PATCH 16/33] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-08-28 17:07 ` Fenghua Yu
2025-09-09 16:57 ` James Morse
2025-09-09 15:39 ` Dave Martin
2025-09-10 19:19 ` James Morse
2025-08-22 15:29 ` [PATCH 17/33] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-08-28 13:44 ` Ben Horgan
2025-09-09 16:57 ` James Morse
2025-09-10 9:11 ` Ben Horgan
2025-08-22 15:29 ` [PATCH 18/33] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-08-29 13:54 ` Ben Horgan
2025-09-09 16:57 ` James Morse
2025-08-22 15:30 ` [PATCH 19/33] arm_mpam: Reset MSC controls from cpu hp callbacks James Morse
2025-08-27 16:19 ` Ben Horgan
2025-09-09 16:57 ` James Morse
2025-08-22 15:30 ` [PATCH 20/33] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-08-28 16:13 ` Ben Horgan
2025-09-09 16:57 ` James Morse
2025-08-22 15:30 ` [PATCH 21/33] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-08-29 14:30 ` Ben Horgan
2025-09-09 16:58 ` James Morse
2025-08-22 15:30 ` [PATCH 22/33] arm_mpam: Register and enable IRQs James Morse
2025-09-09 16:58 ` James Morse
2025-08-22 15:30 ` [PATCH 23/33] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-08-22 15:30 ` [PATCH 24/33] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-08-28 16:13 ` Ben Horgan
2025-09-10 19:29 ` James Morse
2025-08-22 15:30 ` [PATCH 25/33] arm_mpam: Probe and reset the rest of the features James Morse
2025-08-28 10:11 ` Ben Horgan
2025-09-10 19:30 ` James Morse
2025-08-22 15:30 ` [PATCH 26/33] arm_mpam: Add helpers to allocate monitors James Morse
2025-08-29 15:47 ` Ben Horgan
2025-08-22 15:30 ` [PATCH 27/33] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-08-29 15:55 ` Ben Horgan
2025-09-10 19:30 ` James Morse
2025-08-22 15:30 ` [PATCH 28/33] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-08-29 16:09 ` Ben Horgan
2025-08-22 15:30 ` [PATCH 29/33] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-08-28 16:14 ` Ben Horgan
2025-09-10 19:30 ` James Morse
2025-08-22 15:30 ` [PATCH 30/33] arm_mpam: Use long MBWU counters if supported James Morse
2025-08-29 16:39 ` Ben Horgan
2025-09-10 19:30 ` James Morse
2025-08-22 15:30 ` [PATCH 31/33] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-08-22 15:30 ` [PATCH 32/33] arm_mpam: Add kunit test for bitmap reset James Morse
2025-08-29 16:56 ` Ben Horgan
2025-09-10 19:30 ` James Morse
2025-08-22 15:30 ` [PATCH 33/33] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-08-29 17:11 ` Ben Horgan
2025-09-10 19:31 ` James Morse
2025-08-22 15:30 ` [PATCH 00/33] arm_mpam: Add basic mpam driver James Morse
2025-08-22 15:30 ` [PATCH 01/33] cacheinfo: Expose the code to generate a cache-id from a device_node James Morse
2025-08-22 15:30 ` [PATCH 02/33] drivers: base: cacheinfo: Add helper to find the cache size from cpu+level James Morse
2025-08-22 15:30 ` [PATCH 03/33] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-08-22 15:30 ` [PATCH 04/33] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-09-10 13:44 ` Lorenzo Pieralisi
2025-09-10 19:19 ` James Morse
2025-08-22 15:30 ` [PATCH 05/33] ACPI / PPTT: Find cache level by cache-id James Morse
2025-08-22 15:30 ` [PATCH 06/33] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-09-10 16:06 ` Lorenzo Pieralisi
2025-09-10 19:18 ` James Morse
2025-08-22 15:30 ` [PATCH 07/33] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-08-22 15:30 ` [PATCH 08/33] ACPI / MPAM: Parse the MPAM table James Morse
2025-09-09 6:54 ` Shaopeng Tan (Fujitsu)
2025-09-10 19:31 ` James Morse
2025-08-22 15:30 ` [PATCH 09/33] dt-bindings: arm: Add MPAM MSC binding James Morse
2025-08-22 15:30 ` [PATCH 10/33] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-09-09 7:03 ` Shaopeng Tan (Fujitsu)
2025-09-10 19:31 ` James Morse
2025-08-22 15:30 ` [PATCH 11/33] arm_mpam: Add support for memory controller MSC on DT platforms James Morse
2025-09-09 7:11 ` Shaopeng Tan (Fujitsu)
2025-09-10 19:31 ` James Morse
2025-08-22 15:30 ` [PATCH 12/33] arm_mpam: Add the class and component structures for ris firmware described James Morse
2025-08-29 12:41 ` Ben Horgan
2025-09-10 19:32 ` James Morse
2025-09-09 7:30 ` Shaopeng Tan (Fujitsu)
2025-09-10 19:32 ` James Morse
2025-08-22 15:30 ` [PATCH 13/33] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-08-22 15:30 ` [PATCH 14/33] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-08-22 15:30 ` [PATCH 15/33] arm_mpam: Probe MSCs to find the supported partid/pmg values James Morse
2025-08-22 15:30 ` [PATCH 16/33] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-08-22 15:30 ` [PATCH 17/33] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-08-22 15:30 ` [PATCH 18/33] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-08-22 15:30 ` [PATCH 19/33] arm_mpam: Reset MSC controls from cpu hp callbacks James Morse
2025-08-22 15:30 ` [PATCH 20/33] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-08-22 15:30 ` [PATCH 21/33] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-08-22 15:30 ` [PATCH 22/33] arm_mpam: Register and enable IRQs James Morse
2025-09-01 10:05 ` Ben Horgan
2025-08-22 15:30 ` [PATCH 23/33] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-08-22 15:30 ` [PATCH 24/33] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-08-22 15:30 ` [PATCH 25/33] arm_mpam: Probe and reset the rest of the features James Morse
2025-08-22 15:30 ` [PATCH 26/33] arm_mpam: Add helpers to allocate monitors James Morse
2025-08-22 15:30 ` [PATCH 27/33] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-08-22 15:30 ` [PATCH 28/33] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-08-28 0:58 ` Fenghua Yu
2025-09-10 19:29 ` James Morse
2025-08-22 15:30 ` [PATCH 29/33] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-08-22 15:30 ` [PATCH 30/33] arm_mpam: Use long MBWU counters if supported James Morse
2025-08-22 15:30 ` [PATCH 31/33] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-08-22 15:30 ` [PATCH 32/33] arm_mpam: Add kunit test for bitmap reset James Morse
2025-08-22 15:30 ` [PATCH 33/33] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-09-02 16:59 ` Fenghua Yu
2025-08-24 17:24 ` [PATCH 00/33] arm_mpam: Add basic mpam driver Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMAPTVqb7fLfFH6R@e133380.arm.com \
--to=dave.martin@arm$(echo .)com \
--cc=amitsinght@marvell$(echo .)com \
--cc=baisheng.gao@unisoc$(echo .)com \
--cc=baolin.wang@linux$(echo .)alibaba.com \
--cc=ben.horgan@arm$(echo .)com \
--cc=bobo.shaobowang@huawei$(echo .)com \
--cc=carl@os$(echo .)amperecomputing.com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=conor+dt@kernel$(echo .)org \
--cc=dakr@kernel$(echo .)org \
--cc=david@redhat$(echo .)com \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=dfustini@baylibre$(echo .)com \
--cc=fenghuay@nvidia$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=guohanjun@huawei$(echo .)com \
--cc=james.morse@arm$(echo .)com \
--cc=jonathan.cameron@huawei$(echo .)com \
--cc=kobak@nvidia$(echo .)com \
--cc=krzk+dt@kernel$(echo .)org \
--cc=lcherian@marvell$(echo .)com \
--cc=lenb@kernel$(echo .)org \
--cc=linux-acpi@vger$(echo .)kernel.org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=lpieralisi@kernel$(echo .)org \
--cc=peternewman@google$(echo .)com \
--cc=quic_jiles@quicinc$(echo .)com \
--cc=rafael@kernel$(echo .)org \
--cc=robh@kernel$(echo .)org \
--cc=rohit.mathew@arm$(echo .)com \
--cc=scott@os$(echo .)amperecomputing.com \
--cc=sdonthineni@nvidia$(echo .)com \
--cc=sudeep.holla@arm$(echo .)com \
--cc=tan.shaopeng@fujitsu$(echo .)com \
--cc=will@kernel$(echo .)org \
--cc=xhao@linux$(echo .)alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox