public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.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>,
	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>,
	Dave Martin <dave.martin@arm.com>, Koba Ko <kobak@nvidia.com>,
	Shanker Donthineni <sdonthineni@nvidia.com>,
	<fenghuay@nvidia.com>, <baisheng.gao@unisoc.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>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH v2 06/29] ACPI / MPAM: Parse the MPAM table
Date: Thu, 11 Sep 2025 14:17:26 +0100	[thread overview]
Message-ID: <20250911141726.00002f0c@huawei.com> (raw)
In-Reply-To: <20250910204309.20751-7-james.morse@arm.com>

On Wed, 10 Sep 2025 20:42:46 +0000
James Morse <james.morse@arm.com> wrote:

> Add code to parse the arm64 specific MPAM table, looking up the cache
> level from the PPTT and feeding the end result into the MPAM driver.
> 
> For now the MPAM hook mpam_ris_create() is stubbed out, but will update
> the MPAM driver with optional discovered data.
> 
> CC: Carl Worth <carl@os.amperecomputing.com>
> Link: https://developer.arm.com/documentation/den0065/3-0bet/?lang=en
> Signed-off-by: James Morse <james.morse@arm.com>
> 
Hi James,

A few comments inline.  Note I've more or less completely forgotten
what was discussed in RFC 1 so I might well be repeating stuff that
you replied to then.  Always a problem for me with big complex patch sets!

Jonathan

> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> new file mode 100644
> index 000000000000..fd9cfa143676
> --- /dev/null
> +++ b/drivers/acpi/arm64/mpam.c


> +static int acpi_mpam_parse_resource(struct mpam_msc *msc,
> +				    struct acpi_mpam_resource_node *res)
> +{
> +	int level, nid;
> +	u32 cache_id;
> +
> +	switch (res->locator_type) {
> +	case ACPI_MPAM_LOCATION_TYPE_PROCESSOR_CACHE:
> +		cache_id = res->locator.cache_locator.cache_reference;
> +		level = find_acpi_cache_level_from_id(cache_id);
> +		if (level <= 0) {
> +			pr_err_once("Bad level (%u) for cache with id %u\n", level, cache_id);
> +			return -EINVAL;
> +		}
> +		return mpam_ris_create(msc, res->ris_index, MPAM_CLASS_CACHE,
> +				       level, cache_id);
> +	case ACPI_MPAM_LOCATION_TYPE_MEMORY:
> +		nid = pxm_to_node(res->locator.memory_locator.proximity_domain);
> +		if (nid == NUMA_NO_NODE)
> +			nid = 0;
> +		return mpam_ris_create(msc, res->ris_index, MPAM_CLASS_MEMORY,
> +				       255, nid);
> +	default:
> +		/* These get discovered later and treated as unknown */

are treated?


> +		return 0;
> +	}
> +}

> +static bool __init parse_msc_pm_link(struct acpi_mpam_msc_node *tbl_msc,
> +				     struct platform_device *pdev,
> +				     u32 *acpi_id)
> +{
> +	char hid[sizeof(tbl_msc->hardware_id_linked_device) + 1];
> +	bool acpi_id_valid = false;
> +	struct acpi_device *buddy;
> +	char uid[11];
> +	int err;
> +
> +	memset(&hid, 0, sizeof(hid));

 = {}; above and skip the memset.

> +	memcpy(hid, &tbl_msc->hardware_id_linked_device,
> +	       sizeof(tbl_msc->hardware_id_linked_device));
> +
> +	if (!strcmp(hid, ACPI_PROCESSOR_CONTAINER_HID)) {
> +		*acpi_id = tbl_msc->instance_id_linked_device;
> +		acpi_id_valid = true;
> +	}
> +
> +	err = snprintf(uid, sizeof(uid), "%u",
> +		       tbl_msc->instance_id_linked_device);
> +	if (err >= sizeof(uid)) {
> +		pr_debug("Failed to convert uid of device for power management.");
> +		return acpi_id_valid;
> +	}
> +
> +	buddy = acpi_dev_get_first_match_dev(hid, uid, -1);
> +	if (buddy)
> +		device_link_add(&pdev->dev, &buddy->dev, DL_FLAG_STATELESS);
> +
> +	return acpi_id_valid;
> +}

