On 11/7/2022 9:28 AM, Daniele Palmas wrote:
Hi Loic,
Il giorno lun 7 nov 2022 alle ore 14:47 Loic Poulain
<loic.poulain@xxxxxxxxxx> ha scritto:
On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:
+ Loic
On Tue, Sep 20, 2022 at 04:23:25PM +0200, Daniele Palmas wrote:
Hello all,
I'm looking for some guidance related to a possible MHI client for
serial ports signals management implementation.
Testing the AT channels with Telit modems I noted that unsolicited
indications do not show: the root cause for this is DTR not set for
those ports through MHI channels 18/19, something that with current
upstream code can't be done due to the missing DTR client driver.
I currently have an hack, based on the very first mhi stack submission
(see https://lore.kernel.org/lkml/1524795811-21399-2-git-send-email-sdias@xxxxxxxxxxxxxx/#Z31drivers:bus:mhi:core:mhi_dtr.c),
solving my issue, but I would like to understand which would be the
correct way, so maybe I can contribute some code.
Should the MHI DTR client be part of the WWAN subsystem?
Yes, since WWAN is going to be the consumer of this channel, it makes sense to
host the client driver there.
Agree.
If yes, does it make sense to have an associated port exposed as a char
device?
If the goal is to control the DTR settings from userspace, then you can use
the "AT" chardev node and handle the DTR settings in this client driver.
Because at the end of the day, user is going to read/write from AT port only.
Adding one more ctrl port and have it configured before using AT port is going
to be a pain.
Thanks,
Mani
I guess the answer is no, since it should be used just by the AT ports
created by mhi_wwan_ctrl, but I'm not sure if that's possible.
Or should the DTR management be somehow part of the MHI stack and
mhi_wwan_ctrl interacts with that through exported functions?
Is this DTR thing Telit specific?
I'm still not 100% sure, but I believe it is Telit specific.
Noticed you're using the IP_CTRL channel for this, do you have more
information about the protocol to use?
No, Qualcomm documents I have about mhi does not telly anything about
this protocol: all I know is coming from previously sent patches and
code available at
https://git.codelinaro.org/clo/le/platform/mhi-host/-/commit/17a10f4c879c9f504a0d279f03e924553bcf2420
At first glance, I would say you can create a simple driver for
IP_CTRL channel (that could be part of mhi_wwan_ctrl), but instead of
exposing it rawly to the user, simply enable DTR unconditionally at
probe time?
Yes, this is what I'm currently doing in custom patches and it's
working fine since I just need to "turn on" indications. Not sure,
however, if this works fine for other use cases (e.g. dial-up, as
mentioned in commit description at
https://git.codelinaro.org/clo/le/platform/mhi-host/-/commit/17a10f4c879c9f504a0d279f03e924553bcf2420
though I'm not sure how much having a dial-up connection with this
kind of modems makes sense...)
Its my understanding DUN is still used for carrier
validation/certification and also to support a number of legacy
services. A niche thing, but still in use.
