Re: [RFC PATCH 1/8] platform/x86/amd/hsmp: Add new HSMP messages for Family 1Ah, Model 50h-5Fh

[Qinyun Tan]

On Mon, 19 Jan 2026, Muralidhara M K wrote:
> The same firmware also extends three existing SET-only messages
> (HSMP_SET_XGMI_LINK_WIDTH 0x0C, HSMP_SET_DF_PSTATE 0x0D,
> HSMP_SET_PSTATE_MAX_MIN 0x22) with a read-back path selected by
> bit[31] of args[0] (0 = set, 1 = get). Without converting these
> entries to HSMP_SET_GET, userspace cannot query the currently
> programmed value even though firmware now supports it.

I noticed that HSMP_SET_XGMI_PSTATE_RANGE (0x26) is not converted
here. The esmi_ib_library already implements a GET path for it in
esmi_xgmi_pstate_range_get() using the same bit[31] convention:

  msg.msg_id    = HSMP_SET_XGMI_PSTATE_RANGE;
  msg.args[0]   = BIT(31);
  ret = hsmp_xfer(&msg, O_RDONLY);

Since the kernel descriptor is still {1, 0, HSMP_SET}, hsmp_ioctl()
would reject the O_RDONLY open with -EPERM because is_get_msg() only
recognises HSMP_GET and HSMP_SET_GET types.

>  	/*
> -	 * HSMP_SET_XGMI_LINK_WIDTH, num_args = 1, response_sz = 0
> +	 * HSMP_SET_XGMI_LINK_WIDTH, num_args = 1, response_sz = 0/1
> +	 * input: args[0] = set/get XGMI Link width[31] (0 = set, 1 = get) +
[...]
> -	{1, 0, HSMP_SET},
> +	{1, 1, HSMP_SET_GET},

Does HSMP_SET_XGMI_PSTATE_RANGE also need the same conversion?

Thanks,
Qinyun