From: Alex Elder <elder@linaro.org>
To: Johannes Berg <johannes@sipsolutions.net>,
Dan Williams <dcbw@redhat.com>, Arnd Bergmann <arnd@arndb.de>
Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
abhishek.esse@gmail.com, Ben Chan <benchan@google.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
cpratapa@codeaurora.org, David Miller <davem@davemloft.net>,
DTML <devicetree@vger.kernel.org>,
Eric Caruso <ejcaruso@google.com>,
evgreen@chromium.org,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-soc@vger.kernel.org, Networking <netdev@vger.kernel.org>,
syadagir@codeaurora.org
Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
Date: Wed, 26 Jun 2019 08:36:53 -0500 [thread overview]
Message-ID: <0f5c0332-6894-2fdd-fd25-7af9a21b445b@linaro.org> (raw)
In-Reply-To: <868e949b1fc8cf22307f579ab1f14543064bec20.camel@sipsolutions.net>
On 6/25/19 9:14 AM, Johannes Berg wrote:
> Hi Alex,
>
> I'll just pick a few or your messages and reply there - some other
> subthreads seem to have pretty much completed.
>
. . .
>>> Linux usually tries to keep drivers generic and focused; each driver is
>>> written for a specific function. For example, a USB device usually
>>> provides multiple USB interfaces which will be bound to different Linux
>>> drivers like a TTY, cdc-ether, QMI (via qmi_wwan), cdc-acm, etc.
>>
>> So USB has some attributes similar to what we're talking about
>> here. But if I'm not mistaken we want some sort of an overall
>> management scheme as well.
>
> Yes. For the record, I think the part about "keep drivers generic and
> focused" really only works for USB devices that expose different pieces
> that look like any other network device or a TTY device on the USB
> level, just the combination of these things (and knowing about that)
> really makes them a modem.
>
> For things like IPA or the (hypothetical) Intel driver we're talking
> about, it's still all managed by a single (PCIe) driver. For the Intel
> device in particular, even all the control channels are over exactly the
> same transport mechanism as the data channels.
Actually the setup for IPA requires certain things to be done via
QMI by something outside the IPA driver, and it uses a separate
communication path. But I understand what you're saying.
. . .
>> I don't like the "maybe" API unless there's no other way to do it.
>>
>> Instead I think it would be better for the probing driver to register
>> with a whatever the WWAN core is, and then have the WWAN core be
>> responsible for pulling things all together when it receives a
>> request to do so. I.e., something in user space should request
>> that a registered data interface be brought up, and at that
>> time everything "knows" it's implemented as part of a WWAN
>> device.
>
> Right, but then we just punt to userspace. Mostly we *do* (eventually!)
> know that it's a WWAN device, just not every component can detect it.
> Some components typically can.
We need to identify the existence of a WWAN device (which is I
guess--typically? always?--a modem). Perhaps that can be
discovered in some cases but I think it means a node described
by Device Tree.
> So for example, you might have a USB multi-function device with a
> network function (looks just like ethernet pretty much) but another TTY
> control channel that actually has some specific WWAN IDs, so that part
> can know it's a WWAN.
>
> Here, the ethernet function would need "maybe" attach, and the control
> channel would "definitively" attach, pulling it together as a WWAN
> device without requiring any more action or information.
So you're saying you have a single Ethernet driver, and it can
drive an Ethernet device connected to a WWAN, or not connected
to a WWAN, without any changes. The only distinction is that
if the device is part of a WWAN it needs to register with the
WWAN framework. Is that right?
>> So maybe:
>> - Hardware probe detects a WWAN device
>> - The drivers that detect the WWAN device register it with the
>> WWAN core code.
>> - A control channel is instantiated at/before the time the WWAN
>> device is registered
>> - Something in user space should manage the bring-up of any
>> other things on the WWAN device thereafter
>
> But those things need to actually get connected first :-)
What I meant is that the registering with the "WWAN core code"
is what does that "connecting." The WWAN code has the information
about what got registered. But as I said above, this WWAN device
needs to be identified, and I think (at least for IPA) that will
require something in Device Tree. That will "connect" them.
Or I might be misunderstanding your point.
> In IPA/Intel case this is easy since it's a single driver. But if
> there's multi-function device with ethernet being a completely separate
> driver, the control channel cannot even reach that to tell it to create
> a new data channel.
There's a lot more to talk about with control. I think
you discuss this in another message, and I'll get to that
shortly. But I think understand your point, and again
I think it comes back to having an abstraction that
represents the modem, distinct from (but "connected" to)
the functions it implements/includes.
>>> userspace should probably always create the netdevices (since they are
>>> always useless until userspace coordinates with the firmware about
>>> them) but that's not how things are yet.
>>
>> That's too bad. How hard would that be to change?
>
> Depends, but as I said above it's probably orthogonal to the question.
> The data channel driver would still need to attach to the WWAN device
> somehow so it becomes reachable by the control plane (note this isn't
> the same as "control channel" since the latter talks to the modem, the
> control plane talks to the kernel drivers).
>
>>>> - What causes a created channel to be removed?
>>>
>>> Driver removal, userspace WWAN daemon terminating the packet data
>>> connection which the channel represents, the modem terminating the
>>> packet data connection (eg network initiated disconnect), etc.
>>
>> OK this is as I expected. Driver (or device) removal is somewhat
>> obvious, but you're confirming user space might request it as well.
>
> If userspace actually had the ability to create (data) channels, then it
> would have the ability to also remove them. Right now, this may or may
> not be supported by the drivers that act together to form the interfaces
> to a WWAN device.
I think this (user space control) needs to be an option, but
it doesn't have to be the only way.
. . .
You made some other good clarifications in this message but I'm
going to try to capture them elsewhere rather than respond here.
-Alex
next prev parent reply other threads:[~2019-06-26 13:37 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 3:53 [PATCH v2 00/17] net: introduce Qualcomm IPA driver Alex Elder
2019-05-31 3:53 ` [PATCH v2 01/17] bitfield.h: add FIELD_MAX() and field_max() Alex Elder
2019-05-31 3:53 ` [PATCH v2 02/17] dt-bindings: soc: qcom: add IPA bindings Alex Elder
2019-06-10 22:08 ` Rob Herring
2019-06-11 2:11 ` Alex Elder
2019-07-03 15:09 ` Alex Elder
2019-05-31 3:53 ` [PATCH v2 03/17] soc: qcom: ipa: main code Alex Elder
2019-05-31 21:50 ` David Miller
2019-05-31 22:25 ` Alex Elder
2019-05-31 3:53 ` [PATCH v2 04/17] soc: qcom: ipa: configuration data Alex Elder
2019-05-31 3:53 ` [PATCH v2 05/17] soc: qcom: ipa: clocking, interrupts, and memory Alex Elder
2019-05-31 3:53 ` [PATCH v2 06/17] soc: qcom: ipa: GSI headers Alex Elder
2019-05-31 3:53 ` [PATCH v2 07/17] soc: qcom: ipa: the generic software interface Alex Elder
2019-05-31 3:53 ` [PATCH v2 08/17] soc: qcom: ipa: GSI transactions Alex Elder
2019-05-31 3:53 ` [PATCH v2 09/17] soc: qcom: ipa: IPA interface to GSI Alex Elder
2019-05-31 3:53 ` [PATCH v2 10/17] soc: qcom: ipa: IPA endpoints Alex Elder
2019-05-31 3:53 ` [PATCH v2 11/17] soc: qcom: ipa: immediate commands Alex Elder
2019-05-31 3:53 ` [PATCH v2 12/17] soc: qcom: ipa: IPA network device and microcontroller Alex Elder
2019-05-31 3:53 ` [PATCH v2 13/17] soc: qcom: ipa: AP/modem communications Alex Elder
2019-05-31 3:53 ` [PATCH v2 14/17] soc: qcom: ipa: support build of IPA code Alex Elder
2019-05-31 3:53 ` [PATCH v2 15/17] MAINTAINERS: add entry for the Qualcomm IPA driver Alex Elder
2019-05-31 3:53 ` [PATCH v2 16/17] arm64: dts: sdm845: add IPA information Alex Elder
2019-05-31 3:53 ` [PATCH v2 17/17] arm64: defconfig: enable build of IPA code Alex Elder
2019-05-31 14:58 ` [PATCH v2 00/17] net: introduce Qualcomm IPA driver Dan Williams
2019-05-31 16:36 ` Alex Elder
2019-05-31 19:19 ` Arnd Bergmann
2019-05-31 20:47 ` Alex Elder
2019-05-31 21:12 ` Arnd Bergmann
2019-05-31 22:08 ` Alex Elder
2019-06-07 17:43 ` Alex Elder
2019-05-31 23:33 ` Bjorn Andersson
2019-05-31 23:59 ` Subash Abhinov Kasiviswanathan
2019-06-03 10:04 ` Arnd Bergmann
2019-06-03 13:32 ` Alex Elder
2019-06-04 8:13 ` Arnd Bergmann
2019-06-04 15:18 ` Dan Williams
2019-06-04 20:04 ` Arnd Bergmann
2019-06-04 21:29 ` Dan Williams
2019-06-06 17:42 ` Alex Elder
2019-06-11 8:12 ` Johannes Berg
2019-06-11 11:56 ` Arnd Bergmann
2019-06-11 15:53 ` Dan Williams
2019-06-11 16:52 ` Subash Abhinov Kasiviswanathan
2019-06-11 17:22 ` Dan Williams
2019-06-12 8:31 ` Arnd Bergmann
2019-06-12 14:27 ` Dan Williams
2019-06-12 15:06 ` Arnd Bergmann
2019-06-17 11:42 ` Johannes Berg
2019-06-17 12:25 ` Johannes Berg
2019-06-18 15:20 ` Alex Elder
2019-06-18 18:06 ` Dan Williams
2019-06-24 16:21 ` Alex Elder
2019-06-25 14:14 ` Johannes Berg
2019-06-26 13:36 ` Alex Elder [this message]
2019-06-26 17:55 ` Johannes Berg
2019-06-18 18:48 ` Johannes Berg
2019-06-24 16:21 ` Alex Elder
2019-06-18 13:45 ` Alex Elder
2019-06-18 19:03 ` Johannes Berg
2019-06-18 20:09 ` Arnd Bergmann
2019-06-18 20:15 ` Johannes Berg
2019-06-18 20:33 ` Arnd Bergmann
2019-06-18 20:39 ` Johannes Berg
2019-06-18 21:06 ` Arnd Bergmann
2019-06-19 20:56 ` Dan Williams
2019-06-24 16:21 ` Alex Elder
2019-06-24 16:40 ` Arnd Bergmann
2019-06-25 14:19 ` Johannes Berg
2019-06-26 13:39 ` Alex Elder
2019-06-26 13:58 ` Arnd Bergmann
2019-06-26 17:48 ` Johannes Berg
2019-06-26 17:45 ` Johannes Berg
2019-06-26 13:51 ` Alex Elder
2019-06-17 11:28 ` Johannes Berg
2019-06-18 13:16 ` Alex Elder
2019-06-18 13:48 ` Arnd Bergmann
2019-06-18 19:14 ` Johannes Berg
2019-06-18 19:59 ` Arnd Bergmann
2019-06-18 20:36 ` Johannes Berg
2019-06-18 20:55 ` Arnd Bergmann
2019-06-18 21:02 ` Johannes Berg
2019-06-18 21:15 ` Subash Abhinov Kasiviswanathan
2019-06-19 12:23 ` Arnd Bergmann
2019-06-19 18:47 ` Subash Abhinov Kasiviswanathan
2019-06-20 1:25 ` Dan Williams
2019-06-24 16:21 ` Alex Elder
2019-06-17 12:14 ` Johannes Berg
2019-06-18 14:00 ` Alex Elder
2019-06-18 19:22 ` Johannes Berg
2019-06-24 16:21 ` Alex Elder
2019-06-03 14:50 ` Dan Williams
2019-06-03 14:54 ` Dan Williams
2019-06-03 15:52 ` Alex Elder
2019-06-03 16:18 ` Dan Williams
2019-06-03 19:04 ` Subash Abhinov Kasiviswanathan
2019-06-04 15:21 ` Dan Williams
2019-05-31 23:27 ` Bjorn Andersson
2019-06-10 2:44 ` Alex Elder
2019-06-24 16:30 ` WWAN Controller Framework (was IPA [PATCH v2 00/17]) Alex Elder
2019-06-24 17:06 ` Alex Elder
2019-06-25 14:34 ` Johannes Berg
2019-06-26 13:40 ` Alex Elder
2019-06-26 17:58 ` Johannes Berg
2019-06-24 19:54 ` Dan Williams
2019-06-24 21:16 ` Alex Elder
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=0f5c0332-6894-2fdd-fd25-7af9a21b445b@linaro.org \
--to=elder@linaro.org \
--cc=abhishek.esse@gmail.com \
--cc=arnd@arndb.de \
--cc=benchan@google.com \
--cc=bjorn.andersson@linaro.org \
--cc=cpratapa@codeaurora.org \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=ejcaruso@google.com \
--cc=evgreen@chromium.org \
--cc=ilias.apalodimas@linaro.org \
--cc=johannes@sipsolutions.net \
--cc=linux-arm-kernel@lists.infradead.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 \
--cc=subashab@codeaurora.org \
--cc=syadagir@codeaurora.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).