Hello Yonglin,
On Mon, Feb 21, 2022 at 7:21 PM 谭 永林 <[email protected]> wrote:
> SAHARA protocol is used not only to dump the memory but also to enable FW downloading.
> The protocol is designed primarily for transferring software images from a host to a target and provides a simple mechanism for requesting data to be transferred over any physical link.
>
> To conclude, the SAHARA port provide a mechanism to transfer messages between host and device during SBL.
>
> -----邮件原件-----
> 发件人: Loic Poulain <[email protected]>
> 发送时间: 2022年2月22日 0:03
> 收件人: Yonglin Tan <[email protected]>
> 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
> 主题: Re: [PATCH] net: wwan: To support SAHARA port for Qualcomm WWAN module.
>
> Hi Yonglin,
>
> On Mon, 21 Feb 2022 at 13:21, Yonglin Tan <[email protected]> wrote:
>>
>> The SAHARA port for Qualcomm WWAN module is used to capture memory
>> dump. But now this feature has not been supported by linux kernel
>> code. Such that no SAHARA driver matched while the device entered to
>> DUMP mode. Once the device crashed due to some reasons, device will
>> enter into DUMP mode and running in SBL stage. After that, the device
>> change EE to SBL and the host will detect the EE change event and
>> re-enumerate SAHARA port.
>>
>> Cc: [email protected]
>> Fixes: fa588eba632d ("net: Add Qcom WWAN control driver")
>> Signed-off-by: Yonglin Tan <[email protected]>
>> Reviewed-by: Loic Poulain <[email protected]>
>
> Sorry, but I've not yet offered that tag :-)
>
> The WWAN framework is a generic way to expose a WWAN device and its related control/data protocols, such as AT, QMI, MBIM, QCDM, etc...
> All the exposed protocols are supported by open-source user tools/daemons such as ModemManager, ofono, fwupd... SAHARA does not seem to be WWAN specific and is not something needed for controlling a modem, right?
>
> I know it would be easier to just add this channel to the WWAN ports, but we don't want to rawly expose something that could fit into an existing framework/subsystem, that's why I referred to the devcoredump framework, which 'seems' a better place for its integration. But I could be wrong, I don't know much about devcoredump and maybe SAHARA is doing much more than a firmware coredump...
>
> As a last resort, I think this kind of debug interface should go to debugfs.
Here I agree with Loic. An interface that is exported through the WWAN
subsystem should be common enough for WWAN devices. For a firmware
crash dump collection, there are better solutions like devcoredump as
already pointed out by Loic. The firmware update function can be
implemented using the devlink firmware flashing API. You could see the
use of both APIs in the IOSM driver.
If none of these interfaces can be used to utilize the SAHARA
functionality, then, as Loic has already pointed out, such an
interface should probably go to the debugfs. But I suggest to
implement the firmware management functionality using the generic
kernel API. This will save time for end users, distro maintainers and
probably for modem vendor support too.
--
Sergey