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>,
"Rob Herring" <robh@kernel.org>, Ben Horgan <ben.horgan@arm.com>,
Rohit Mathew <rohit.mathew@arm.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
"Zeng Heng" <zengheng4@huawei.com>,
Lecopzer Chen <lecopzerc@nvidia.com>,
"Carl Worth" <carl@os.amperecomputing.com>,
<shameerali.kolothum.thodi@huawei.com>,
D Scott Phillips OS <scott@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>,
Rex Nie <rex.nie@jaguarmicro.com>,
Dave Martin <dave.martin@arm.com>, Koba Ko <kobak@nvidia.com>
Subject: Re: [RFC PATCH 10/36] ACPI / MPAM: Parse the MPAM table
Date: Wed, 16 Jul 2025 18:07:25 +0100 [thread overview]
Message-ID: <20250716180725.0000452d@huawei.com> (raw)
In-Reply-To: <20250711183648.30766-11-james.morse@arm.com>
On Fri, 11 Jul 2025 18:36:22 +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.
Throw in a link to the spec perhaps? Particularly useful to know which
version this was written against when reviewing it.
>
> CC: Carl Worth <carl@os.amperecomputing.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Kconfig | 3 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/mpam.c | 365 ++++++++++++++++++++++++++++++++++++
> drivers/acpi/tables.c | 2 +-
> include/linux/arm_mpam.h | 46 +++++
> 6 files changed, 417 insertions(+), 1 deletion(-)
> create mode 100644 drivers/acpi/arm64/mpam.c
> create mode 100644 include/linux/arm_mpam.h
>
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 05ecde9eaabe..27b872249baa 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -6,5 +6,6 @@ obj-$(CONFIG_ACPI_GTDT) += gtdt.o
> obj-$(CONFIG_ACPI_IORT) += iort.o
> obj-$(CONFIG_ACPI_PROCESSOR_IDLE) += cpuidle.o
> obj-$(CONFIG_ARM_AMBA) += amba.o
> +obj-$(CONFIG_ACPI_MPAM) += mpam.o
Keep it with the ACPI ones? There doesn't seem to be a lot of order in here
though so I guess maybe there is logic behind putting it here I'm missing.
> obj-y += dma.o init.o
> obj-y += thermal_cpufreq.o
> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> new file mode 100644
> index 000000000000..f4791bac9a2a
> --- /dev/null
> +++ b/drivers/acpi/arm64/mpam.c
> @@ -0,0 +1,365 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2025 Arm Ltd.
> +
> +/* Parse the MPAM ACPI table feeding the discovered nodes into the driver */
> +
> +#define pr_fmt(fmt) "ACPI MPAM: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/arm_mpam.h>
> +#include <linux/cpu.h>
> +#include <linux/cpumask.h>
> +#include <linux/platform_device.h>
> +
> +#include <acpi/processor.h>
> +
> +/* Flags for acpi_table_mpam_msc.*_interrupt_flags */
References.. I'm looking at 3.0-alpha table 5 to check this.
I can see why you might be reluctant to point at an alpha if that
is what you are using ;)
> +#define ACPI_MPAM_MSC_IRQ_MODE_EDGE 1
> +#define ACPI_MPAM_MSC_IRQ_TYPE_MASK (3 << 1)
GENMASK(3, 2) would be my preference for how to do masks in new code.
> +#define ACPI_MPAM_MSC_IRQ_TYPE_WIRED 0
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_PROCESSOR_CONTAINER BIT(3)
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_VALID BIT(4)
> +
> +static bool frob_irq(struct platform_device *pdev, int intid, u32 flags,
> + int *irq, u32 processor_container_uid)
> +{
> + int sense;
> +
> + if (!intid)
> + return false;
> +
> + /* 0 in this field indicates a wired interrupt */
> + if (flags & ACPI_MPAM_MSC_IRQ_TYPE_MASK)
I'd prefer more explicit code (and probably no comment)
if (FIELD_GET(flags, ACPI_MPAM_MSC_IRQ_TYPE_MASK) !=
ACPI_MPAM_MSC_IRQ_TYPE_WIRED)
return false;
> + return false;
> +
> + if (flags & ACPI_MPAM_MSC_IRQ_MODE_EDGE)
> + sense = ACPI_EDGE_SENSITIVE;
> + else
> + sense = ACPI_LEVEL_SENSITIVE;
If the spec is supposed to be using standard ACPI_* types for this field
(I don't think the connection is explicitly documented though) then
sense = FIELD_GET(flags, ACPI_MPAM_MSC_IRQ_MODE_MASK);
Assuming a change to define the mask and rely on the ACPI defs for the values
This one is entirely up to you.
> +
> + /*
> + * If the GSI is in the GIC's PPI range, try and create a partitioned
> + * percpu interrupt.
> + */
> + if (16 <= intid && intid < 32 && processor_container_uid != ~0) {
> + pr_err_once("Partitioned interrupts not supported\n");
> + return false;
> + }
> +
> + *irq = acpi_register_gsi(&pdev->dev, intid, sense, ACPI_ACTIVE_HIGH);
> + if (*irq <= 0) {
> + pr_err_once("Failed to register interrupt 0x%x with ACPI\n",
> + intid);
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static void acpi_mpam_parse_irqs(struct platform_device *pdev,
> + struct acpi_mpam_msc_node *tbl_msc,
> + struct resource *res, int *res_idx)
> +{
> + u32 flags, aff = ~0;
> + int irq;
> +
> + flags = tbl_msc->overflow_interrupt_flags;
> + if (flags & ACPI_MPAM_MSC_IRQ_AFFINITY_VALID &&
> + flags & ACPI_MPAM_MSC_IRQ_AFFINITY_PROCESSOR_CONTAINER)
> + aff = tbl_msc->overflow_interrupt_affinity;
Just to make the two cases look the same I'd do
else
aff = ~0;
here as well and not initialize above. It's not quite worth using
a helper function for these two identical blocks but it's close.
> + if (frob_irq(pdev, tbl_msc->overflow_interrupt, flags, &irq, aff)) {
> + res[*res_idx].start = irq;
> + res[*res_idx].end = irq;
> + res[*res_idx].flags = IORESOURCE_IRQ;
> + res[*res_idx].name = "overflow";
res[*res_idx] = DEFINE_RES_IRQ_NAMED(irq, 1, "overflow");
> +
> + (*res_idx)++;
Can roll this in as well.
> + }
> +
> + flags = tbl_msc->error_interrupt_flags;
> + if (flags & ACPI_MPAM_MSC_IRQ_AFFINITY_VALID &&
> + flags & ACPI_MPAM_MSC_IRQ_AFFINITY_PROCESSOR_CONTAINER)
> + aff = tbl_msc->error_interrupt_affinity;
> + else
> + aff = ~0;
> + if (frob_irq(pdev, tbl_msc->error_interrupt, flags, &irq, aff)) {
> + res[*res_idx].start = irq;
> + res[*res_idx].end = irq;
> + res[*res_idx].flags = IORESOURCE_IRQ;
> + res[*res_idx].name = "error";
Similar to above.
> +
> + (*res_idx)++;
> + }
> +}
> +
> +static bool __init parse_msc_pm_link(struct acpi_mpam_msc_node *tbl_msc,
> + struct platform_device *pdev,
> + u32 *acpi_id)
> +{
> + bool acpi_id_valid = false;
> + struct acpi_device *buddy;
> + char hid[16], uid[16];
> + int err;
> +
> + memset(&hid, 0, sizeof(hid));
> + 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 < 0 || err >= sizeof(uid))
Does snprintf() ever return < 0 ? It's documented as returning
number of chars printed (without the NULL) so that can only be 0 or
greater.
Can it return >= sizeof(uid) ? Looks odd.
+ 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 _parse_table(struct acpi_table_header *table)
> +{
> + char *table_end, *table_offset = (char *)(table + 1);
> + struct property_entry props[4]; /* needs a sentinel */
> + 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];
> + char uid[16];
> + u32 acpi_id;
> +
> + 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 any of the reserved fields are set, make no attempt to
> + * parse the msc structure. This will prevent the driver from
> + * probing all the MSC, meaning it can't discover the system
> + * wide supported partid and pmg ranges. This avoids whatever
> + * this MSC is truncating the partids and creating a screaming
> + * error interrupt.
> + */
> + if (tbl_msc->reserved || tbl_msc->reserved1 || tbl_msc->reserved2)
> + continue;
> +
> + if (decode_interface_type(tbl_msc, &iface))
> + 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);
> + if (IS_ERR(pdev)) {
returns NULL in at least some error cases (probably all, I'm just to lazy to check)
> + err = PTR_ERR(pdev);
> + 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);
> + }
> +
> + if (iface == MPAM_IFACE_MMIO) {
> + res[next_res].name = "MPAM:MSC";
> + res[next_res].start = tbl_msc->base_address;
> + res[next_res].end = tbl_msc->base_address + tbl_msc->mmio_size - 1;
> + res[next_res].flags = IORESOURCE_MEM;
> + next_res++;
DEFINE_RES_MEM_NAMED()?
> + } else if (iface == MPAM_IFACE_PCC) {
> + props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
> + tbl_msc->base_address);
> + next_prop++;
> + }
> +
> + 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;
> +
> + platform_device_add(pdev);
Can fail.
> + }
> +
> + if (err)
> + platform_device_put(pdev);
> +
> + return err;
> +}
> +
> +static struct acpi_table_header *get_table(void)
> +{
> + struct acpi_table_header *table;
> + acpi_status status;
> +
> + if (acpi_disabled || !system_supports_mpam())
> + return NULL;
> +
> + status = acpi_get_table(ACPI_SIG_MPAM, 0, &table);
> + if (ACPI_FAILURE(status))
> + return NULL;
> +
> + if (table->revision != 1)
> + return NULL;
> +
> + return table;
> +}
> +
> +static int __init acpi_mpam_parse(void)
> +{
> + struct acpi_table_header *mpam;
> + int err;
> +
> + mpam = get_table();
> + if (!mpam)
> + return 0;
Just what I was suggesting for the PPTT case in early patches. Nice :)
> +
> + err = _parse_table(mpam);
> + acpi_put_table(mpam);
> +
> + return err;
> +}
> +
> +static int _count_msc(struct acpi_table_header *table)
> +{
> + char *table_end, *table_offset = (char *)(table + 1);
> + struct acpi_mpam_msc_node *tbl_msc;
> + int ret = 0;
Call it count as it only ever contains the count?
> +
> + tbl_msc = (struct acpi_mpam_msc_node *)table_offset;
> + table_end = (char *)table + table->length;
> +
> + while (table_offset < table_end) {
> + if (tbl_msc->length < sizeof(*tbl_msc))
> + return -EINVAL;
> +
> + ret++;
count++ would feel more natural here.
> +
> + table_offset += tbl_msc->length;
> + tbl_msc = (struct acpi_mpam_msc_node *)table_offset;
> + }
> +
> + return ret;
> +}
That's all I have time for today. Will get to the rest of the series soonish.
Jonathan
next prev parent reply other threads:[~2025-07-16 17:10 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 18:36 [RFC PATCH 00/36] arm_mpam: Add basic mpam driver James Morse
2025-07-11 18:36 ` [RFC PATCH 01/36] cacheinfo: Set cache 'id' based on DT data James Morse
2025-07-11 18:36 ` [RFC PATCH 02/36] cacheinfo: Add arch hook to compress CPU h/w id into 32 bits for cache-id James Morse
2025-07-11 18:36 ` [RFC PATCH 03/36] arm64: cacheinfo: Provide helper to compress MPIDR value into u32 James Morse
2025-07-11 18:36 ` [RFC PATCH 04/36] cacheinfo: Expose the code to generate a cache-id from a device_node James Morse
2025-07-14 11:40 ` Ben Horgan
2025-07-25 17:08 ` James Morse
2025-07-28 8:37 ` Ben Horgan
2025-07-11 18:36 ` [RFC PATCH 05/36] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-07-17 7:58 ` Shaopeng Tan (Fujitsu)
2025-07-25 17:06 ` James Morse
2025-07-22 14:28 ` Jonathan Cameron
2025-07-25 17:05 ` James Morse
2025-07-23 14:42 ` Ben Horgan
2025-07-25 17:05 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 06/36] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-07-16 15:51 ` Jonathan Cameron
2025-07-25 17:05 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 07/36] ACPI / PPTT: Find cache level by cache-id James Morse
2025-07-14 11:42 ` Ben Horgan
2025-08-05 17:06 ` James Morse
2025-07-16 16:21 ` [RFC PATCH 07/36] ACPI / PPTT: Find cache level by cache-idUIRE Jonathan Cameron
2025-08-05 17:06 ` [RFC PATCH 07/36] ACPI / PPTT: Find cache level by cache-id James Morse
2025-07-11 18:36 ` [RFC PATCH 08/36] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-07-16 16:24 ` Jonathan Cameron
2025-08-05 17:06 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 09/36] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-07-16 16:26 ` Jonathan Cameron
2025-07-11 18:36 ` [RFC PATCH 10/36] ACPI / MPAM: Parse the MPAM table James Morse
2025-07-16 17:07 ` Jonathan Cameron [this message]
2025-07-23 16:39 ` Ben Horgan
2025-08-05 17:07 ` James Morse
2025-08-15 9:33 ` Ben Horgan
2025-07-28 10:08 ` Jonathan Cameron
2025-08-05 17:08 ` James Morse
2025-08-05 17:07 ` James Morse
2025-07-24 10:50 ` Ben Horgan
2025-08-05 17:08 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 11/36] dt-bindings: arm: Add MPAM MSC binding James Morse
2025-07-11 21:43 ` Rob Herring
2025-08-05 17:08 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 12/36] platform: arm64: Move ec devices to an ec subdirectory James Morse
2025-07-21 16:32 ` Jonathan Cameron
2025-08-06 18:03 ` James Morse
2025-07-24 10:56 ` Ben Horgan
2025-08-06 18:03 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 13/36] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-07-24 11:02 ` Ben Horgan
2025-08-06 18:03 ` James Morse
2025-07-24 12:09 ` Catalin Marinas
2025-08-06 18:04 ` James Morse
2025-08-07 17:50 ` Drew Fustini
2025-07-11 18:36 ` [RFC PATCH 14/36] arm_mpam: Add support for memory controller MSC on DT platforms James Morse
2025-07-11 18:36 ` [RFC PATCH 15/36] arm_mpam: Add the class and component structures for ris firmware described James Morse
2025-07-11 18:36 ` [RFC PATCH 16/36] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-07-17 1:04 ` Shaopeng Tan (Fujitsu)
2025-08-06 18:04 ` James Morse
2025-07-24 14:02 ` Ben Horgan
2025-08-06 18:05 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 17/36] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-07-24 14:13 ` Ben Horgan
2025-08-06 18:07 ` James Morse
2025-07-29 6:11 ` Baisheng Gao
2025-08-06 18:07 ` James Morse
2025-08-05 8:46 ` Jonathan Cameron
2025-07-11 18:36 ` [RFC PATCH 18/36] arm_mpam: Probe MSCs to find the supported partid/pmg values James Morse
2025-07-11 18:36 ` [RFC PATCH 19/36] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-07-11 18:36 ` [RFC PATCH 20/36] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-07-24 15:08 ` Ben Horgan
2025-07-28 16:16 ` Jonathan Cameron
2025-08-07 18:26 ` James Morse
2025-07-28 8:56 ` Ben Horgan
2025-08-08 7:20 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 21/36] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-07-28 9:15 ` Ben Horgan
2025-07-11 18:36 ` [RFC PATCH 22/36] arm_mpam: Reset MSC controls from cpu hp callbacks James Morse
2025-07-28 9:49 ` Ben Horgan
2025-08-08 7:05 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 23/36] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-07-11 18:36 ` [RFC PATCH 24/36] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-07-28 10:22 ` Ben Horgan
2025-08-08 7:07 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 25/36] arm_mpam: Register and enable IRQs James Morse
2025-07-16 7:31 ` Shaopeng Tan (Fujitsu)
2025-08-08 7:08 ` James Morse
2025-07-17 1:08 ` Shaopeng Tan (Fujitsu)
2025-08-08 7:07 ` James Morse
2025-07-22 15:06 ` Jonathan Cameron
2025-08-08 7:11 ` James Morse
2025-07-28 10:49 ` Ben Horgan
2025-08-08 7:11 ` James Morse
2025-08-04 16:53 ` Fenghua Yu
2025-08-08 7:12 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 26/36] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-07-11 18:36 ` [RFC PATCH 27/36] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-07-16 6:49 ` Shaopeng Tan (Fujitsu)
2025-08-08 7:13 ` James Morse
2025-07-28 11:59 ` Ben Horgan
2025-07-28 15:34 ` Dave Martin
2025-08-08 7:16 ` James Morse
2025-08-08 7:14 ` James Morse
2025-08-04 16:39 ` Fenghua Yu
2025-08-08 7:17 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 28/36] arm_mpam: Probe and reset the rest of the features James Morse
2025-07-11 18:36 ` [RFC PATCH 29/36] arm_mpam: Add helpers to allocate monitors James Morse
2025-07-11 18:36 ` [RFC PATCH 30/36] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-07-28 13:02 ` Ben Horgan
2025-07-11 18:36 ` [RFC PATCH 31/36] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-07-11 18:36 ` [RFC PATCH 32/36] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-07-11 18:36 ` [RFC PATCH 33/36] arm_mpam: Use long MBWU counters if supported James Morse
2025-07-28 13:46 ` Ben Horgan
2025-08-08 7:19 ` James Morse
2025-07-11 18:36 ` [RFC PATCH 34/36] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-07-11 18:36 ` [RFC PATCH 35/36] arm_mpam: Add kunit test for bitmap reset James Morse
2025-07-11 18:36 ` [RFC PATCH 36/36] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-08-01 16:09 ` [RFC PATCH 00/36] arm_mpam: Add basic mpam driver Jonathan Cameron
2025-08-08 7:23 ` James Morse
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=20250716180725.0000452d@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=amitsinght@marvell.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=ben.horgan@arm.com \
--cc=bobo.shaobowang@huawei.com \
--cc=carl@os.amperecomputing.com \
--cc=dave.martin@arm.com \
--cc=david@redhat.com \
--cc=dfustini@baylibre.com \
--cc=james.morse@arm.com \
--cc=kobak@nvidia.com \
--cc=lcherian@marvell.com \
--cc=lecopzerc@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peternewman@google.com \
--cc=quic_jiles@quicinc.com \
--cc=rex.nie@jaguarmicro.com \
--cc=robh@kernel.org \
--cc=rohit.mathew@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=sdonthineni@nvidia.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=xhao@linux.alibaba.com \
--cc=zengheng4@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.