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 for Android: free password hash cracker in your pocket

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

Message-ID: <aFO/ahs3LwUvKpAB@hu-qianyu-lv.qualcomm.com>
Date: Thu, 19 Jun 2025 00:42:34 -0700
From: Qiang Yu <qiang.yu@....qualcomm.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Baochen Qiang <quic_bqiang@...cinc.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        jeff.hugo@....qualcomm.com, mhi@...ts.linux.dev,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        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 17, 2025 at 02:53:02PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Jun 06, 2025 at 09:58:06AM +0800, Baochen Qiang wrote:
> > 
> > 
> > On 6/6/2025 1:04 AM, Manivannan Sadhasivam wrote:
> > > 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.
> > 
> > The flag would be used when a new WLAN device getting upstream. So either we merge this
> > patch alone, or we get it grouped within the WLAN patches. Kindly share your thoughts?
> > 
> 
> For the reason I mentioned in my previous reply, I don't think we should rely on
> the flag unless the WLAN device is shipped with *only* the new FW. If that is
> the case, then please send this patch when the ath driver support shows up. I
> do not want to merge a patch with an unused interface.
>

I discussed with Wlan FW team. For a specific model of wlan chip, only one
format image will be released.

- Qiang Yu

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