netdev - Re: MHI DTR client implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZdPi-=AkfKnyPRBgV-7RxczePnB4shLq2bdj+q3kh+7Web3w@mail.gmail.com>
Date:   Mon, 7 Nov 2022 14:46:29 +0100
From:   Loic Poulain <loic.poulain@...aro.org>
To:     Manivannan Sadhasivam <mani@...nel.org>
Cc:     Daniele Palmas <dnlplm@...il.com>, mhi@...ts.linux.dev,
        linux-arm-msm@...r.kernel.org,
        Network Development <netdev@...r.kernel.org>
Subject: Re: MHI DTR client implementation

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?

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