From: Marcel Holtmann <marcel@holtmann.org>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
"David S. Miller" <davem@davemloft.net>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
Netdev list <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] In-kernel QMI handling
Date: Tue, 8 Aug 2017 13:13:22 +0200 [thread overview]
Message-ID: <43B553C5-4473-482D-9648-6031088AAAD5@holtmann.org> (raw)
In-Reply-To: <8737921fw2.fsf@miraculix.mork.no>
Hi Bjorn,
>> This series starts by moving the common definitions of the QMUX protocol to the
>> uapi header, as they are shared with clients - both in kernel and userspace.
>>
>> This series then introduces in-kernel helper functions for aiding the handling
>> of QMI encoded messages in the kernel. QMI encoding is a wire-format used in
>> exchanging messages between the majority of QRTR clients and services.
>
> Interesting! I tried to add some QMI handling in the kernel a few years
> ago, but was thankfully voted down. See
> https://www.spinics.net/lists/netdev/msg183101.html and the following
> discussion. I am convinced that was the right decision, for the client
> side at least. The protocol is just too extensive and ever-growing to be
> implemented in the kernel. We would be catching up forever.
I think that even back then I said, that it has to be done as a proper subsystem if it has a chance to be in the kernel. So something similar to Phonet and CAIF where the service registration is handled by the kernel, but applications can be fully in userspace. None of this is actually brand new Qualcomm design since Nokia has had its Phonet long before QMI existed.
The real importance is that Qualcomm is behind this and wants to get this done a clean way with a proper API. The /dev/qmi thing was a pretty broken interface. Any subsystem has to support multiple QMI devices. Even if this is unlikely in a phone design, it has to be supported so that attaching two USB QMI based dongles does not end up with some pointless errors.
Regards
Marcel
next prev parent reply other threads:[~2017-08-08 11:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-04 14:59 [PATCH 0/6] In-kernel QMI handling Bjorn Andersson
2017-08-04 14:59 ` [PATCH 1/6] net: qrtr: Invoke sk_error_report() after setting sk_err Bjorn Andersson
2017-08-04 14:59 ` [PATCH 2/6] net: qrtr: Move constants to header file Bjorn Andersson
2017-08-04 14:59 ` [PATCH 3/6] net: qrtr: Add control packet definition to uapi Bjorn Andersson
2017-08-04 14:59 ` [PATCH 4/6] soc: qcom: Introduce QMI encoder/decoder Bjorn Andersson
2017-08-04 14:59 ` [PATCH 5/6] soc: qcom: Introduce QMI helpers Bjorn Andersson
2017-08-04 14:59 ` [PATCH 6/6] samples: Introduce Qualcomm QRTR sample client Bjorn Andersson
2017-08-04 15:36 ` [PATCH 0/6] In-kernel QMI handling Dan Williams
2017-08-07 17:38 ` Bjorn Andersson
2017-08-07 19:19 ` Marcel Holtmann
2017-08-08 4:45 ` Bjorn Andersson
2017-08-08 6:15 ` Marcel Holtmann
2017-08-08 11:02 ` Bjørn Mork
2017-08-08 11:13 ` Marcel Holtmann [this message]
2017-08-08 22:42 ` Bjorn Andersson
2017-08-09 0:48 ` Dan Williams
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=43B553C5-4473-482D-9648-6031088AAAD5@holtmann.org \
--to=marcel@holtmann.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=david.brown@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.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).