Date:   Mon, 7 Nov 2022 17:28:08 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     Manivannan Sadhasivam <mani@...nel.org>, mhi@...ts.linux.dev,
        linux-arm-msm@...r.kernel.org,
        Network Development <netdev@...r.kernel.org>
Subject: Re: MHI DTR client implementation

Hi Loic,

Il giorno lun 7 nov 2022 alle ore 14:47 Loic Poulain
<loic.poulain@...aro.org> ha scritto:
>
> On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@...nel.org> 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@codeaurora.org/#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...)

Thanks,
Daniele

> Regards,
> Loic

Powered by blists - more mailing lists