Hello Yonglin,
On Mon, Feb 21, 2022 at 7:21 PM 谭 永林 yonglin.tan@outlook.com 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 loic.poulain@linaro.org 发送时间: 2022年2月22日 0:03 收件人: Yonglin Tan yonglin.tan@outlook.com 抄送: ryazanov.s.a@gmail.com; johannes@sipsolutions.net; davem@davemloft.net; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; stable@vger.kernel.org 主题: Re: [PATCH] net: wwan: To support SAHARA port for Qualcomm WWAN module.
Hi Yonglin,
On Mon, 21 Feb 2022 at 13:21, Yonglin Tan yonglin.tan@outlook.com 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: stable@vger.kernel.org Fixes: fa588eba632d ("net: Add Qcom WWAN control driver") Signed-off-by: Yonglin Tan yonglin.tan@outlook.com Reviewed-by: Loic Poulain loic.poulain@linaro.org
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.