Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <yonglin.tan@outlook.com> <MEYP282MB237454C97E14056454FBBC77FD3A9@MEYP282MB2374.AUSP282.PROD.OUTLOOK.COM>
 <CAMZdPi_7KGx69s5tFumkswVXiQSdxXZjDXT5f9njRnBNz1k-VA@mail.gmail.com> <MEYP282MB2374BDAB34B7AE65C1246A44FD3A9@MEYP282MB2374.AUSP282.PROD.OUTLOOK.COM>
In-Reply-To: <MEYP282MB2374BDAB34B7AE65C1246A44FD3A9@MEYP282MB2374.AUSP282.PROD.OUTLOOK.COM>
From:   Sergey Ryazanov <ryazanov.s.a@gmail.com>
Date:   Mon, 21 Feb 2022 21:12:55 +0300
Message-ID: <CAHNKnsQtENMg2pv+AD1BYm=MA63O3j=1agUXGdgogpZh5c6JCw@mail.gmail.com>
Subject: Re: [PATCH] net: wwan: To support SAHARA port for Qualcomm WWAN module.
To:     =?UTF-8?B?6LCtIOawuOaelw==?= <yonglin.tan@outlook.com>
Cc:     Loic Poulain <loic.poulain@linaro.org>,
        "johannes@sipsolutions.net" <johannes@sipsolutions.net>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello Yonglin,

On Mon, Feb 21, 2022 at 7:21 PM =E8=B0=AD =E6=B0=B8=E6=9E=97 <yonglin.tan@o=
utlook.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 b=
e transferred over any physical link.
>
> To conclude, the SAHARA port provide a mechanism to transfer messages bet=
ween host and device during SBL.
>
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Loic Poulain <loic.poulain@linaro.org>
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B42=E6=9C=8822=E6=97=A5 =
0:03
> =E6=94=B6=E4=BB=B6=E4=BA=BA: Yonglin Tan <yonglin.tan@outlook.com>
> =E6=8A=84=E9=80=81: ryazanov.s.a@gmail.com; johannes@sipsolutions.net; da=
vem@davemloft.net; kuba@kernel.org; netdev@vger.kernel.org; linux-kernel@vg=
er.kernel.org; stable@vger.kernel.org
> =E4=B8=BB=E9=A2=98: Re: [PATCH] net: wwan: To support SAHARA port for Qua=
lcomm 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 relat=
ed 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 spec=
ific 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 fr=
amework/subsystem, that's why I referred to the devcoredump framework, whic=
h '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 fir=
mware coredump...
>
> As a last resort, I think this kind of debug interface should go to debug=
fs.

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.

--=20
Sergey