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]
Date: Fri, 17 May 2024 09:09:05 +0800 (CST)
From: "Slark Xiao" <slark_xiao@....com>
To: "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org>
Cc: "Manivannan Sadhasivam" <mani@...nel.org>, loic.poulain@...aro.org, 
	mhi@...ts.linux.dev, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, quic_qianyu@...cinc.com
Subject: Re:Re: Re: Re: Re: [PATCH] bus: mhi: host: Add Foxconn SDX72
 related support


At 2024-05-16 22:23:46, "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org> wrote:
>On Wed, May 15, 2024 at 08:17:23PM +0800, Slark Xiao wrote:
>> 
>> 
>> At 2024-05-15 19:52:39, "Manivannan Sadhasivam" <mani@...nel.org> wrote:
>> >On Wed, May 15, 2024 at 04:01:37PM +0800, Slark Xiao wrote:
>> >> 
>> >> At 2024-05-15 15:41:19, "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org> wrote:
>> >> >+ Qiang
>> >> >
>> >> >On Wed, May 15, 2024 at 09:29:20AM +0800, Slark Xiao wrote:
>> >> >> At 2024-05-14 22:37:41, "Manivannan Sadhasivam" <manivannan.sadhasivam@...aro.org> wrote:
>> >> >> >On Fri, May 10, 2024 at 11:26:57AM +0800, Slark Xiao wrote:
>> >> >> >> Align with Qcom SDX72, add ready timeout item for Foxconn SDX72.
>> >> >> >> And also, add firehose support since SDX72.
>> >> >> >> 
>> >> >> >> Signed-off-by: Slark Xiao <slark_xiao@....com>
>> >> >> >> ---
>> >> >> >>  drivers/bus/mhi/host/pci_generic.c | 31 ++++++++++++++++++++++++++++++
>> >> >> >>  1 file changed, 31 insertions(+)
>> >> >> >> 
>> >> >> >> diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
>> >> >> >> index 08844ee79654..0fd94c193fc6 100644
>> >> >> >> --- a/drivers/bus/mhi/host/pci_generic.c
>> >> >> >> +++ b/drivers/bus/mhi/host/pci_generic.c
>> >> >> >> @@ -399,6 +399,8 @@ static const struct mhi_channel_config mhi_foxconn_sdx55_channels[] = {
>> >> >> >>  	MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
>> >> >> >>  	MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
>> >> >> >>  	MHI_CHANNEL_CONFIG_DL(33, "DUN", 32, 0),
>> >> >> >> +	MHI_CHANNEL_CONFIG_UL_FP(34, "FIREHOSE", 32, 0),
>> >> >> >> +	MHI_CHANNEL_CONFIG_DL_FP(35, "FIREHOSE", 32, 0),
>> >> >> >
>> >> >> >This means SDX55 is also supporting FIREHOSE channels, which is not true I
>> >> >> >believe.
>> >> >> Actually, I just verified it with my sdx55 and the answer is Yes. These channels
>> >> >> are common settings for Qcom device which support PCIe mode. BTW, the
>> >> >> default settings of Qcom and Quectel support firehose for their sdx55 products.
>> >> >
>> >> >Qiang, can you please confirm that SDX55 supports FIREHOSE channels?
>> >> >
>> >> >> >
>> >> >> >>  	MHI_CHANNEL_CONFIG_HW_UL(100, "IP_HW0_MBIM", 128, 2),
>> >> >> >>  	MHI_CHANNEL_CONFIG_HW_DL(101, "IP_HW0_MBIM", 128, 3),
>> >> >> >>  };
>> >> >> >> @@ -419,6 +421,16 @@ static const struct mhi_controller_config modem_foxconn_sdx55_config = {
>> >> >> >>  	.event_cfg = mhi_foxconn_sdx55_events,
>> >> >> >>  };
>> >> >> >>  
>> >> >> >> +static const struct mhi_controller_config modem_foxconn_sdx72_config = {
>> >> >> >> +	.max_channels = 128,
>> >> >> >> +	.timeout_ms = 20000,
>> >> >> >> +	.ready_timeout_ms = 50000,
>> >> >> >> +	.num_channels = ARRAY_SIZE(mhi_foxconn_sdx55_channels),
>> >> >> >> +	.ch_cfg = mhi_foxconn_sdx55_channels,
>> >> >> >> +	.num_events = ARRAY_SIZE(mhi_foxconn_sdx55_events),
>> >> >> >> +	.event_cfg = mhi_foxconn_sdx55_events,
>> >> >> >> +};
>> >> >> >> +
>> >> >> >>  static const struct mhi_pci_dev_info mhi_foxconn_sdx24_info = {
>> >> >> >>  	.name = "foxconn-sdx24",
>> >> >> >>  	.config = &modem_foxconn_sdx55_config,
>> >> >> >> @@ -448,6 +460,16 @@ static const struct mhi_pci_dev_info mhi_foxconn_sdx65_info = {
>> >> >> >>  	.sideband_wake = false,
>> >> >> >>  };
>> >> >> >>  
>> >> >> >> +static const struct mhi_pci_dev_info mhi_foxconn_sdx72_info = {
>> >> >> >> +	.name = "foxconn-sdx72",
>> >> >> >> +	.edl = "qcom/sdx72m/xbl_s_devprg_ns.melf",
>> >> >> >
>> >> >> >What is '.melf'? Is the firmware available somewhere? Did you plan to upstream
>> >> >> >it to linux-firmware?
>> >> >> >
>> >> >> This file similar with "edl.mbn". In SDX72 product, the default "edl" file name is
>> >> >> "xbl_s_devprg_ns.melf". Currently we don't plan to upstream it to linux-firmware
>> >> >> since 2 reasons: 1: we share the same fold name sdx72m with qcom or other vendors
>> >> >> 2: this file may be changed since sdx72 product still under developing in our side. we
>> >> >> may change the base line according to QCOM release.
>> >> >
>> >> >Then I would ask you to add support when you have a stable firmware. I do not
>> >> >want to change the firmware name after some time as it will confuse users.
>> >> >
>> >> >- Mani
>> >> If a stable firmware must be provided, I think I shall change the folder name from qcom to
>> >> fox, do you agree this?
>> >
>> >Even in that case, where can the user find the firmware?
>> >
>> I think this edl file could help user let device enter into edl mode(wwan0firehose0).
>> For PCIE device, there is no opensource tool to support PCIE edl download. If user
>> could get the tool to do the firehose download, I think it's not hard to get complete firmware
>> from PC vendor or somewhere else.
>
>I was told that Qcom will upstream the PCI support for QDL in the coming weeks.
>Once that happens (even if a PR), I'll share that with you. Please test it and
>let me know if that works or not.
>
Sure. But I think this shall not the block cause for merging this patch, right?
Before that PR, we have verified the firehose function in our local with our
firehose tool which is not open. 
>And for entering EDL mode, we have recently added support to trigger EDL mode
>from host [1]. Could you also test that? You just need to add `edl_trigger =
>true` to the `mhi_pci_dev_info` struct of SDX72 and trigger EDL mode from host
>by:
>
>echo 1 > /sys/bus/mhi/devices/.../trigger_edl
>
Do you remember that I told you I want to merge such function from qualcomm driver
in last year? I merge the commit from QUD driver in my local. Actually it's same as the
commit [1], it's called "force_edl". And sure, the result is yes, it works well.

>> >> BTW, I need to check if it works after updating 'edl fw' from  xbl_s_devprg_ns.melf to
>> >> edl.mbn. 
>> 
>> >
>> >Okay. IMO, we should upstream the product support only after a stable firmware
>> >release (well stable in the sense a stable name at least).
>> >
>> >- Mani
>> The check result is we can rename it to align with previous format. Until now, 
>> I didn't see any mhi device has upstream their firmware to /lib/firmware/qcom folder.
>
>It is not mandatory, but it is a best practise that I recently started asking
>for.
>
>> If it's a must, I think we can upstream the edl file later.  Anyway, we hope we can
>> merge this sdx72 support into 6.10 since customer(Dell) would use this kernel for official
>> release. But no worry, we can make sure this firehose download method works well in
>>  our local side.
>> And also, please help a review about my previous email about fix sdx72 ping failure issue.
>> There is a fix solution from us. 
>> 
>
>Qiang is working on that.
Good to hear that. BTW, may I know the feature merge window in V6.10? I don't worry about
merge window of the network fix commit, since it's a fix with higher priority. But I want to
merge the basic support of my SDX72 before merge window close. This is important for us.

Thanks!
>
>- Mani
>
>[1] https://lore.kernel.org/mhi/1713928915-18229-1-git-send-email-quic_qianyu@quicinc.com/
>
>-- 
>மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