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] [day] [month] [year] [list]

Message-ID: <q3uxu5cki7c3nkv65kozibiz7ofjcm3clelog3oaqcya32kph4@ntvsqbshmeuw>
Date: Tue, 17 Jun 2025 14:53:02 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Baochen Qiang <quic_bqiang@...cinc.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, 
	Qiang Yu <qiang.yu@....qualcomm.com>, 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 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.

- Mani

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