linux-kernel - Re: [PATCH v2] mhi: host: Add standard elf image download functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <sdhop6vyvt4y63tbbtorqfd5xa4ckbiwxdad5g6zzwlljqvd6q@eoaqmairdeey>
Date: Thu, 5 Jun 2025 22:34:50 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Qiang Yu <qiang.yu@....qualcomm.com>
Cc: jeff.hugo@....qualcomm.com, mhi@...ts.linux.dev, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, quic_bqiang@...cinc.com, 
	can.guo@....qualcomm.com, Mayank Rana <mayank.rana@....qualcomm.com>
Subject: Re: [PATCH v2] mhi: host: Add standard elf image download
 functionality

On Tue, Jun 03, 2025 at 02:05:44AM -0700, Qiang Yu wrote:
> From: Mayank Rana <mayank.rana@....qualcomm.com>
> 
> Currently, the FBC image is a non-standard ELF file that contains a single
> ELF header, followed by segments for SBL, RDDM, and AMSS. Some devices are
> unable to process this non-standard ELF format and therefore require
> special handling during image loading.
> 

What are those "some devices"? Why are they not able to process this format
which is used across the rest of the Qcom devices?

> Add standard_elf_image flag to determine whether the device can process
> the non-standard ELF format. If this flag is set, a standard ELF image
> must be loaded, meaning the first 512 KB of the FBC image should be
> skipped when loading the AMSS image over the BHIe interface.

Please explain what is present in the first 512KiB and why skipping that is
required.

> Note that
> this flag does not affect the SBL image download process.
> 
> Signed-off-by: Mayank Rana <mayank.rana@....qualcomm.com>
> Co-developed-by: Qiang Yu <qiang.yu@....qualcomm.com>
> Signed-off-by: Qiang Yu <qiang.yu@....qualcomm.com>
> ---
> Changes in v2:
> - V1 patch is paused because of no user. WLAN team plan to add support for
>   new WLAN chip that requires this patch, so send v2.
> - Change author and SOB with new mail address.
> - Reword commit message.
> - Place standard_elf_image flag after wake_set in struct mhi_controller
> - Link to v1: https://lore.kernel.org/mhi/1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com/
> ---
>  drivers/bus/mhi/host/boot.c | 7 +++++++
>  include/linux/mhi.h         | 4 ++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> index efa3b6dddf4d2f937535243bd8e8ed32109150a4..f1686a8e0681d49f778838820b44f4c845ddbd1f 100644
> --- a/drivers/bus/mhi/host/boot.c
> +++ b/drivers/bus/mhi/host/boot.c
> @@ -584,6 +584,13 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>  	 * device transitioning into MHI READY state
>  	 */
>  	if (fw_load_type == MHI_FW_LOAD_FBC) {
> +		dev_dbg(dev, "standard_elf_image:%s\n",
> +			(mhi_cntrl->standard_elf_image ? "True" : "False"));

This print is just a noise even for debug.

> +		if (mhi_cntrl->standard_elf_image) {
> +			fw_data += mhi_cntrl->sbl_size;
> +			fw_sz -= mhi_cntrl->sbl_size;

Is it possible to detect the image type during runtime instead of using a flag?
Also, the flag is currently unused. So it should come along an user.

- Mani

-- 
மணிவண்ணன் சதாசிவம்