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: <CAGRyCJF+EodvRNK6T7KrBP_WKyETPYmz537M6hF6ZDD0RQVvkA@mail.gmail.com>
Date:   Mon, 7 Nov 2022 17:18:00 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     Manivannan Sadhasivam <mani@...nel.org>
Cc:     mhi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
        Network Development <netdev@...r.kernel.org>,
        loic.poulain@...aro.org
Subject: Re: MHI DTR client implementation

Hi Mani,

Il giorno lun 7 nov 2022 alle ore 12:59 Manivannan Sadhasivam
<mani@...nel.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
> >
>
> --
> மணிவண்ணன் சதாசிவம்