> +
> +static int __init acpi_mpam_parse(void)
> +{
> +	struct acpi_table_header *table __free(acpi_table) = acpi_get_table_ret(ACPI_SIG_MPAM, 0);
> +	char *table_end, *table_offset = (char *)(table + 1);
> +	struct property_entry props[4]; /* needs a sentinel */
Perhaps move this and res into the loop and use = {};

> +	struct acpi_mpam_msc_node *tbl_msc;
> +	int next_res, next_prop, err = 0;
> +	struct acpi_device *companion;
> +	struct platform_device *pdev;
> +	enum mpam_msc_iface iface;
> +	struct resource res[3];

Add a comment here or a check later on why this is large enough.

> +	char uid[16];
> +	u32 acpi_id;
> +
> +	if (acpi_disabled || !system_supports_mpam() || IS_ERR(table))
> +		return 0;
> +
> +	if (table->revision < 1)
> +		return 0;
> +
> +	table_end = (char *)table + table->length;
> +
> +	while (table_offset < table_end) {
> +		tbl_msc = (struct acpi_mpam_msc_node *)table_offset;
> +		table_offset += tbl_msc->length;
> +
> +		if (table_offset > table_end) {
> +			pr_debug("MSC entry overlaps end of ACPI table\n");
> +			break;

That this isn't considered an error is a bit subtle and made me wonder
if there was a use of uninitialized pdev (there isn't because err == 0)
Why not return here?

> +		}
> +
> +		/*
> +		 * If any of the reserved fields are set, make no attempt to
> +		 * parse the MSC structure. This MSC will still be counted,
> +		 * meaning the MPAM driver can't probe against all MSC, and
> +		 * will never be enabled. There is no way to enable it safely,
> +		 * because we cannot determine safe system-wide partid and pmg
> +		 * ranges in this situation.
> +		 */

This is decidedly paranoid. I'd normally expect the architecture to be based
on assumption that is fine for old software to ignore new fields.  ACPI itself
has fairly firm rules on this (though it goes wrong sometimes :)
I'm guessing there is something out there that made this necessary though so
keep it if you actually need it.

> +		if (tbl_msc->reserved || tbl_msc->reserved1 || tbl_msc->reserved2) {
> +			pr_err_once("Unrecognised MSC, MPAM not usable\n");
> +			pr_debug("MSC.%u: reserved field set\n", tbl_msc->identifier);
> +			continue;
> +		}
> +
> +		if (!tbl_msc->mmio_size) {
> +			pr_debug("MSC.%u: marked as disabled\n", tbl_msc->identifier);
> +			continue;
> +		}
> +
> +		if (decode_interface_type(tbl_msc, &iface)) {
> +			pr_debug("MSC.%u: unknown interface type\n", tbl_msc->identifier);
> +			continue;
> +		}
> +
> +		next_res = 0;
> +		next_prop = 0;
> +		memset(res, 0, sizeof(res));
> +		memset(props, 0, sizeof(props));
> +
> +		pdev = platform_device_alloc("mpam_msc", tbl_msc->identifier);

https://lore.kernel.org/all/20241009124120.1124-13-shiju.jose@huawei.com/
was a proposal to add a DEFINE_FREE() to clean these up.  Might be worth a revisit.
Then Greg was against the use it was put to and asking for an example of where
it helped.  Maybe this is that example.

If you do want to do that, I'd factor out a bunch of the stuff here as a helper
so we can have the clean ownership pass of a return_ptr().  
Similar to what Shiju did here (this is the usecase for platform device that
Greg didn't like).
https://lore.kernel.org/all/20241009124120.1124-14-shiju.jose@huawei.com/

Even without that I think factoring some of this out and hence being able to
do returns on errors and put the if (err) into the loop would be a nice
improvement to readability.

> +		if (!pdev) {
> +			err = -ENOMEM;
> +			break;
> +		}
> +
> +		if (tbl_msc->length < sizeof(*tbl_msc)) {
> +			err = -EINVAL;
> +			break;
> +		}
> +
> +		/* Some power management is described in the namespace: */
> +		err = snprintf(uid, sizeof(uid), "%u", tbl_msc->identifier);
> +		if (err > 0 && err < sizeof(uid)) {
> +			companion = acpi_dev_get_first_match_dev("ARMHAA5C", uid, -1);
> +			if (companion)
> +				ACPI_COMPANION_SET(&pdev->dev, companion);
> +			else
> +				pr_debug("MSC.%u: missing namespace entry\n", tbl_msc->identifier);
> +		}
> +
> +		if (iface == MPAM_IFACE_MMIO) {
> +			res[next_res++] = DEFINE_RES_MEM_NAMED(tbl_msc->base_address,
> +							       tbl_msc->mmio_size,
> +							       "MPAM:MSC");
> +		} else if (iface == MPAM_IFACE_PCC) {
> +			props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
> +								tbl_msc->base_address);
> +			next_prop++;

Why the double increment? Needs a comment if that is right thing to do.

> +		}
> +
> +		acpi_mpam_parse_irqs(pdev, tbl_msc, res, &next_res);
> +		err = platform_device_add_resources(pdev, res, next_res);
> +		if (err)
> +			break;
> +
> +		props[next_prop++] = PROPERTY_ENTRY_U32("arm,not-ready-us",
> +							tbl_msc->max_nrdy_usec);
> +
> +		/*
> +		 * The MSC's CPU affinity is described via its linked power
> +		 * management device, but only if it points at a Processor or
> +		 * Processor Container.
> +		 */
> +		if (parse_msc_pm_link(tbl_msc, pdev, &acpi_id)) {
> +			props[next_prop++] = PROPERTY_ENTRY_U32("cpu_affinity",
> +								acpi_id);
> +		}
> +
> +		err = device_create_managed_software_node(&pdev->dev, props,
> +							  NULL);
> +		if (err)
> +			break;
> +
> +		/* Come back later if you want the RIS too */
> +		err = platform_device_add_data(pdev, tbl_msc, tbl_msc->length);
> +		if (err)
> +			break;
> +
> +		err = platform_device_add(pdev);
> +		if (err)
> +			break;
> +	}
> +
> +	if (err)
> +		platform_device_put(pdev);
> +
> +	return err;
> +}
> +
> +int acpi_mpam_count_msc(void)
> +{
> +	struct acpi_table_header *table __free(acpi_table) = acpi_get_table_ret(ACPI_SIG_MPAM, 0);
> +	char *table_end, *table_offset = (char *)(table + 1);
> +	struct acpi_mpam_msc_node *tbl_msc;
> +	int count = 0;
> +
> +	if (IS_ERR(table))
> +		return 0;
> +
> +	if (table->revision < 1)
> +		return 0;
> +
> +	table_end = (char *)table + table->length;
Trivial so feel free to ignore.
Perhaps should aim for consistency.  Whilst I prefer pointers for this stuff
PPTT did use unsigned longs.

> +
> +	while (table_offset < table_end) {
> +		tbl_msc = (struct acpi_mpam_msc_node *)table_offset;
> +		if (!tbl_msc->mmio_size)
> +			continue;
> +
> +		if (tbl_msc->length < sizeof(*tbl_msc))
> +			return -EINVAL;
> +		if (tbl_msc->length > table_end - table_offset)
> +			return -EINVAL;
> +		table_offset += tbl_msc->length;
> +
> +		count++;
> +	}
> +
> +	return count;
> +}
> +

Could reorder to put acpi_mpam_parse and this use of it together?

> +/*
> + * Call after ACPI devices have been created, which happens behind acpi_scan_init()
> + * called from subsys_initcall(). PCC requires the mailbox driver, which is
> + * initialised from postcore_initcall().
> + */
> +subsys_initcall_sync(acpi_mpam_parse);

> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5fd92cda487..af449964426b 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -8,6 +8,7 @@
>  #ifndef _LINUX_ACPI_H
>  #define _LINUX_ACPI_H
>  
> +#include <linux/cleanup.h>
>  #include <linux/errno.h>
>  #include <linux/ioport.h>	/* for struct resource */
>  #include <linux/resource_ext.h>
> @@ -221,6 +222,17 @@ void acpi_reserve_initial_tables (void);
>  void acpi_table_init_complete (void);
>  int acpi_table_init (void);
>  
> +static inline struct acpi_table_header *acpi_get_table_ret(char *signature, u32 instance)
> +{
> +	struct acpi_table_header *table;
> +	int status = acpi_get_table(signature, instance, &table);
> +
> +	if (ACPI_FAILURE(status))
> +		return ERR_PTR(-ENOENT);
> +	return table;
> +}
> +DEFINE_FREE(acpi_table, struct acpi_table_header *, if (!IS_ERR(_T)) acpi_put_table(_T))

I'd use if (!IS_ERR_OR_NULL(_T)) not because it is functionally necessary but
because it will let the compiler optimize this out if it can tell that in a given
path _T is NULL (I think it was Peter Z who pointed this out in a similar interface
a while back).


I'd like an opinion from Rafael on this in general.



> +
>  int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
>  int __init_or_acpilib acpi_table_parse_entries(char *id,
>  		unsigned long table_size, int entry_id,


  reply	other threads:[~2025-09-11 13:17 UTC|newest]

Thread overview: 200+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 20:42 [PATCH v2 00/29] arm_mpam: Add basic mpam driver James Morse
2025-09-10 20:42 ` [PATCH v2 01/29] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-09-11 10:43   ` Jonathan Cameron
2025-09-11 10:48     ` Jonathan Cameron
2025-09-19 16:10     ` James Morse
2025-09-25  9:32   ` Stanimir Varbanov
2025-10-10 16:54     ` James Morse
2025-10-02  3:35   ` Fenghua Yu
2025-10-10 16:54     ` James Morse
2025-10-03  0:15   ` Gavin Shan
2025-10-10 16:55     ` James Morse
2025-09-10 20:42 ` [PATCH v2 02/29] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-09-11 10:46   ` Jonathan Cameron
2025-09-19 16:10     ` James Morse
2025-09-11 14:08   ` Ben Horgan
2025-09-19 16:10     ` James Morse
2025-10-02  3:55   ` Fenghua Yu
2025-10-10 16:55     ` James Morse
2025-10-03  0:17   ` Gavin Shan
2025-09-10 20:42 ` [PATCH v2 03/29] ACPI / PPTT: Find cache level by cache-id James Morse
2025-09-11 10:59   ` Jonathan Cameron
2025-09-19 16:10     ` James Morse
2025-09-11 15:27   ` Lorenzo Pieralisi
2025-09-19 16:10     ` James Morse
2025-10-02  4:30   ` Fenghua Yu
2025-10-10 16:55     ` James Morse
2025-10-03  0:23   ` Gavin Shan
2025-09-10 20:42 ` [PATCH v2 04/29] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-09-11 11:06   ` Jonathan Cameron
2025-09-19 16:10     ` James Morse
2025-10-02  5:03   ` Fenghua Yu
2025-10-10 16:55     ` James Morse
2025-09-10 20:42 ` [PATCH v2 05/29] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-09-12 10:14   ` Ben Horgan
2025-10-02  5:06   ` Fenghua Yu
2025-10-10 16:55     ` James Morse
2025-10-03  0:32   ` Gavin Shan
2025-10-10 16:55     ` James Morse
2025-09-10 20:42 ` [PATCH v2 06/29] ACPI / MPAM: Parse the MPAM table James Morse
2025-09-11 13:17   ` Jonathan Cameron [this message]
2025-09-19 16:11     ` James Morse
2025-09-26 14:48       ` Jonathan Cameron
2025-10-17 18:50         ` James Morse
2025-09-11 14:56   ` Lorenzo Pieralisi
2025-09-19 16:11     ` James Morse
2025-09-16 13:17   ` [PATCH] arm_mpam: Try reading again if MPAM instance returns not ready Zeng Heng
2025-09-19 16:11     ` James Morse
2025-09-20 10:14       ` Zeng Heng
2025-10-02  3:21   ` [PATCH v2 06/29] ACPI / MPAM: Parse the MPAM table Fenghua Yu
2025-10-17 18:50     ` James Morse
2025-10-03  0:58   ` Gavin Shan
2025-10-17 18:51     ` James Morse
2025-09-10 20:42 ` [PATCH v2 07/29] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-09-11 13:35   ` Jonathan Cameron
2025-09-23 16:41     ` James Morse
2025-09-26 14:55       ` Jonathan Cameron
2025-10-17 18:51         ` James Morse
2025-09-17 11:03   ` Ben Horgan
2025-09-29 17:44     ` James Morse
2025-10-03  3:53   ` Gavin Shan
2025-10-17 18:51     ` James Morse
2025-09-10 20:42 ` [PATCH v2 08/29] arm_mpam: Add the class and component structures for firmware described ris James Morse
2025-09-11 14:22   ` Jonathan Cameron
2025-09-26 17:52     ` James Morse
2025-09-11 16:30   ` Markus Elfring
2025-09-26 17:52     ` James Morse
2025-09-26 18:15       ` Markus Elfring
2025-10-17 18:51         ` James Morse
2025-10-03 16:54   ` Fenghua Yu
2025-10-17 18:51     ` James Morse
2025-10-06 23:13   ` Gavin Shan
2025-10-17 18:51     ` James Morse
2025-09-10 20:42 ` [PATCH v2 09/29] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-09-11 15:00   ` Jonathan Cameron
2025-10-17 18:53     ` James Morse
2025-09-12  7:33   ` Markus Elfring
2025-10-06 23:25   ` Gavin Shan
2025-09-10 20:42 ` [PATCH v2 10/29] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-09-11 15:07   ` Jonathan Cameron
2025-09-29 17:44     ` James Morse
2025-09-12 10:42   ` Ben Horgan
2025-09-29 17:44     ` James Morse
2025-10-03 17:56   ` Fenghua Yu
2025-10-06 23:42   ` Gavin Shan
2025-09-10 20:42 ` [PATCH v2 11/29] arm_mpam: Probe hardware to find the supported partid/pmg values James Morse
2025-09-11 15:18   ` Jonathan Cameron
2025-09-29 17:44     ` James Morse
2025-09-12 11:11   ` Ben Horgan
2025-09-29 17:44     ` James Morse
2025-10-03 18:58   ` Fenghua Yu
2025-09-10 20:42 ` [PATCH v2 12/29] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-09-11 15:24   ` Jonathan Cameron
2025-09-29 17:44     ` James Morse
2025-09-11 15:31   ` Ben Horgan
2025-09-29 17:44     ` James Morse
2025-10-05  0:09   ` Fenghua Yu
2025-09-10 20:42 ` [PATCH v2 13/29] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-09-11 15:29   ` Jonathan Cameron
2025-09-29 17:45     ` James Morse
2025-09-11 15:37   ` Ben Horgan
2025-09-29 17:45     ` James Morse
2025-09-30 13:32       ` Ben Horgan
2025-10-05  0:53   ` Fenghua Yu
2025-09-10 20:42 ` [PATCH v2 14/29] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-09-12 11:49   ` Jonathan Cameron
2025-09-29 17:45     ` James Morse
2025-10-05  1:28   ` Fenghua Yu
2025-09-10 20:42 ` [PATCH v2 15/29] arm_mpam: Reset MSC controls from cpu hp callbacks James Morse
2025-09-12 11:25   ` Ben Horgan
2025-09-12 14:52     ` Ben Horgan
2025-09-30 17:06       ` James Morse
2025-09-30 17:06     ` James Morse
2025-09-12 11:55   ` Jonathan Cameron
2025-09-30 17:06     ` James Morse
2025-09-30  2:51   ` Shaopeng Tan (Fujitsu)
2025-10-01  9:51     ` James Morse
     [not found]   ` <1f084a23-7211-4291-99b6-7f5192fb9096@nvidia.com>
2025-10-17 18:50     ` James Morse
2025-09-10 20:42 ` [PATCH v2 16/29] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-09-12 11:57   ` Jonathan Cameron
2025-10-01  9:50     ` James Morse
2025-10-05 21:08   ` Fenghua Yu
2025-09-10 20:42 ` [PATCH v2 17/29] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-09-12 11:42   ` Ben Horgan
2025-10-02 18:02     ` James Morse
2025-09-12 12:02   ` Jonathan Cameron
2025-09-30 17:06     ` James Morse
2025-09-25  7:16   ` Fenghua Yu
2025-10-02 18:02     ` James Morse
2025-09-10 20:42 ` [PATCH v2 18/29] arm_mpam: Register and enable IRQs James Morse
2025-09-12 12:12   ` Jonathan Cameron
2025-10-02 18:02     ` James Morse
2025-09-12 14:40   ` Ben Horgan
2025-10-02 18:03     ` James Morse
2025-09-12 15:22   ` Dave Martin
2025-10-03 18:02     ` James Morse
2025-09-25  6:33   ` Fenghua Yu
2025-10-03 18:03     ` James Morse
2025-09-10 20:42 ` [PATCH v2 19/29] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-09-12 12:13   ` Jonathan Cameron
2025-10-03 18:03     ` James Morse
2025-09-12 14:42   ` Ben Horgan
2025-10-03 18:03     ` James Morse
2025-09-26  2:31   ` Fenghua Yu
2025-10-03 18:04     ` James Morse
2025-09-10 20:43 ` [PATCH v2 20/29] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-09-12 12:22   ` Jonathan Cameron
2025-10-07 11:11     ` James Morse
2025-09-12 15:00   ` Ben Horgan
2025-09-25  6:53   ` Fenghua Yu
2025-10-03 18:04     ` James Morse
2025-09-10 20:43 ` [PATCH v2 21/29] arm_mpam: Probe and reset the rest of the features James Morse
2025-09-12 13:07   ` Jonathan Cameron
2025-10-03 18:05     ` James Morse
2025-09-10 20:43 ` [PATCH v2 22/29] arm_mpam: Add helpers to allocate monitors James Morse
2025-09-12 13:11   ` Jonathan Cameron
2025-10-06 14:57     ` James Morse
2025-10-06 15:56     ` James Morse
2025-09-10 20:43 ` [PATCH v2 23/29] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-09-11 15:46   ` Ben Horgan
2025-09-12 15:08     ` Ben Horgan
2025-10-06 16:00       ` James Morse
2025-10-06 15:59     ` James Morse
2025-09-12 13:21   ` Jonathan Cameron
2025-10-09 17:48     ` James Morse
2025-09-25  2:30   ` Fenghua Yu
2025-10-09 17:48     ` James Morse
2025-09-10 20:43 ` [PATCH v2 24/29] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-09-12 13:24   ` Jonathan Cameron
2025-10-09 17:48     ` James Morse
2025-09-12 15:55   ` Ben Horgan
2025-10-13 16:29     ` James Morse
2025-09-10 20:43 ` [PATCH v2 25/29] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-09-12 13:27   ` Jonathan Cameron
2025-10-09 17:48     ` James Morse
2025-09-10 20:43 ` [PATCH v2 26/29] arm_mpam: Use long MBWU counters if supported James Morse
2025-09-12 13:29   ` Jonathan Cameron
2025-10-10 16:53     ` James Morse
2025-09-26  4:51   ` Fenghua Yu
2025-09-10 20:43 ` [PATCH v2 27/29] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-09-12 13:33   ` Jonathan Cameron
2025-10-10 16:53     ` James Morse
2025-09-18  2:35   ` Shaopeng Tan (Fujitsu)
2025-10-10 16:53     ` James Morse
2025-09-26  4:11   ` Fenghua Yu
2025-10-10 16:53     ` James Morse
2025-09-10 20:43 ` [PATCH v2 28/29] arm_mpam: Add kunit test for bitmap reset James Morse
2025-09-12 13:37   ` Jonathan Cameron
2025-10-10 16:53     ` James Morse
2025-09-12 16:06   ` Ben Horgan
2025-10-10 16:53     ` James Morse
2025-09-26  2:35   ` Fenghua Yu
2025-10-10 16:53     ` James Morse
2025-09-10 20:43 ` [PATCH v2 29/29] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-09-12 13:41   ` Jonathan Cameron
2025-10-10 16:54     ` James Morse
2025-09-12 16:01   ` Ben Horgan
2025-10-10 16:54     ` James Morse
2025-09-26  2:36   ` Fenghua Yu
2025-10-10 16:54     ` James Morse
2025-09-25  7:18 ` [PATCH v2 00/29] arm_mpam: Add basic mpam driver Fenghua Yu

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=20250911141726.00002f0c@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=amitsinght@marvell.com \
    --cc=baisheng.gao@unisoc.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bobo.shaobowang@huawei.com \
    --cc=carl@os.amperecomputing.com \
    --cc=catalin.marinas@arm.com \
    --cc=dakr@kernel.org \
    --cc=dave.martin@arm.com \
    --cc=david@redhat.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghuay@nvidia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=kobak@nvidia.com \
    --cc=lcherian@marvell.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=peternewman@google.com \
    --cc=quic_jiles@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rohit.mathew@arm.com \
    --cc=scott@os.amperecomputing.com \
    --cc=sdonthineni@nvidia.com \
    --cc=sudeep.holla@arm.com \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=will@kernel.org \
    --cc=xhao@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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