From: Ben Horgan <ben.horgan@arm.com>
To: Peter Newman <peternewman@google.com>
Cc: James Morse <james.morse@arm.com>,
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>,
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,
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>,
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 26/29] arm_mpam: Use long MBWU counters if supported
Date: Fri, 7 Nov 2025 10:53:32 +0000 [thread overview]
Message-ID: <1b8875ab-39ee-4a9c-9f99-0a8f6b80a2ca@arm.com> (raw)
In-Reply-To: <CALPaoCg7ZeQOgkeaPQ6ERKtaJqQ_n3xQUrK=qxi01CnuTjL4PA@mail.gmail.com>
Hi Peter,
On 11/7/25 10:30, Peter Newman wrote:
> Hi Ben
>
> On Thu, Nov 6, 2025 at 5:41 PM Ben Horgan <ben.horgan@arm.com> wrote:
>>
>> Hi Peter,
>>
>> On 11/6/25 16:15, Peter Newman wrote:
>>> Hi Ben (and James),
>>>
>>> On Fri, Oct 17, 2025 at 8:59 PM James Morse <james.morse@arm.com> wrote:
>>>>
>>>> From: Rohit Mathew <rohit.mathew@arm.com>
>>>>
>>>> Now that the larger counter sizes are probed, make use of them.
>>>>
>>>> Callers of mpam_msmon_read() may not know (or care!) about the different
>>>> counter sizes. Allow them to specify mpam_feat_msmon_mbwu and have the
>>>> driver pick the counter to use.
>>>>
>>>> Only 32bit accesses to the MSC are required to be supported by the
>>>> spec, but these registers are 64bits. The lower half may overflow
>>>> into the higher half between two 32bit reads. To avoid this, use
>>>> a helper that reads the top half multiple times to check for overflow.
>>>>
>>>> Signed-off-by: Rohit Mathew <rohit.mathew@arm.com>
>>>> [morse: merged multiple patches from Rohit, added explicit counter selection ]
>>>> Signed-off-by: James Morse <james.morse@arm.com>
>>>> Reviewed-by: Ben Horgan <ben.horgan@arm.com>
>>>> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>>>> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com>
>>>> Tested-by: Fenghua Yu <fenghuay@nvidia.com>
>>>> ---
>>>> Changes since v2:
>>>> * Removed mpam_feat_msmon_mbwu as a top-level bit for explicit 31bit counter
>>>> selection.
>>>> * Allow callers of mpam_msmon_read() to specify mpam_feat_msmon_mbwu and have
>>>> the driver pick a supported counter size.
>>>> * Rephrased commit message.
>>>>
>>>> Changes since v1:
>>>> * Only clear OFLOW_STATUS_L on MBWU counters.
>>>>
>>>> Changes since RFC:
>>>> * Commit message wrangling.
>>>> * Refer to 31 bit counters as opposed to 32 bit (registers).
>>>> ---
>>>> drivers/resctrl/mpam_devices.c | 134 ++++++++++++++++++++++++++++-----
>>>> 1 file changed, 116 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>>>> index f4d07234ce10..c207a6d2832c 100644
>>>> --- a/drivers/resctrl/mpam_devices.c
>>>> +++ b/drivers/resctrl/mpam_devices.c
>>>> @@ -897,6 +897,48 @@ struct mon_read {
>>>> int err;
>>>> };
>>>>
>>>> +static bool mpam_ris_has_mbwu_long_counter(struct mpam_msc_ris *ris)
>>>> +{
>>>> + return (mpam_has_feature(mpam_feat_msmon_mbwu_63counter, &ris->props) ||
>>>> + mpam_has_feature(mpam_feat_msmon_mbwu_44counter, &ris->props));
>>>> +}
>>>> +
>>>> +static u64 mpam_msc_read_mbwu_l(struct mpam_msc *msc)
>>>> +{
>>>> + int retry = 3;
>>>> + u32 mbwu_l_low;
>>>> + u64 mbwu_l_high1, mbwu_l_high2;
>>>> +
>>>> + mpam_mon_sel_lock_held(msc);
>>>> +
>>>> + WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz);
>>>> + WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility));
>>>> +
>>>> + mbwu_l_high2 = __mpam_read_reg(msc, MSMON_MBWU_L + 4);
>>>> + do {
>>>> + mbwu_l_high1 = mbwu_l_high2;
>>>> + mbwu_l_low = __mpam_read_reg(msc, MSMON_MBWU_L);
>>>> + mbwu_l_high2 = __mpam_read_reg(msc, MSMON_MBWU_L + 4);
>>>> +
>>>> + retry--;
>>>> + } while (mbwu_l_high1 != mbwu_l_high2 && retry > 0);
>>>> +
>>>> + if (mbwu_l_high1 == mbwu_l_high2)
>>>> + return (mbwu_l_high1 << 32) | mbwu_l_low;
>>>> + return MSMON___NRDY_L;
>>>> +}
>>>> +
>>>> +static void mpam_msc_zero_mbwu_l(struct mpam_msc *msc)
>>>> +{
>>>> + mpam_mon_sel_lock_held(msc);
>>>> +
>>>> + WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz);
>>>> + WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility));
>>>> +
>>>> + __mpam_write_reg(msc, MSMON_MBWU_L, 0);
>>>> + __mpam_write_reg(msc, MSMON_MBWU_L + 4, 0);
>>>> +}
>>>> +
>>>> static void gen_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val,
>>>> u32 *flt_val)
>>>> {
>>>> @@ -924,7 +966,9 @@ static void gen_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val,
>>>> ctx->csu_exclude_clean);
>>>>
>>>> break;
>>>> - case mpam_feat_msmon_mbwu:
>>>> + case mpam_feat_msmon_mbwu_31counter:
>>>> + case mpam_feat_msmon_mbwu_44counter:
>>>> + case mpam_feat_msmon_mbwu_63counter:
>>>> *ctl_val |= MSMON_CFG_MBWU_CTL_TYPE_MBWU;
>>>>
>>>> if (mpam_has_feature(mpam_feat_msmon_mbwu_rwbw, &m->ris->props))
>>>> @@ -946,7 +990,9 @@ static void read_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val,
>>>> *ctl_val = mpam_read_monsel_reg(msc, CFG_CSU_CTL);
>>>> *flt_val = mpam_read_monsel_reg(msc, CFG_CSU_FLT);
>>>> return;
>>>> - case mpam_feat_msmon_mbwu:
>>>> + case mpam_feat_msmon_mbwu_31counter:
>>>> + case mpam_feat_msmon_mbwu_44counter:
>>>> + case mpam_feat_msmon_mbwu_63counter:
>>>> *ctl_val = mpam_read_monsel_reg(msc, CFG_MBWU_CTL);
>>>> *flt_val = mpam_read_monsel_reg(msc, CFG_MBWU_FLT);
>>>> return;
>>>> @@ -959,6 +1005,9 @@ static void read_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val,
>>>> static void clean_msmon_ctl_val(u32 *cur_ctl)
>>>> {
>>>> *cur_ctl &= ~MSMON_CFG_x_CTL_OFLOW_STATUS;
>>>> +
>>>> + if (FIELD_GET(MSMON_CFG_x_CTL_TYPE, *cur_ctl) == MSMON_CFG_MBWU_CTL_TYPE_MBWU)
>>>> + *cur_ctl &= ~MSMON_CFG_MBWU_CTL_OFLOW_STATUS_L;
>>>> }
>>>>
>>>> static void write_msmon_ctl_flt_vals(struct mon_read *m, u32 ctl_val,
>>>> @@ -978,10 +1027,15 @@ static void write_msmon_ctl_flt_vals(struct mon_read *m, u32 ctl_val,
>>>> mpam_write_monsel_reg(msc, CSU, 0);
>>>> mpam_write_monsel_reg(msc, CFG_CSU_CTL, ctl_val | MSMON_CFG_x_CTL_EN);
>>>> break;
>>>> - case mpam_feat_msmon_mbwu:
>>>> + case mpam_feat_msmon_mbwu_44counter:
>>>> + case mpam_feat_msmon_mbwu_63counter:
>>>> + mpam_msc_zero_mbwu_l(m->ris->vmsc->msc);
>>>> + fallthrough;
>>>> + case mpam_feat_msmon_mbwu_31counter:
>>>> mpam_write_monsel_reg(msc, CFG_MBWU_FLT, flt_val);
>>>> mpam_write_monsel_reg(msc, CFG_MBWU_CTL, ctl_val);
>>>> mpam_write_monsel_reg(msc, MBWU, 0);
>>>
>>> The fallthrough above seems to be problematic, assuming the MBWU=0
>>> being last for 31-bit was intentional. For long counters, this is
>>> zeroing the counter before updating the filter/control registers, but
>>> then clearing the 32-bit version of the counter. This fails to clear
>>> the NRDY bit on the long counter, which isn't cleared by software
>>> anywhere else.
>>>
>>> From section 10.3.2 from the MPAM spec shared:
>>>
>>> "On a counting monitor, the NRDY bit remains set until it is reset by
>>> software writing it as 0 in the monitor register, or automatically
>>> after the monitor is captured in the capture register by a capture
>>> event"
>>>
>>> If I update the 63-bit case to call
>>> mpam_msc_zero_mbwu_l(m->ris->vmsc->msc) after updating the
>>> control/filter registers (in addition to the other items I pointed in
>>> my last reply), I'm able to read MBWU counts from my hardware through
>>> mbm_total_bytes.
>>>
>>> Thanks,
>>> -Peter
>>
>> Thanks for the testing and flagging the problem. We should do the
>> configuration in the same order for all the monitors.
>>
>> I'll change the case to:
>>
>> case mpam_feat_msmon_mbwu_31counter:
>> case mpam_feat_msmon_mbwu_44counter:
>> case mpam_feat_msmon_mbwu_63counter:
>> mpam_write_monsel_reg(msc, CFG_MBWU_FLT, flt_val);
>> mpam_write_monsel_reg(msc, CFG_MBWU_CTL, ctl_val);
>>
>> if (m->type == mpam_feat_msmon_mbwu_31counter)
>> mpam_write_monsel_reg(msc, MBWU, 0);
>> else
>> mpam_msc_zero_mbwu_l(m->ris->vmsc->msc);
>>
>> mpam_write_monsel_reg(msc, CFG_MBWU_CTL, ctl_val | MSMON_CFG_x_CTL_EN);
>> break;
>
> I tried this out but wasn't able to read the counters. I needed to
> move the MBWU[_L] write to the end. Writing the registers directly on
> the hardware I'm testing with, I confirmed that just flipping
> MBWU_CTL.EN sets NRDY:
>
> MBWU_L=0x880
> MBWU_CTL=0x828
>
> / # mmio_read32 $((msc + MBWU_CTL))
> 0x80030042
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x03ecb2c0
> 0x00000000
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x03f70580
> 0x00000000
>
> Clear MBWU_CTL.EN:
>
> / # mmio_write32 $((msc + MBWU_CTL)) 0x00030042
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x05004680
> 0x80000000
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x05004680
> 0x80000000
>
> Clear NRDY and reenable MBWU_CTL.EN:
>
> / # mmio_write32 $((msc + MBWU_L)) 0; mmio_write32 $((msc + MBWU_L + 4)) 0
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x00000000
> 0x00000000
> / # mmio_write32 $((msc + MBWU_CTL)) 0x80030042
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x001dee80
> 0x80000000
>
> In fact, re-writing the same value back into MBWU_CTL.EN also sets NRDY:
>
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x00253e00
> 0x00000000
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x00b1a6c0
> 0x00000000
> / # mmio_write32 $((msc + MBWU_CTL)) 0x80030042
> / # mmio_read32 $((msc + MBWU_L)); mmio_read32 $((msc + MBWU_L + 4))
> 0x018d1d40
> 0x80000000
>
> Thanks,
> -Peter
Thank you very much for the quick testing and diagnosis. It does seeem
reasonable that the .EN flip would be considered a configuration change
and so indeed the writing NRDY (and the value) should happend after for
counting monitors (mbwu). I'll make this change now.
Thanks,
Ben
next prev parent reply other threads:[~2025-11-07 10:53 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
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 [this message]
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=1b8875ab-39ee-4a9c-9f99-0a8f6b80a2ca@arm.com \
--to=ben.horgan@arm.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=jonathan.cameron@huawei.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;
as well as URLs for NNTP newsgroup(s).