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