MHI DTR client implementation

MHI DTR client implementation

[Daniele Palmas]

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? If yes, does
it make sense to have an associated port exposed as a char device? 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?

Thanks a lot in advance,
Daniele

Re: MHI DTR client implementation

[Manivannan Sadhasivam]

+ 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.

> 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?
> 
> Thanks a lot in advance,
> Daniele
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: MHI DTR client implementation

[Loic Poulain]

On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@kernel.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?

Noticed you're using the IP_CTRL channel for this, do you have more
information about the protocol to use?

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?

Regards,
Loic

Re: MHI DTR client implementation

[Daniele Palmas]

Hi Mani,

Il giorno lun 7 nov 2022 alle ore 12:59 Manivannan Sadhasivam
<mani@kernel.org> ha scritto:
>
> + 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.
>
> > 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.
>

ok.

Meanwhile, I've found the following
https://git.codelinaro.org/clo/le/platform/mhi-host/-/commit/17a10f4c879c9f504a0d279f03e924553bcf2420
and https://git.codelinaro.org/clo/le/platform/mhi-host/-/commit/8a87038021d4f39e435e035124acade1eb168749
that is very similar to the approach I was thinking about.

I guess this could be probably the best starting point for mainline integration.

Thanks,
Daniele

> 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?
> >
> > Thanks a lot in advance,
> > Daniele
> >
>
> --
> மணிவண்ணன் சதாசிவம்

Re: MHI DTR client implementation

[Daniele Palmas]

Hi Loic,

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

Re: MHI DTR client implementation

[Jeffrey Hugo]

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@linaro.org> ha scritto:
>>
>> On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@kernel.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...)

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.