Re: [PATCH 2/2] platform/x86/amd/hsmp: Add support for variable-sized metrics tables

From: Ramalingam, Muthusamy

Date: Wed Apr 01 2026 - 08:39:19 EST


Hi Ilpo,
Thanks for input.

On 01-04-2026 04:59 pm, Ilpo Järvinen wrote:
On Wed, 1 Apr 2026, Ramalingam, Muthusamy wrote:

Hi Ilpo,

Thank you for the suggestions. I will update version v2 shortly to address the
comments listed below.

On 31-03-2026 02:13 pm, Ilpo Järvinen wrote:
On Thu, 5 Mar 2026, Muthusamy Ramalingam wrote:

Add support for the new metrics table format introduced in AMD Family 1Ah
Model 50h-5Fh processors with HSMP protocol version 7.

Use CPU family/model and protocol versions to map respective
variable-sized
metric table configurations.
The exported hsmp_metric_tbl_read() function provides offset support for
variable-sized tables.

This patch should be split into multiple changes.
Sure.

Co-developed-by: Muralidhara M K <muralimk@xxxxxxx>
Signed-off-by: Muralidhara M K <muralimk@xxxxxxx>
Signed-off-by: Muthusamy Ramalingam <muthusamy.ramalingam@xxxxxxx>
---
arch/x86/include/uapi/asm/amd_hsmp.h | 86 ++++++++++++++++++++++++++++
drivers/platform/x86/amd/hsmp/acpi.c | 9 +--
drivers/platform/x86/amd/hsmp/hsmp.c | 83 ++++++++++++++++++++++-----
drivers/platform/x86/amd/hsmp/hsmp.h | 3 +-
drivers/platform/x86/amd/hsmp/plat.c | 3 +-
5 files changed, 164 insertions(+), 20 deletions(-)

--- a/drivers/platform/x86/amd/hsmp/acpi.c
+++ b/drivers/platform/x86/amd/hsmp/acpi.c

@@ -403,8 +424,44 @@ int hsmp_get_tbl_dram_base(u16 sock_ind)
dev_err(sock->dev, "Invalid DRAM address for metric table\n");
return -ENOMEM;
}
- sock->metric_tbl_addr = devm_ioremap(sock->dev, dram_addr,
- sizeof(struct
hsmp_metric_table));
+
+ /* Get metric table version */
+ msg_tbl_ver.sock_ind = sock_ind;
+ msg_tbl_ver.response_sz =
hsmp_msg_desc_table[HSMP_GET_METRIC_TABLE_VER].response_sz;
+ msg_tbl_ver.msg_id = HSMP_GET_METRIC_TABLE_VER;
+
+ ret = hsmp_send_message(&msg_tbl_ver);
+ if (ret)
+ return ret;
+
+ table_ver = msg_tbl_ver.args[0];
+
+ hsmp_pdev.hsmp_table_size = 0;

Is this necessary?

Yes, We want this for unsupported family check.

Isn't this initialized to its default value which is 0? So why it needs to
be explicitly done again?
you are right, I will verify once and update in v2.