Netdev Archive on
help / color / mirror / Atom feed
From: Aleksander Morgado <>
To: "Sergey Ryazanov" <>, "Bjørn Mork" <>
Cc: Stephan Gerhold <>,
	Loic Poulain <>,
	"David S. Miller" <>,
	Jakub Kicinski <>,
	Johannes Berg <>,
	Bjorn Andersson <>,
	Andy Gross <>, Vinod Koul <>,
	Rob Herring <>,
	Network Development <>,
	linux-arm-msm <>,,
	devicetree <>,
	open list <>,,
	Jeffrey Hugo <>
Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver
Date: Mon, 26 Jul 2021 10:10:57 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


> But what if we implement the QMI multiplexing management part in the
> kernel? This way the kernel will take care about modem-to-host
> communication protocols and interfaces, and provides userspace with a
> single WWAN device (possibly with multiple network and network
> management interfaces).
> I do not propose to fully implement QMI protocol inside the kernel,
> but implement only a mux management part, while passing all other
> messages between a "modem" and a userspace software as-is.
> What pros and cons of such a design do you see?

The original GobiNet driver already provided some QMI protocol
implementation in the driver itself. In addition to initial device
setup as you suggest, it also allowed userspace applications to
allocate and release QMI clients for the different services that could
be used independently by different processes. Not going to say that
was the wrong way to do it, but the implementation is definitely not
simple. The decision taken in qmi_wwan to make the driver as simple as
possible and leave all the QMI management to userspace was quite an
important one; it made the driver extremely simple, leaving all the
complexity of managing the protocol to userspace, and while it had
some initial drawbacks (e.g. only one process could talk QMI at a
time) the userspace tools have evolved to avoid them (e.g. the

I wrote some time ago about this, maybe it's still relevant today:
Article in PDF

Making the driver talk QMI just for device setup would require the
kernel to know how the QMI protocol works, how QMI client allocations
and releases are done, how errors are reported, how is the format of
the requests and responses involved; it would require the kernel to
wait until the QMI protocol endpoint in the modem is capable of
returning QMI responses (this could be up to 20 or 30 secs after the
device is available in the bus), it would require to have possibly
some specific rules on how the QMI clients are managed after a
suspend/resume operation. It would also require to sync the access to
the CTL service, which is the one running QMI service allocations and
releases, so that both kernel and userspace can perform operations
with that service at the same time. It would need to know how
different QMI capable devices behave, because not all devices support
the same services, and some don't even support the WDA service that
would be the one needed to setup data aggregation. There is definitely
some overlap on what the kernel could do and what userspace could do,
and I'd say that we have much more flexibility in userspace to do all
this leaving all the complexity out of the kernel driver.

ModemManager already provides a unified API to e.g. setup multiplexed
data sessions, regardless of what the underlying kernel implementation
is (qmi_wwan only, qmi_wwan+rmnet, ipa+rmnet, bam-dmux, cdc_mbim...) .
The logic doing all that is extremely complex and possibly full of
errors, I would definitely not want to have all that logic in the
kernel itself, let the errors be in userspace! Unifying stuff in the
kernel is a good idea, but if you ask me, it should be done in a way
that is as simple as possible, leaving complexity to userspace, even
if that means that userspace still needs to know what type of device
we have behind the wwan subsystem, because userspace will anyway need
to know all that.


  reply	other threads:[~2021-07-26  8:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 14:53 [RFC PATCH net-next 0/4] " Stephan Gerhold
2021-07-19 14:53 ` [RFC PATCH net-next 1/4] dt-bindings: dmaengine: bam_dma: Add remote power collapse mode Stephan Gerhold
2021-07-29 19:36   ` Rob Herring
2021-07-29 19:50     ` Stephan Gerhold
2021-07-19 14:53 ` [RFC PATCH net-next 2/4] dmaengine: qcom: " Stephan Gerhold
2021-07-19 14:53 ` [RFC PATCH net-next 3/4] dt-bindings: net: Add schema for Qualcomm BAM-DMUX Stephan Gerhold
2021-07-19 14:53 ` [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Stephan Gerhold
2021-07-19 16:01   ` Loic Poulain
2021-07-22 15:40     ` Stephan Gerhold
2021-07-24 11:25       ` Sergey Ryazanov
2021-07-26  8:10         ` Aleksander Morgado [this message]
2021-07-26 22:40           ` Sergey Ryazanov
2021-07-20  9:10   ` Sergey Ryazanov
2021-07-21 12:17     ` Stephan Gerhold
2021-07-24 10:22       ` Sergey Ryazanov
2021-07-19 15:43 ` [RFC PATCH net-next 0/4] " Jeffrey Hugo
2021-07-19 18:23   ` Stephan Gerhold
2021-07-19 23:13     ` Jeffrey Hugo
2021-07-22 14:51       ` Stephan Gerhold
2021-07-26 14:58         ` Jeffrey Hugo

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --cc=~postmarketos/ \
    --subject='Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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