mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
To: Jay Buddhabhatti <jay.buddhabhatti@amd.com>,
	michal.simek@amd.com, git@amd.com
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] firmware: xilinx: Use TF-A feature check for TF-A specific APIs
Date: Fri, 24 Jul 2026 12:01:10 +0530	[thread overview]
Message-ID: <d910521d-0446-4b78-b717-062c263eea9f@linux.microsoft.com> (raw)
In-Reply-To: <20260723124841.2567827-5-jay.buddhabhatti@amd.com>

Hi Jay,

On 23-07-2026 18:18, Jay Buddhabhatti wrote:
> Currently, TF-A-specific APIs are validated using the firmware
> PM_FEATURE_CHECK API, even though TF-A provides a dedicated mechanism via
> PM_API_FEATURES API. Ideally it should use the TF-A feature check
> (PM_API_FEATURES) for TF-A specific APIs. Update the feature check logic
> for TF-A specific API calls to ensure it is validated using
> PM_API_FEATURES. If this check fails, fall back to the legacy
> PM_FEATURE_CHECK to support backward compatibility.
> 
> When do_fw_call() fails, propagate the errno from zynqmp_pm_ret_code()
> instead of always returning -EOPNOTSUPP. This applies to every module ID,
> not only TF-A, because the rewrite sat in the common failure path.
> Existing callers only test ret < 0 and are unchanged.
> 
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
> ---
>   drivers/firmware/xilinx/zynqmp.c | 31 +++++++++++++++++--------------
>   1 file changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index fc7212f554ee..0b6c20a1d8be 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -224,34 +224,37 @@ static int __do_feature_check_call(const u32 api_id, u32 *ret_payload)
>   	module_id = FIELD_GET(MODULE_ID_MASK, api_id);
>   
>   	/*
> -	 * Feature check of APIs belonging to PM, XSEM, and TF-A are handled by calling
> +	 * Feature check of APIs belonging to PM and XSEM are handled by calling
>   	 * PM_FEATURE_CHECK API. For other modules, call PM_API_FEATURES API.
>   	 */
> -	if (module_id == PM_MODULE_ID || module_id == XSEM_MODULE_ID || module_id == TF_A_MODULE_ID)
> +	if (module_id == PM_MODULE_ID || module_id == XSEM_MODULE_ID)
>   		feature_check_api_id = PM_FEATURE_CHECK;
>   	else
>   		feature_check_api_id = PM_API_FEATURES;
>   
> -	/*
> -	 * Feature check of TF-A APIs is done in the TF-A layer and it expects for
> -	 * MODULE_ID_MASK bits of SMC's arg[0] to be the same as PM_MODULE_ID.
> -	 */
> -	if (module_id == TF_A_MODULE_ID) {
> -		module_id = PM_MODULE_ID;
> +	if (module_id == TF_A_MODULE_ID)
>   		smc_arg[1] = api_id;
> -	} else {
> +	else
>   		smc_arg[1] = (api_id & API_ID_MASK);
> -	}
>   
>   	smc_arg[0] = PM_SIP_SVC | FIELD_PREP(MODULE_ID_MASK, module_id) | feature_check_api_id;
>   
>   	ret = do_fw_call(ret_payload, 2, smc_arg[0], smc_arg[1]);
> +
> +	/*
> +	 * For TF-A APIs, if the feature check with PM_API_FEATURES fails,
> +	 * retry with the legacy PM_FEATURE_CHECK for backward compatibility.
> +	 */
> +	if (module_id == TF_A_MODULE_ID && ret) {
> +		smc_arg[0] = PM_SIP_SVC | FIELD_PREP(MODULE_ID_MASK, PM_MODULE_ID) |
> +			     PM_FEATURE_CHECK;
> +		ret = do_fw_call(ret_payload, 2, smc_arg[0], smc_arg[1]);
> +	}

This looks like a general improvement unrelated to the other patches in 
this series. I think this should go as a separate patch (not as a part 
of this series).

> +
>   	if (ret)
> -		ret = -EOPNOTSUPP;
> -	else
> -		ret = ret_payload[1];
> +		return ret;
>   
> -	return ret;
> +	return ret_payload[1];
>   }
>   
>   static int do_feature_check_call(const u32 api_id)

