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: <20221107115856.GE2220@thinkpad>
Date:   Mon, 7 Nov 2022 17:28:56 +0530
From:   Manivannan Sadhasivam <mani@...nel.org>
To:     Daniele Palmas <dnlplm@...il.com>
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

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

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