From: Loic Poulain <loic.poulain@linaro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jakub Kicinski <kuba@kernel.org>
Cc: linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Hemant Kumar <hemantk@codeaurora.org>,
open list <linux-kernel@vger.kernel.org>,
Jeffrey Hugo <jhugo@codeaurora.org>,
Bhaumik Bhatt <bbhatt@codeaurora.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH v18 0/3] userspace MHI client interface driver
Date: Wed, 16 Dec 2020 10:17:30 +0100 [thread overview]
Message-ID: <CAMZdPi8=9OsoCH_eV_JZohmFbuXcLv2kWNPLFzQUAKUCUHYs5A@mail.gmail.com> (raw)
In-Reply-To: <1607715903-16442-1-git-send-email-hemantk@codeaurora.org>
Hi Folks,
On Fri, 11 Dec 2020 at 20:45, Hemant Kumar <hemantk@codeaurora.org> wrote:
>
> This patch series adds support for UCI driver. UCI driver enables userspace
> clients to communicate to external MHI devices like modem. UCI driver probe
> creates standard character device file nodes for userspace clients to
> perform open, read, write, poll and release file operations. These file
> operations call MHI core layer APIs to perform data transfer using MHI bus
> to communicate with MHI device.
>
> This interface allows exposing modem control channel(s) such as QMI, MBIM,
> or AT commands to userspace which can be used to configure the modem using
> tools such as libqmi, ModemManager, minicom (for AT), etc over MHI. This is
> required as there are no kernel APIs to access modem control path for device
> configuration. Data path transporting the network payload (IP), however, is
> routed to the Linux network via the mhi-net driver. Currently driver supports
> QMI channel. libqmi is userspace MHI client which communicates to a QMI
> service using QMI channel. Please refer to
> https://www.freedesktop.org/wiki/Software/libqmi/ for additional information
> on libqmi.
>
> Patch is tested using arm64 and x86 based platform.
Are there any blockers or unadressed comments remaining on this
series? As far as I understand, the original blocker was the net/WiFi
mention in the commit message, that caused a legitimate concern from
network maintainer. It has been clarified now that this driver is not
for exposing any channel that could be otherwise handled properly by
an existing Linux subsystem/interface. It will be especially used as a
pipe for modem QMI channel (or AT commands) in the same way as the USB
CDC-WDM driver is doing (keeping userspace compatibility). Other MHI
channels, such as network data, QRTR, etc are not exposed and
correctly bound to the corresponding Linux subsystems.
The correlated worry was that it could be a userspace channel facility
for 'everything qualcomm', but we could say the same for other
existing busses with userspace shunt (/dev/bus/usb, /dev/i2c,
/dev/spidev, PCI UIO, UART...). Moreover, it is mitigated by the fact
that not all MHI channels are exposed by default, but only the allowed
ones (QMI in the initial version). For sure, special care must be
given to any further channel addition.
Regards,
Loic
next prev parent reply other threads:[~2020-12-16 9:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 19:45 [PATCH v18 0/3] userspace MHI client interface driver Hemant Kumar
2020-12-11 19:45 ` [PATCH v18 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file Hemant Kumar
2020-12-11 19:45 ` [PATCH v18 2/3] docs: Add documentation for userspace client interface Hemant Kumar
2020-12-11 19:45 ` [PATCH v18 3/3] bus: mhi: Add userspace client interface driver Hemant Kumar
2020-12-16 9:17 ` Loic Poulain [this message]
2020-12-16 9:42 ` [PATCH v18 0/3] userspace MHI " Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZdPi8=9OsoCH_eV_JZohmFbuXcLv2kWNPLFzQUAKUCUHYs5A@mail.gmail.com' \
--to=loic.poulain@linaro.org \
--cc=bbhatt@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=hemantk@codeaurora.org \
--cc=jhugo@codeaurora.org \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).