* MHI DTR client implementation @ 2022-09-20 14:23 Daniele Palmas 2022-11-07 11:58 ` Manivannan Sadhasivam 0 siblings, 1 reply; 6+ messages in thread From: Daniele Palmas @ 2022-09-20 14:23 UTC (permalink / raw) To: mhi, linux-arm-msm, Network Development 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? If yes, does it make sense to have an associated port exposed as a char device? 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MHI DTR client implementation 2022-09-20 14:23 MHI DTR client implementation Daniele Palmas @ 2022-11-07 11:58 ` Manivannan Sadhasivam 2022-11-07 13:46 ` Loic Poulain 2022-11-07 16:18 ` Daniele Palmas 0 siblings, 2 replies; 6+ messages in thread From: Manivannan Sadhasivam @ 2022-11-07 11:58 UTC (permalink / raw) To: Daniele Palmas; +Cc: mhi, linux-arm-msm, Network Development, loic.poulain + 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 > -- மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MHI DTR client implementation 2022-11-07 11:58 ` Manivannan Sadhasivam @ 2022-11-07 13:46 ` Loic Poulain 2022-11-07 16:28 ` Daniele Palmas 2022-11-07 16:18 ` Daniele Palmas 1 sibling, 1 reply; 6+ messages in thread From: Loic Poulain @ 2022-11-07 13:46 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: Daniele Palmas, mhi, linux-arm-msm, Network Development On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@kernel.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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MHI DTR client implementation 2022-11-07 13:46 ` Loic Poulain @ 2022-11-07 16:28 ` Daniele Palmas 2022-11-07 16:36 ` Jeffrey Hugo 0 siblings, 1 reply; 6+ messages in thread From: Daniele Palmas @ 2022-11-07 16:28 UTC (permalink / raw) To: Loic Poulain Cc: Manivannan Sadhasivam, mhi, linux-arm-msm, Network Development Hi Loic, Il giorno lun 7 nov 2022 alle ore 14:47 Loic Poulain <loic.poulain@linaro.org> ha scritto: > > On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@kernel.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...) Thanks, Daniele > Regards, > Loic ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MHI DTR client implementation 2022-11-07 16:28 ` Daniele Palmas @ 2022-11-07 16:36 ` Jeffrey Hugo 0 siblings, 0 replies; 6+ messages in thread From: Jeffrey Hugo @ 2022-11-07 16:36 UTC (permalink / raw) To: Daniele Palmas, Loic Poulain Cc: Manivannan Sadhasivam, mhi, linux-arm-msm, Network Development 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@linaro.org> ha scritto: >> >> On Mon, 7 Nov 2022 at 12:59, Manivannan Sadhasivam <mani@kernel.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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: MHI DTR client implementation 2022-11-07 11:58 ` Manivannan Sadhasivam 2022-11-07 13:46 ` Loic Poulain @ 2022-11-07 16:18 ` Daniele Palmas 1 sibling, 0 replies; 6+ messages in thread From: Daniele Palmas @ 2022-11-07 16:18 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: mhi, linux-arm-msm, Network Development, loic.poulain Hi Mani, Il giorno lun 7 nov 2022 alle ore 12:59 Manivannan Sadhasivam <mani@kernel.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 > > > > -- > மணிவண்ணன் சதாசிவம் ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-07 16:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-20 14:23 MHI DTR client implementation Daniele Palmas 2022-11-07 11:58 ` Manivannan Sadhasivam 2022-11-07 13:46 ` Loic Poulain 2022-11-07 16:28 ` Daniele Palmas 2022-11-07 16:36 ` Jeffrey Hugo 2022-11-07 16:18 ` Daniele Palmas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).