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>,
Jeremy Linton <jeremy.linton@arm.com>,
Gavin Shan <gshan@redhat.com>
Subject: Re: [PATCH v3 06/29] ACPI / MPAM: Parse the MPAM table
Date: Fri, 24 Oct 2025 17:13:50 +0100 [thread overview]
Message-ID: <20251024171350.00005451@huawei.com> (raw)
In-Reply-To: <20251017185645.26604-7-james.morse@arm.com>
On Fri, 17 Oct 2025 18:56: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.
>
> This happens in two stages. Platform devices are created first for the
> MSC devices. Once the driver probes it calls acpi_mpam_parse_resources()
> to discover the RIS entries the MSC contains.
>
> For now the MPAM hook mpam_ris_create() is stubbed out, but will update
> the MPAM driver with optional discovered data about the RIS entries.
>
> CC: Carl Worth <carl@os.amperecomputing.com>
> Link: https://developer.arm.com/documentation/den0065/3-0bet/?lang=en
> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Tested-by: Fenghua Yu <fenghuay@nvidia.com>
> Signed-off-by: James Morse <james.morse@arm.com>
>
Hi James,
Various comments inline. One challenge with this is that a few
very generic things (the acpi table DEFINE_FREE() stuff and the
platform device put equivalent) aren't obvious enough that I'd expect
those concerned to necessarily notice them. I'd break those out
as precursor patches, or narrow what they do to not be generic.
> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> new file mode 100644
> index 000000000000..59712397025d
> --- /dev/null
> +++ b/drivers/acpi/arm64/mpam.c
> @@ -0,0 +1,377 @@
> +// 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/bits.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.
> + * See 2.1.1 Interrupt Flags, Table 5, of DEN0065B_MPAM_ACPI_3.0-bet.
This needs to ultimately end up in ACPICA. Perhaps fine to have it here
for now. Maybe can't happen until this isn't a beta? I'm not sure on
policy around that.
> + */
> +#define ACPI_MPAM_MSC_IRQ_MODE BIT(0)
> +#define ACPI_MPAM_MSC_IRQ_TYPE_MASK GENMASK(2, 1)
> +#define ACPI_MPAM_MSC_IRQ_TYPE_WIRED 0
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_TYPE_MASK BIT(3)
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_TYPE_PROCESSOR 0
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_TYPE_PROCESSOR_CONTAINER 1
> +#define ACPI_MPAM_MSC_IRQ_AFFINITY_VALID BIT(4)
> +
> +/*
> + * Encodings for the MSC node body interface type field.
> + * See 2.1 MPAM MSC node, Table 4 of DEN0065B_MPAM_ACPI_3.0-bet.
> + */
> +#define ACPI_MPAM_MSC_IFACE_MMIO 0x00
> +#define ACPI_MPAM_MSC_IFACE_PCC 0x0a
> +
> +static bool acpi_mpam_register_irq(struct platform_device *pdev, int intid,
> + u32 flags, int *irq)
Given irq value of 0 is invalid, could just return the irq from this.
Or even return error codes for what went wrong given negative irqs are invalid
as well.
> +{
> + u32 int_type;
> + int sense;
> +
> + if (!intid)
> + return false;
> +
> + if (_is_ppi_partition(flags))
> + return false;
> +
> + sense = FIELD_GET(ACPI_MPAM_MSC_IRQ_MODE, flags);
Given it's one bit that indicates 1 if edge, I'd call this edge (which
inherently doesn't mean level). Sense as a term I think can incorporate
this and rising/falling high/low. It's parse to acpi_register_gsi()
which calls it trigger so that would work as well.
> + int_type = FIELD_GET(ACPI_MPAM_MSC_IRQ_TYPE_MASK, flags);
> + if (int_type != ACPI_MPAM_MSC_IRQ_TYPE_WIRED)
> + 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, intid;
> + int irq;
> +
> + intid = tbl_msc->overflow_interrupt;
> + flags = tbl_msc->overflow_interrupt_flags;
> + if (acpi_mpam_register_irq(pdev, intid, flags, &irq))
> + res[(*res_idx)++] = DEFINE_RES_IRQ_NAMED(irq, "overflow");
> +
> + intid = tbl_msc->error_interrupt;
> + flags = tbl_msc->error_interrupt_flags;
> + if (acpi_mpam_register_irq(pdev, intid, flags, &irq))
> + res[(*res_idx)++] = DEFINE_RES_IRQ_NAMED(irq, "error");
> +}
> +
This function has a bit of a dual use to it. I think it needs some documentation
to explain under what conditions acpi_id is set.
> +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] = { 0 };
> + bool acpi_id_valid = false;
> + struct acpi_device *buddy;
> + char uid[11];
> + int err;
> +
> + 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)) {
The err naming is a bit confusing as it's not an error code. Could call it
something like len or just avoid having a local variable at all.
if (snprintf(uid, sizeof(uid), "%u",
tbl_msc->instance_id_linked_device) >= 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 struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_node *tbl_msc)
> +{
> + struct platform_device *pdev __free(platform_device_put) = platform_device_alloc("mpam_msc", tbl_msc->identifier);
That's too long. Format as
struct platform_device *pdev __free(platform_device_put) =
platform_device_alloc("mpam_msc", tbl_msc->identifier);
> + int next_res = 0, next_prop = 0, err;
...
> +
> +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 acpi_mpam_msc_node *tbl_msc;
> + struct platform_device *pdev;
> +
> + if (acpi_disabled || !system_supports_mpam() || IS_ERR(table))
Check acpi_disabled || !system_supports_mpam() before
struct acpi_table_header *table __free(acpi_table) = acpi_get_table_ret(ACPI_SIG_MPAM, 0);
if (IS_ERR(table))
return 0;
That way we aren't relying on acpi_get_table_ret() doing the right thing if acpi_disabled == true
which seems gragile even though it is fine today
Declaring stuff using __free() inline is fine (commonly done).
> + return 0;
> +
...
> +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))
Why fewer things to guard on in here than in the parse function?
I guess this may only be called in circumstances where we know those
other reasons not to carry on aren't true, but still seem odd.
> + 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;
> + if (!tbl_msc->mmio_size)
Bit marginal on how much we protect against garbage, but perhaps
check the length is long enough to get here. Or can you just
do the length checks first?
> + continue;
Infinite loop? table_offset isn't updated so this
keeps checking the same value. Similar to funciton above, I'd
do the table_offset update before check this (and modify
the appropriate checks below).
> +
> + 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;
> +}
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index a9dbacabdf89..9d66421f68ff 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)
I wonder if it's worth instance being a variable. 11 instances of 1, 52 instances of 0
(almost nothing else). Maybe just about worth it...
Whilst I like the general nature of this I wonder if smoother
to merge acpi_get_table_mpam() that does this first and then
look at generalizing when it's not on the critical path for this
patch set? If ACPI folk are fine with this I don't mind it being
in here though as generally useful to have.
(I may well be arguing with earlier me on this :)
> +{
> + 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))
Ben raised earlier comment on checking for NULL as well to let the compiler optimize
things better.
> +
> 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,
> diff --git a/include/linux/arm_mpam.h b/include/linux/arm_mpam.h
> new file mode 100644
> index 000000000000..3d6c39c667c3
> --- /dev/null
> +++ b/include/linux/arm_mpam.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2025 Arm Ltd. */
> +
> +#ifndef __LINUX_ARM_MPAM_H
> +#define __LINUX_ARM_MPAM_H
> +
> +#include <linux/acpi.h>
> +#include <linux/types.h>
...
> +enum mpam_class_types {
> + MPAM_CLASS_CACHE, /* Well known caches, e.g. L2 */
Curious comment. As opposed to the lesser known l5? I get
what you mean about not including the weird like memory-side caches
but TLBs are also well known caches so I'd just go with
/* Caches, e.g. l2, l3 */
or something like that.
> + MPAM_CLASS_MEMORY, /* Main memory */
> + MPAM_CLASS_UNKNOWN, /* Everything else, e.g. SMMU */
> +};
> +
> +#ifdef CONFIG_ACPI_MPAM
> +/* Parse the ACPI description of resources entries for this MSC. */
I'd push more detailed documentation down along side the implementation
rather than having it here. The function name and parameters make this fairly
obvious anyway.
> +int acpi_mpam_parse_resources(struct mpam_msc *msc,
> + struct acpi_mpam_msc_node *tbl_msc);
> +
> +int acpi_mpam_count_msc(void);
> +#else
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 074754c23d33..23a30ada2d4c 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -232,6 +232,7 @@ extern int platform_device_add_data(struct platform_device *pdev,
> extern int platform_device_add(struct platform_device *pdev);
> extern void platform_device_del(struct platform_device *pdev);
> extern void platform_device_put(struct platform_device *pdev);
> +DEFINE_FREE(platform_device_put, struct platform_device *, if (_T) platform_device_put(_T))
I'd break this out as a separate precursor patch mostly so people notice it.
Likely will get some review from folk who aren't going to spot it down here.
They may well tell you to not have it as a separate patch but at least you'll
be sure it was noticed!
Jonathan
>
> struct platform_driver {
> int (*probe)(struct platform_device *);
next prev parent reply other threads:[~2025-10-24 16:13 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 18:56 [PATCH v3 00/29] arm_mpam: Add basic mpam driver James Morse
2025-10-17 18:56 ` [PATCH v3 01/29] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-10-24 11:26 ` Jonathan Cameron
2025-11-06 16:09 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 02/29] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-10-24 11:29 ` Jonathan Cameron
2025-11-06 16:10 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 03/29] ACPI / PPTT: Find cache level by cache-id James Morse
2025-10-20 10:34 ` Ben Horgan
2025-10-24 14:15 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 04/29] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-10-20 10:45 ` Ben Horgan
2025-10-22 12:58 ` Jeremy Linton
2025-10-24 14:22 ` Jonathan Cameron
2025-11-06 16:18 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 05/29] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-10-17 18:56 ` [PATCH v3 06/29] ACPI / MPAM: Parse the MPAM table James Morse
2025-10-20 12:29 ` Ben Horgan
2025-10-24 16:13 ` Jonathan Cameron [this message]
2025-11-06 16:55 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 07/29] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-10-20 12:43 ` Ben Horgan
2025-10-20 15:44 ` Ben Horgan
2025-10-21 9:51 ` Ben Horgan
2025-10-22 0:29 ` Fenghua Yu
2025-10-22 19:00 ` Tushar Dave
2025-10-24 16:25 ` Jonathan Cameron
2025-11-06 17:48 ` Markus Elfring
2025-10-17 18:56 ` [PATCH v3 08/29] arm_mpam: Add the class and component structures for firmware described ris James Morse
2025-10-24 16:47 ` Jonathan Cameron
2025-11-06 17:43 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 09/29] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-10-17 23:03 ` Fenghua Yu
2025-10-24 17:32 ` Jonathan Cameron
2025-10-27 16:33 ` Ben Horgan
2025-10-29 6:37 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 10/29] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-10-29 7:24 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 11/29] arm_mpam: Probe hardware to find the supported partid/pmg values James Morse
2025-10-24 17:40 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 12/29] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-10-24 17:43 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 13/29] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-10-24 17:47 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 14/29] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-10-17 18:56 ` [PATCH v3 15/29] arm_mpam: Reset MSC controls from cpuhp callbacks James Morse
2025-10-24 17:52 ` Jonathan Cameron
2025-10-29 6:53 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 16/29] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-10-17 18:56 ` [PATCH v3 17/29] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-10-20 15:14 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 18/29] arm_mpam: Register and enable IRQs James Morse
2025-10-24 18:03 ` Jonathan Cameron
2025-10-29 7:02 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 19/29] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-10-20 16:28 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 20/29] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-10-20 17:04 ` Ben Horgan
2025-10-27 8:47 ` Shaopeng Tan (Fujitsu)
2025-11-05 16:16 ` Peter Newman
2025-11-06 10:11 ` Ben Horgan
2025-10-29 7:09 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 21/29] arm_mpam: Probe and reset the rest of the features James Morse
2025-10-20 17:16 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 22/29] arm_mpam: Add helpers to allocate monitors James Morse
2025-10-17 18:56 ` [PATCH v3 23/29] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-10-24 18:18 ` Jonathan Cameron
2025-11-05 8:32 ` Shaopeng Tan (Fujitsu)
2025-11-05 12:11 ` Ben Horgan
2025-11-07 5:01 ` Shaopeng Tan (Fujitsu)
2025-11-07 10:01 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 24/29] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-10-22 13:39 ` [PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor overflow handling Zeng Heng
2025-10-22 16:17 ` Ben Horgan
2025-10-25 8:45 ` Zeng Heng
2025-10-25 9:34 ` [PATCH] arm64/mpam: Clean MBWU monitor overflow bit Zeng Heng
2025-10-28 17:37 ` Ben Horgan
2025-10-28 17:04 ` [PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor overflow handling Ben Horgan
2025-10-25 9:01 ` Zeng Heng
2025-10-28 16:01 ` Ben Horgan
2025-10-29 2:49 ` Zeng Heng
2025-10-29 3:59 ` Zeng Heng
2025-10-24 18:22 ` [PATCH v3 24/29] arm_mpam: Track bandwidth counter state for overflow and power management Jonathan Cameron
2025-10-29 7:56 ` [PATCH v2] arm64/mpam: Clean MBWU monitor overflow bit Zeng Heng
2025-10-30 9:52 ` Ben Horgan
2025-11-03 3:47 ` Zeng Heng
2025-11-04 10:24 ` Ben Horgan
2025-11-04 13:48 ` Zeng Heng
2025-10-17 18:56 ` [PATCH v3 25/29] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-10-22 11:23 ` Ben Horgan
2025-10-24 18:24 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 26/29] arm_mpam: Use long MBWU counters if supported James Morse
2025-10-22 12:31 ` Ben Horgan
2025-10-24 18:29 ` Jonathan Cameron
2025-11-06 15:18 ` Peter Newman
2025-11-06 15:43 ` Ben Horgan
2025-11-06 16:15 ` Peter Newman
2025-11-06 16:41 ` Ben Horgan
2025-11-07 10:30 ` Peter Newman
2025-11-07 10:53 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 27/29] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-10-24 18:34 ` Jonathan Cameron
2025-10-29 7:14 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 28/29] arm_mpam: Add kunit test for bitmap reset James Morse
2025-10-17 18:56 ` [PATCH v3 29/29] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-10-18 1:01 ` [PATCH v3 00/29] arm_mpam: Add basic mpam driver Fenghua Yu
2025-10-23 8:15 ` Shaopeng Tan (Fujitsu)
2025-11-05 9:39 ` Peter Newman
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=20251024171350.00005451@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=gshan@redhat.com \
--cc=guohanjun@huawei.com \
--cc=james.morse@arm.com \
--cc=jeremy.linton@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 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.