public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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


  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