The return value change is separate improvement unrelated to the series 
or to the PM_API_FEATURES API usage. I think this change can be carved 
out to a separate patch.

Except for the above nits, code looks good to me.

Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>

Regards,
Prasanna Kumar

  parent reply	other threads:[~2026-07-24  6:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 12:48 [PATCH 0/4] firmware: xilinx: Clean up firmware and TF-A state on kexec Jay Buddhabhatti
2026-07-23 12:48 ` [PATCH 1/4] firmware: xilinx: Add support to clear TF-A PM state Jay Buddhabhatti
2026-07-23 16:25   ` Pandey, Radhey Shyam
2026-07-24  6:17   ` Prasanna Kumar T S M
2026-07-23 12:48 ` [PATCH 2/4] firmware: xilinx: Release all peripheral devices from firmware Jay Buddhabhatti
2026-07-23 16:25   ` Pandey, Radhey Shyam
2026-07-24  6:17   ` Prasanna Kumar T S M
2026-07-23 12:48 ` [PATCH 3/4] firmware: xilinx: Clear firmware notifiers across kexec transitions Jay Buddhabhatti
2026-07-23 16:27   ` Pandey, Radhey Shyam
2026-07-24  6:18   ` Prasanna Kumar T S M
2026-07-23 12:48 ` [PATCH 4/4] firmware: xilinx: Use TF-A feature check for TF-A specific APIs Jay Buddhabhatti
2026-07-23 16:28   ` Pandey, Radhey Shyam
2026-07-24  6:31   ` Prasanna Kumar T S M [this message]
2026-07-24  7:37     ` Buddhabhatti, Jay
2026-07-24  9:52 ` [PATCH v2 0/3] firmware: xilinx: Clean up firmware and TF-A state on kexec Jay Buddhabhatti
2026-07-24  9:52   ` [PATCH v2 1/4] firmware: xilinx: Add support to clear TF-A PM state Jay Buddhabhatti
2026-07-24  9:53   ` [PATCH v2 2/4] firmware: xilinx: Release all peripheral devices from firmware Jay Buddhabhatti
2026-07-24  9:53   ` [PATCH v2 3/4] firmware: xilinx: Clear firmware notifiers across kexec transitions Jay Buddhabhatti
2026-07-24 10:19   ` [PATCH v3 0/3] firmware: xilinx: Clean up firmware and TF-A state on kexec Jay Buddhabhatti
2026-07-24 10:19     ` [PATCH v3 1/3] firmware: xilinx: Add support to clear TF-A PM state Jay Buddhabhatti
2026-07-24 11:13       ` Sudeep Holla
2026-07-29  7:05         ` Jay Buddhabhatti
2026-07-24 10:19     ` [PATCH v3 2/3] firmware: xilinx: Release all peripheral devices from firmware Jay Buddhabhatti
2026-07-24 10:19     ` [PATCH v3 3/3] firmware: xilinx: Clear firmware notifiers across kexec transitions Jay Buddhabhatti
2026-07-29 12:25     ` [PATCH v4 0/3] firmware: xilinx: Clean up firmware and EL3 state on kexec Jay Buddhabhatti
2026-07-29 12:25       ` [PATCH v4 1/3] firmware: xilinx: Add support to clear EL3 PM state Jay Buddhabhatti
2026-07-29 12:25       ` [PATCH v4 2/3] firmware: xilinx: Release all peripheral devices from firmware Jay Buddhabhatti
2026-07-29 12:25       ` [PATCH v4 3/3] firmware: xilinx: Clear firmware notifiers across kexec transitions Jay Buddhabhatti
2026-08-06 13:27       ` [PATCH v4 0/3] firmware: xilinx: Clean up firmware and EL3 state on kexec Michal Simek

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=d910521d-0446-4b78-b717-062c263eea9f@linux.microsoft.com \
    --to=ptsm@linux.microsoft.com \
    --cc=git@amd.com \
    --cc=jay.buddhabhatti@amd.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.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

Powered by JetHome