mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baochen Qiang <quic_bqiang@quicinc.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Qiang Yu <qiang.yu@oss.qualcomm.com>
Cc: <jeff.hugo@oss.qualcomm.com>, <mhi@lists.linux.dev>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<can.guo@oss.qualcomm.com>,
	Mayank Rana <mayank.rana@oss.qualcomm.com>
Subject: Re: [PATCH v2] mhi: host: Add standard elf image download functionality
Date: Fri, 6 Jun 2025 09:58:06 +0800	[thread overview]
Message-ID: <9ab8e8f8-e176-44ab-b8e5-0c27e5eff30b@quicinc.com> (raw)
In-Reply-To: <sdhop6vyvt4y63tbbtorqfd5xa4ckbiwxdad5g6zzwlljqvd6q@eoaqmairdeey>



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@oss.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@oss.qualcomm.com>
>> Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>> Signed-off-by: Qiang Yu <qiang.yu@oss.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?

> 
> - Mani
> 


  reply	other threads:[~2025-06-06  1:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03  9:05 Qiang Yu
2025-06-03  9:10 ` Baochen Qiang
2025-06-05 17:04 ` Manivannan Sadhasivam
2025-06-06  1:58   ` Baochen Qiang [this message]
2025-06-17  9:23     ` Manivannan Sadhasivam
2025-06-19  7:42       ` Qiang Yu
2025-06-06  7:53   ` Qiang Yu
2025-06-17  9:19     ` Manivannan Sadhasivam
2025-06-19  3:44       ` Qiang Yu

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=9ab8e8f8-e176-44ab-b8e5-0c27e5eff30b@quicinc.com \
    --to=quic_bqiang@quicinc.com \
    --cc=can.guo@oss.qualcomm.com \
    --cc=jeff.hugo@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mayank.rana@oss.qualcomm.com \
    --cc=mhi@lists.linux.dev \
    --cc=qiang.yu@oss.qualcomm.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

all inboxes | Powered by JetHome®