From: Ben Horgan <ben.horgan@arm.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: james.morse@arm.com, amitsinght@marvell.com,
baisheng.gao@unisoc.com, baolin.wang@linux.alibaba.com,
bobo.shaobowang@huawei.com, carl@os.amperecomputing.com,
catalin.marinas@arm.com, dakr@kernel.org, dave.martin@arm.com,
david@redhat.com, dfustini@baylibre.com, fenghuay@nvidia.com,
gregkh@linuxfoundation.org, gshan@redhat.com,
guohanjun@huawei.com, jeremy.linton@arm.com, kobak@nvidia.com,
lcherian@marvell.com, lenb@kernel.org,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, lpieralisi@kernel.org,
peternewman@google.com, quic_jiles@quicinc.com,
rafael@kernel.org, robh@kernel.org, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
sudeep.holla@arm.com, tan.shaopeng@fujitsu.com, will@kernel.org,
xhao@linux.alibaba.com
Subject: Re: [PATCH 03/33] ACPI / PPTT: Add acpi_pptt_cache_v1_full to use pptt cache as one structure
Date: Mon, 10 Nov 2025 16:28:10 +0000 [thread overview]
Message-ID: <17caf75c-a00f-41d8-bacc-af5ba6c485d9@arm.com> (raw)
In-Reply-To: <20251110154610.00002247@huawei.com>
Hi Jonathan,
On 11/10/25 15:46, Jonathan Cameron wrote:
> On Fri, 7 Nov 2025 12:34:20 +0000
> Ben Horgan <ben.horgan@arm.com> wrote:
>
>> In actbl2.h, struct acpi_pptt_cache describes the fields in the original
>> cache type structure. In PPTT table version 3 a new field was added at the
>> end, cache_id. This is described in struct acpi_pptt_cache_v1. Introduce
>> the new, acpi_pptt_cache_v1_full to contain both these structures. Update
>> the existing code to use this new struct. This simplifies the code, removes
>> a non-standard use of ACPI_ADD_PTR and allows using the length in the
>> header to check if the cache_id is valid.
>>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>
> Whilst I wish the ACPICA stuff did structures like this, I'm not sure
> if the ACPI maintainers will feel it is appropriate to work around it
> with generic sounding structures like this one.
>
> I'd also say that we should only cast it to your _full structure
> if we know we have rev 3 of PPTT. Otherwise we should continue manipulating
> it as a struct acpi_pptt_cache
Fair enough. My thinking was that you had to check the valid flag anyway
to use cache_id but it's less robust. I'll delay the casting to later
which IIUC is what Jeremy Linton suggested offline.
>
>> ---
>> Changes since v3:
>> New patch
>> ---
>> drivers/acpi/pptt.c | 104 ++++++++++++++++++++++++--------------------
>> 1 file changed, 58 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> index 1027ca3566b1..1ed2099c0d1a 100644
>> --- a/drivers/acpi/pptt.c
>> +++ b/drivers/acpi/pptt.c
>> @@ -21,6 +21,11 @@
>> #include <linux/cacheinfo.h>
>> #include <acpi/processor.h>
>>
>> +struct acpi_pptt_cache_v1_full {
>> + struct acpi_pptt_cache f;
>> + struct acpi_pptt_cache_v1 extra;
>> +} __packed;
>
>> +#define ACPI_PPTT_CACHE_V1_LEN sizeof(struct acpi_pptt_cache_v1_full)
>> +
>> +/*
>> + * From PPTT table version 3, a new field cache_id was added at the end of
>> + * the cache type structure. We now use struct acpi_pptt_cache_v1_full,
>> + * containing the cache_id, everywhere but must check validity before accessing
>> + * the cache_id.
>> + */
>> +static bool acpi_pptt_cache_id_is_valid(struct acpi_pptt_cache_v1_full *cache)
>> +{
>> + return (cache->f.header.length >= ACPI_PPTT_CACHE_V1_LEN &&
>
> Although I later say I don't think you should pass a v1_full structure in here (as
> we don't know it is at least that large until after this check) if you do keep this
> why not use sizeof(*cache) and get rid of the V1_LEN definition as providing no obvious
> value here?
Yes, the define was never needed.
>
>> + cache->f.flags & ACPI_PPTT_CACHE_ID_VALID);
>> }
>
>> @@ -355,7 +374,6 @@ static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *ta
>> * @this_leaf: Kernel cache info structure being updated
>> * @found_cache: The PPTT node describing this cache instance
>> * @cpu_node: A unique reference to describe this cache instance
>> - * @revision: The revision of the PPTT table
>> *
>> * The ACPI spec implies that the fields in the cache structures are used to
>> * extend and correct the information probed from the hardware. Lets only
>> @@ -364,23 +382,20 @@ static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *ta
>> * Return: nothing. Side effect of updating the global cacheinfo
>> */
>> static void update_cache_properties(struct cacheinfo *this_leaf,
>> - struct acpi_pptt_cache *found_cache,
>> - struct acpi_pptt_processor *cpu_node,
>> - u8 revision)
>> + struct acpi_pptt_cache_v1_full *found_cache,
>> + struct acpi_pptt_processor *cpu_node)
>> {
>> - struct acpi_pptt_cache_v1* found_cache_v1;
>> -
>> this_leaf->fw_token = cpu_node;
>> - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID)
>> - this_leaf->size = found_cache->size;
>> - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID)
>> - this_leaf->coherency_line_size = found_cache->line_size;
>> - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID)
>> - this_leaf->number_of_sets = found_cache->number_of_sets;
>> - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID)
>> - this_leaf->ways_of_associativity = found_cache->associativity;
>> - if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) {
>> - switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) {
>> + if (found_cache->f.flags & ACPI_PPTT_SIZE_PROPERTY_VALID)
>> + this_leaf->size = found_cache->f.size;
>> + if (found_cache->f.flags & ACPI_PPTT_LINE_SIZE_VALID)
>> + this_leaf->coherency_line_size = found_cache->f.line_size;
>> + if (found_cache->f.flags & ACPI_PPTT_NUMBER_OF_SETS_VALID)
>> + this_leaf->number_of_sets = found_cache->f.number_of_sets;
>> + if (found_cache->f.flags & ACPI_PPTT_ASSOCIATIVITY_VALID)
>> + this_leaf->ways_of_associativity = found_cache->f.associativity;
>> + if (found_cache->f.flags & ACPI_PPTT_WRITE_POLICY_VALID) {
>> + switch (found_cache->f.attributes & ACPI_PPTT_MASK_WRITE_POLICY) {
>> case ACPI_PPTT_CACHE_POLICY_WT:
>> this_leaf->attributes = CACHE_WRITE_THROUGH;
>> break;
>> @@ -389,8 +404,8 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
>> break;
>> }
>> }
>> - if (found_cache->flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) {
>> - switch (found_cache->attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) {
>> + if (found_cache->f.flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) {
>> + switch (found_cache->f.attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) {
>> case ACPI_PPTT_CACHE_READ_ALLOCATE:
>> this_leaf->attributes |= CACHE_READ_ALLOCATE;
>> break;
>> @@ -415,13 +430,11 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
>> * specified in PPTT.
>> */
>> if (this_leaf->type == CACHE_TYPE_NOCACHE &&
>> - found_cache->flags & ACPI_PPTT_CACHE_TYPE_VALID)
>> + found_cache->f.flags & ACPI_PPTT_CACHE_TYPE_VALID)
>> this_leaf->type = CACHE_TYPE_UNIFIED;
>>
>> - if (revision >= 3 && (found_cache->flags & ACPI_PPTT_CACHE_ID_VALID)) {
>> - found_cache_v1 = ACPI_ADD_PTR(struct acpi_pptt_cache_v1,
>> - found_cache, sizeof(struct acpi_pptt_cache));
>> - this_leaf->id = found_cache_v1->cache_id;
>> + if (acpi_pptt_cache_id_is_valid(found_cache)) {
>
> Only here do we know that found_cache is the _full type.
>
>> + this_leaf->id = found_cache->extra.cache_id;
>> this_leaf->attributes |= CACHE_ID;
>> }
>> }
>> @@ -429,7 +442,7 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
>> static void cache_setup_acpi_cpu(struct acpi_table_header *table,
>> unsigned int cpu)
>> {
>> - struct acpi_pptt_cache *found_cache;
>> + struct acpi_pptt_cache_v1_full *found_cache;
>
> This isn't necessarily valid. Until deep in update_cache_properties() we don't care about the ID
> so this structure may be smaller than this implies.
>
>> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>> u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
>> struct cacheinfo *this_leaf;
>> @@ -445,8 +458,7 @@ static void cache_setup_acpi_cpu(struct acpi_table_header *table,
>> pr_debug("found = %p %p\n", found_cache, cpu_node);
>> if (found_cache)
>> update_cache_properties(this_leaf, found_cache,
>> - ACPI_TO_POINTER(ACPI_PTR_DIFF(cpu_node, table)),
>> - table->revision);
>> + ACPI_TO_POINTER(ACPI_PTR_DIFF(cpu_node, table)));
>>
>> index++;
>> }
>
Thanks,
Ben
next prev parent reply other threads:[~2025-11-10 16:28 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 12:34 [PATCH 00/33] arm_mpam: Add basic mpam driver Ben Horgan
2025-11-07 12:34 ` [PATCH 01/33] ACPI / PPTT: Add a helper to fill a cpumask from a processor container Ben Horgan
2025-11-08 4:31 ` Gavin Shan
2025-11-12 10:14 ` Ben Horgan
2025-11-12 5:45 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 02/33] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels Ben Horgan
2025-11-11 7:34 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 03/33] ACPI / PPTT: Add acpi_pptt_cache_v1_full to use pptt cache as one structure Ben Horgan
2025-11-08 4:54 ` Gavin Shan
2025-11-10 15:51 ` Ben Horgan
2025-11-10 15:46 ` Jonathan Cameron
2025-11-10 16:28 ` Ben Horgan [this message]
2025-11-10 17:00 ` Jeremy Linton
2025-11-11 16:48 ` Ben Horgan
2025-11-12 20:22 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 04/33] ACPI / PPTT: Find cache level by cache-id Ben Horgan
2025-11-08 5:11 ` Gavin Shan
2025-11-10 16:02 ` Jonathan Cameron
2025-11-11 17:02 ` Ben Horgan
2025-11-12 20:23 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 05/33] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id Ben Horgan
2025-11-08 5:10 ` Gavin Shan
2025-11-10 16:04 ` Jonathan Cameron
2025-11-12 20:26 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 06/33] arm64: kconfig: Add Kconfig entry for MPAM Ben Horgan
2025-11-07 12:34 ` [PATCH 07/33] platform: Define platform_device_put cleanup handler Ben Horgan
2025-11-10 1:03 ` Gavin Shan
2025-11-10 16:07 ` Jonathan Cameron
2025-11-12 20:32 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 08/33] ACPI: Define acpi_put_table cleanup handler and acpi_get_table_ret() helper Ben Horgan
2025-11-10 1:03 ` Gavin Shan
2025-11-10 16:11 ` Jonathan Cameron
2025-11-12 7:02 ` Shaopeng Tan (Fujitsu)
2025-11-12 20:39 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 09/33] ACPI / MPAM: Parse the MPAM table Ben Horgan
2025-11-08 8:54 ` Gavin Shan
2025-11-10 16:27 ` Jonathan Cameron
2025-11-12 14:45 ` Ben Horgan
2025-11-10 16:23 ` Jonathan Cameron
2025-11-12 7:01 ` Shaopeng Tan (Fujitsu)
2025-11-12 14:55 ` Ben Horgan
2025-11-13 2:16 ` Fenghua Yu
2025-11-13 12:09 ` Ben Horgan
2025-11-13 2:33 ` Fenghua Yu
2025-11-13 14:24 ` Ben Horgan
2025-11-07 12:34 ` [PATCH 10/33] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate Ben Horgan
2025-11-08 9:28 ` Gavin Shan
2025-11-10 16:44 ` Jonathan Cameron
2025-11-12 15:32 ` Ben Horgan
2025-11-10 16:58 ` Jonathan Cameron
2025-11-12 16:05 ` Ben Horgan
2025-11-12 7:22 ` Shaopeng Tan (Fujitsu)
2025-11-12 15:37 ` Ben Horgan
2025-11-13 2:46 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 11/33] arm_mpam: Add the class and component structures for firmware described ris Ben Horgan
2025-11-09 0:07 ` Gavin Shan
2025-11-12 16:39 ` Ben Horgan
2025-11-12 16:48 ` Ben Horgan
2025-11-10 17:10 ` Jonathan Cameron
2025-11-12 17:21 ` Ben Horgan
2025-11-12 7:29 ` Shaopeng Tan (Fujitsu)
2025-11-13 3:23 ` Fenghua Yu
2025-11-13 16:39 ` Ben Horgan
2025-11-07 12:34 ` [PATCH 12/33] arm_mpam: Add MPAM MSC register layout definitions Ben Horgan
2025-11-09 0:25 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 13/33] arm_mpam: Add cpuhp callbacks to probe MSC hardware Ben Horgan
2025-11-07 12:34 ` [PATCH 14/33] arm_mpam: Probe hardware to find the supported partid/pmg values Ben Horgan
2025-11-09 0:43 ` Gavin Shan
2025-11-10 23:26 ` Gavin Shan
2025-11-11 9:30 ` Ben Horgan
2025-11-12 7:57 ` Shaopeng Tan (Fujitsu)
2025-11-13 3:50 ` Fenghua Yu
2025-11-13 16:43 ` Ben Horgan
2025-11-07 12:34 ` [PATCH 15/33] arm_mpam: Add helpers for managing the locking around the mon_sel registers Ben Horgan
2025-11-09 0:49 ` Gavin Shan
2025-11-12 8:03 ` Shaopeng Tan (Fujitsu)
2025-11-13 3:52 ` Fenghua Yu
2025-11-07 12:34 ` [PATCH 16/33] arm_mpam: Probe the hardware features resctrl supports Ben Horgan
2025-11-09 21:55 ` Gavin Shan
2025-11-12 8:17 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 17/33] arm_mpam: Merge supported features during mpam_enable() into mpam_class Ben Horgan
2025-11-09 21:59 ` Gavin Shan
2025-11-12 8:24 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 18/33] arm_mpam: Reset MSC controls from cpuhp callbacks Ben Horgan
2025-11-09 22:11 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 19/33] arm_mpam: Add a helper to touch an MSC from any CPU Ben Horgan
2025-11-09 22:13 ` Gavin Shan
2025-11-14 2:47 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 20/33] arm_mpam: Extend reset logic to allow devices to be reset any time Ben Horgan
2025-11-09 22:16 ` Gavin Shan
2025-11-13 20:24 ` Fenghua Yu
2025-11-14 2:52 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 21/33] arm_mpam: Register and enable IRQs Ben Horgan
2025-11-09 22:18 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 22/33] arm_mpam: Use a static key to indicate when mpam is enabled Ben Horgan
2025-11-09 22:20 ` Gavin Shan
2025-11-14 4:37 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 23/33] arm_mpam: Allow configuration to be applied and restored during cpu online Ben Horgan
2025-11-09 22:59 ` Gavin Shan
2025-11-13 17:14 ` Ben Horgan
2025-11-10 17:27 ` Jonathan Cameron
2025-11-11 17:45 ` Ben Horgan
2025-11-14 10:33 ` Ben Horgan
2025-11-14 14:34 ` Ben Horgan
2025-11-07 12:34 ` [PATCH 24/33] arm_mpam: Probe and reset the rest of the features Ben Horgan
2025-11-09 23:01 ` Gavin Shan
2025-11-14 7:04 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 25/33] arm_mpam: Add helpers to allocate monitors Ben Horgan
2025-11-09 23:02 ` Gavin Shan
2025-11-14 7:14 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 26/33] arm_mpam: Add mpam_msmon_read() to read monitor value Ben Horgan
2025-11-09 23:13 ` Gavin Shan
2025-11-14 10:07 ` Ben Horgan
2025-11-12 5:33 ` Shaopeng Tan (Fujitsu)
2025-11-07 12:34 ` [PATCH 27/33] arm_mpam: Track bandwidth counter state for power management Ben Horgan
2025-11-09 23:15 ` Gavin Shan
2025-11-10 13:49 ` Zeng Heng
2025-11-10 17:31 ` Jonathan Cameron
2025-11-07 12:34 ` [PATCH 28/33] arm_mpam: Consider overflow in bandwidth counter state Ben Horgan
2025-11-09 23:16 ` Gavin Shan
2025-11-10 13:50 ` Zeng Heng
2025-11-10 17:32 ` Jonathan Cameron
2025-11-07 12:34 ` [PATCH 29/33] arm_mpam: Probe for long/lwd mbwu counters Ben Horgan
2025-11-09 23:16 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 30/33] arm_mpam: Use long MBWU counters if supported Ben Horgan
2025-11-09 23:17 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 31/33] arm_mpam: Add helper to reset saved mbwu state Ben Horgan
2025-11-09 23:18 ` Gavin Shan
2025-11-10 17:34 ` Jonathan Cameron
2025-11-07 12:34 ` [PATCH 32/33] arm_mpam: Add kunit test for bitmap reset Ben Horgan
2025-11-09 23:19 ` Gavin Shan
2025-11-07 12:34 ` [PATCH 33/33] arm_mpam: Add kunit tests for props_mismatch() Ben Horgan
2025-11-09 23:19 ` Gavin Shan
2025-11-07 12:47 ` [PATCH 00/33] arm_mpam: Add basic mpam driver Ben Horgan
2025-11-07 21:22 ` Fenghua Yu
2025-11-07 23:22 ` Carl Worth
2025-11-10 16:15 ` Ben Horgan
2025-11-11 0:45 ` Carl Worth
2025-11-10 1:05 ` Gavin Shan
2025-11-10 13:56 ` Zeng Heng
2025-11-10 16:03 ` Ben Horgan
2025-11-11 7:09 ` Shaopeng Tan (Fujitsu)
2025-11-16 17:16 ` Drew Fustini
2025-11-18 14:11 ` Ben Horgan
2025-11-18 22:55 ` Drew Fustini
2025-11-19 10:00 ` Jonathan Cameron
2025-11-19 20:09 ` Drew Fustini
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=17caf75c-a00f-41d8-bacc-af5ba6c485d9@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