Message-ID: <5e8b3ff3-edee-f4d0-925c-545d0a801e1f@quicinc.com>
Date:   Mon, 7 Nov 2022 09:36:40 -0700
From:   Jeffrey Hugo <quic_jhugo@...cinc.com>
To:     Daniele Palmas <dnlplm@...il.com>,
        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

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@...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...)

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.

Powered by blists - more mailing lists