On Thu, Mar 5, 2020 at 8:28 PM Alex Elder wrote:
>
> This series presents the driver for the Qualcomm IP Accelerator (IPA).
>
> This is version 2 of this updated series. It includes the following
> small changes since the previous version:
> - Now based on net-next instead of v5.6-rc
> - Conf
On Wed, 2019-06-26 at 08:36 -0500, Alex Elder wrote:
>
> 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.
Yeah, perhaps that's something you
On Wed, 2019-06-26 at 15:58 +0200, Arnd Bergmann wrote:
>
> > The IPA hardware is actually something that sits *between* the
> > AP and the modem. It implements one form of communication
> > pathway (IP data), but there are others (including QMI, which
> > presents a network-like interface but it
On Wed, 2019-06-26 at 08:39 -0500, Alex Elder wrote:
> > However, to also reply to Alex: I don't know exactly how IPA works, but
> > for the Intel modem at least you can't fundamentally have two drivers
> > for different parts of the functionality, since it's just a single piece
> > of hardware an
On Wed, Jun 26, 2019 at 3:39 PM Alex Elder wrote:
> On 6/25/19 9:19 AM, Johannes Berg wrote:
> > On Mon, 2019-06-24 at 18:40 +0200, Arnd Bergmann wrote:
>
> > So, IOW, I'm not sure I see how you'd split that up. I guess you could
> > if you actually do something like the "rmnet" model, and I suppo
On 6/24/19 11:40 AM, Arnd Bergmann wrote:
> On Mon, Jun 24, 2019 at 6:21 PM Alex Elder wrote:
>> On 6/18/19 2:03 PM, Johannes Berg wrote:
>>
>>> Really there are two possible ways (and they intersect to some extent).
. . .
>>> The other is something like IPA or the Intel modem driver, where the
On 6/25/19 9:19 AM, Johannes Berg wrote:
> On Mon, 2019-06-24 at 18:40 +0200, Arnd Bergmann wrote:
>> On Mon, Jun 24, 2019 at 6:21 PM Alex Elder wrote:
>>> On 6/18/19 2:03 PM, Johannes Berg wrote:
>>>
Really there are two possible ways (and they intersect to some extent).
One is the
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. Fo
On Mon, 2019-06-24 at 18:40 +0200, Arnd Bergmann wrote:
> On Mon, Jun 24, 2019 at 6:21 PM Alex Elder wrote:
> > On 6/18/19 2:03 PM, Johannes Berg wrote:
> >
> > > Really there are two possible ways (and they intersect to some extent).
> > >
> > > One is the whole multi-function device, where a s
Hi Alex,
I'll just pick a few or your messages and reply there - some other
subthreads seem to have pretty much completed.
> Sorry for the delay. There's a lot here to go through, and with
> each message the picture is (slowly) getting a bit clearer for me.
> Still, there are some broad tradeoff
On Mon, Jun 24, 2019 at 6:21 PM Alex Elder wrote:
> On 6/18/19 2:03 PM, Johannes Berg wrote:
>
> > Really there are two possible ways (and they intersect to some extent).
> >
> > One is the whole multi-function device, where a single WWAN device is
> > composed of channels offered by actually diff
On 6/18/19 2:14 PM, Johannes Berg wrote:
> On Tue, 2019-06-18 at 08:16 -0500, Alex Elder wrote:
>> On 6/17/19 6:28 AM, Johannes Berg wrote:
>>> On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
wrote:
>> As I've made clear bef
On 6/18/19 2:22 PM, Johannes Berg wrote:
> On Tue, 2019-06-18 at 09:00 -0500, Alex Elder wrote:
. . .
> Anyway, I think for now we could probably live with not having this
> configurable for the IPA driver, and if it *does* need to be
> configurable, it seems like it should be a driver configurat
On 6/18/19 1:06 PM, Dan Williams wrote:
> On Tue, 2019-06-18 at 10:20 -0500, Alex Elder wrote:
>> On 6/17/19 7:25 AM, Johannes Berg wrote:
>>> On Mon, 2019-06-17 at 13:42 +0200, Johannes Berg wrote:
>>>
But anyway, as I alluded to above, I had something like this in
mind:
Sorry for the d
On 6/18/19 2:03 PM, Johannes Berg wrote:
> On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote:
>
>> If it had a well-defined way of creating new channels to be
>> multiplexed over the connection to the modem, the IPA driver
>> (rather than the rmnet driver) could present network interfaces
>> for
On 6/18/19 1:48 PM, Johannes Berg wrote:
> Just to add to Dan's response, I think he's captured our discussions and
> thoughts well.
>
>> First, a few terms (correct or improve as you like):
>
> Thanks for defining, we don't do that nearly often enough.
>
>> - WWAN device is a hardware device (l
On Wed, 2019-06-19 at 12:47 -0600, Subash Abhinov Kasiviswanathan
wrote:
> > > There is a n:1 relationship between rmnet and IPA.
> > > rmnet does the de-muxing to multiple netdevs based on the mux id
> > > in the MAP header for RX packets and vice versa.
> >
> > Oh, so you mean that even though I
On Tue, 2019-06-18 at 23:06 +0200, Arnd Bergmann wrote:
> On Tue, Jun 18, 2019 at 10:39 PM Johannes Berg
> wrote:
> > On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote:
> > It seems to me though that this is far more complex than what I'm
> > proposing? What I'm proposing there doesn't even n
There is a n:1 relationship between rmnet and IPA.
rmnet does the de-muxing to multiple netdevs based on the mux id
in the MAP header for RX packets and vice versa.
Oh, so you mean that even though IPA supports multiple channels
and multiple netdev instances for a physical device, all the
rmnet
On Tue, Jun 18, 2019 at 11:15 PM Subash Abhinov Kasiviswanathan
wrote:
>
> On 2019-06-18 14:55, Arnd Bergmann wrote:
> > On Tue, Jun 18, 2019 at 10:36 PM Johannes Berg
> > wrote:
> >>
> >> On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
> >> >
> >> > From my understanding, the ioctl inter
On 2019-06-18 14:55, Arnd Bergmann wrote:
On Tue, Jun 18, 2019 at 10:36 PM Johannes Berg
wrote:
On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
>
> From my understanding, the ioctl interface would create the lower
> netdev after talking to the firmware, and then user space would use
>
On Tue, Jun 18, 2019 at 10:39 PM Johannes Berg
wrote:
> On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote:
> It seems to me though that this is far more complex than what I'm
> proposing? What I'm proposing there doesn't even need any userspace
> involvement, as long as all the pieces are in
On Tue, 2019-06-18 at 22:55 +0200, Arnd Bergmann wrote:
> On Tue, Jun 18, 2019 at 10:36 PM Johannes Berg
> wrote:
> >
> > On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
> > >
> > > From my understanding, the ioctl interface would create the lower
> > > netdev after talking to the firmwa
On Tue, Jun 18, 2019 at 10:36 PM Johannes Berg
wrote:
>
> On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
> >
> > From my understanding, the ioctl interface would create the lower
> > netdev after talking to the firmware, and then user space would use
> > the rmnet interface to create a ma
On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote:
> > Yeah, but where do you hang that driver? Maybe the TTY function is
> > actually a WWAN specific USB driver, but the ethernet is something
> > generic that can also work with pure ethernet USB devices, and it's
> > difficult to figure out
On Tue, 2019-06-18 at 21:59 +0200, Arnd Bergmann wrote:
>
> From my understanding, the ioctl interface would create the lower
> netdev after talking to the firmware, and then user space would use
> the rmnet interface to create a matching upper-level device for that.
> This is an artifact of the s
On Tue, Jun 18, 2019 at 10:15 PM Johannes Berg
wrote:
> On Tue, 2019-06-18 at 22:09 +0200, Arnd Bergmann wrote:
> > > One is the whole multi-function device, where a single WWAN device is
> > > composed of channels offered by actually different drivers, e.g. for a
> > > typical USB device you migh
On Tue, 2019-06-18 at 22:09 +0200, Arnd Bergmann wrote:
>
> > One is the whole multi-function device, where a single WWAN device is
> > composed of channels offered by actually different drivers, e.g. for a
> > typical USB device you might have something like cdc_ether and the
> > usb_wwan TTY dri
On Tue, Jun 18, 2019 at 9:03 PM Johannes Berg wrote:
> On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote:
> Really there are two possible ways (and they intersect to some extent).
>
> One is the whole multi-function device, where a single WWAN device is
> composed of channels offered by actuall
On Tue, Jun 18, 2019 at 9:14 PM Johannes Berg wrote:
> On Tue, 2019-06-18 at 08:16 -0500, Alex Elder wrote:
> > On 6/17/19 6:28 AM, Johannes Berg wrote:
> > So getting back to your question, the IPA in its current form only
> > has a single "multiplexed" channel carried over the connection
> > bet
On Tue, 2019-06-18 at 09:00 -0500, Alex Elder wrote:
> Deaggregation is a connection property, not a channel property.
That'd make sense, yes.
> And it looks like that's exactly how it's used in the rmnet
> driver.
Yeah, I think you're right. I got confused by the whole use of "port"
there, b
On Tue, 2019-06-18 at 08:16 -0500, Alex Elder wrote:
> On 6/17/19 6:28 AM, Johannes Berg wrote:
> > On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
> > > wrote:
> > >
> > > > > As I've made clear before, my work on this has been focused
On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote:
> If it had a well-defined way of creating new channels to be
> multiplexed over the connection to the modem, the IPA driver
> (rather than the rmnet driver) could present network interfaces
> for each and perform the multiplexing.
Right. Tha
Just to add to Dan's response, I think he's captured our discussions and
thoughts well.
> First, a few terms (correct or improve as you like):
Thanks for defining, we don't do that nearly often enough.
> - WWAN device is a hardware device (like IPA) that presents a
> connection between AP and
On Tue, 2019-06-18 at 10:20 -0500, Alex Elder wrote:
> On 6/17/19 7:25 AM, Johannes Berg wrote:
> > On Mon, 2019-06-17 at 13:42 +0200, Johannes Berg wrote:
> >
> > > But anyway, as I alluded to above, I had something like this in
> > > mind:
> >
> > I forgot to state this here, but this was *heav
On 6/17/19 7:25 AM, Johannes Berg wrote:
> On Mon, 2019-06-17 at 13:42 +0200, Johannes Berg wrote:
>
>> But anyway, as I alluded to above, I had something like this in mind:
>
> I forgot to state this here, but this was *heavily* influenced by
> discussions with Dan - many thanks to him.
Thanks
On 6/17/19 7:14 AM, Johannes Berg wrote:
> On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
>
> [...]
>
> Looking at the flags again,
I sort of talked about this in my message a little earlier, but I
now see I was partially mistaken. I thought these flags were
used in messages but they'r
On Tue, Jun 18, 2019 at 3:16 PM Alex Elder wrote:
> On 6/17/19 6:28 AM, Johannes Berg wrote:
> > On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
>
> I'm probably missing something, but I think the checksum
> offload could be handled by the IPA driver rather than
> rmnet. It seems to be an
On 6/17/19 6:42 AM, Johannes Berg wrote:
> On Wed, 2019-06-12 at 17:06 +0200, Arnd Bergmann wrote:
>> On Wed, Jun 12, 2019 at 4:28 PM Dan Williams wrote:
>>> On Wed, 2019-06-12 at 10:31 +0200, Arnd Bergmann wrote:
On Tue, Jun 11, 2019 at 7:23 PM Dan Williams wrote:
>>>
>>> I was trying to ma
On 6/17/19 6:28 AM, Johannes Berg wrote:
> On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
>> On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
>> wrote:
>>
As I've made clear before, my work on this has been focused on the IPA
transport,
and some of this higher-level LTE arch
On Mon, 2019-06-17 at 13:42 +0200, Johannes Berg wrote:
> But anyway, as I alluded to above, I had something like this in mind:
I forgot to state this here, but this was *heavily* influenced by
discussions with Dan - many thanks to him.
> driver_dev
> struct device *dev (USB, PCI, ...)
> net
On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
[...]
Looking at the flags again,
> #define RMNET_FLAGS_INGRESS_DEAGGREGATION (1U << 0)
This one I'm not sure I understand - seems weird to have such a
fundamental thing as a *configuration* on the channel.
> #define RMNET_FLAGS_I
On Wed, 2019-06-12 at 17:06 +0200, Arnd Bergmann wrote:
> On Wed, Jun 12, 2019 at 4:28 PM Dan Williams wrote:
> > On Wed, 2019-06-12 at 10:31 +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 11, 2019 at 7:23 PM Dan Williams wrote:
> >
> > I was trying to make the point that rmnet doesn't need to ca
On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
> On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
> wrote:
>
> > > As I've made clear before, my work on this has been focused on the IPA
> > > transport,
> > > and some of this higher-level LTE architecture is new to me. But it
> > > seems
On Wed, Jun 12, 2019 at 4:28 PM Dan Williams wrote:
> On Wed, 2019-06-12 at 10:31 +0200, Arnd Bergmann wrote:
> > On Tue, Jun 11, 2019 at 7:23 PM Dan Williams wrote:
> I was trying to make the point that rmnet doesn't need to care about
> how the QMAP packets get to the device itself; it can be p
On Wed, 2019-06-12 at 10:31 +0200, Arnd Bergmann wrote:
> On Tue, Jun 11, 2019 at 7:23 PM Dan Williams wrote:
> > On Tue, 2019-06-11 at 10:52 -0600, Subash Abhinov Kasiviswanathan
> > wrote:
> >
> > rmnet should handle muxing the QMAP, QoS, and aggregation and pass
> > the
> > resulting packet to
On Tue, Jun 11, 2019 at 7:23 PM Dan Williams wrote:
> On Tue, 2019-06-11 at 10:52 -0600, Subash Abhinov Kasiviswanathan wrote:
>
> rmnet should handle muxing the QMAP, QoS, and aggregation and pass the
> resulting packet to the lower layer. That lower layer could be IPA or
> qmi_wwan, which in tur
On Tue, 2019-06-11 at 10:52 -0600, Subash Abhinov Kasiviswanathan
wrote:
> > The general plan (and I believe Daniele Palmas was working on it)
> > was
> > to eventually make qmi_wwan use rmnet rather than its internal
> > sysfs-
> > based implementation. qmi_wwan and ipa are at essentially the same
The general plan (and I believe Daniele Palmas was working on it) was
to eventually make qmi_wwan use rmnet rather than its internal sysfs-
based implementation. qmi_wwan and ipa are at essentially the same
level and both could utilize rmnet on top.
*That's* what I'd like to see. I don't want to
On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote:
> On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
> wrote:
>
> > > As I've made clear before, my work on this has been focused on
> > > the IPA transport,
> > > and some of this higher-level LTE architecture is new to me. But
> > > it
> > >
On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg
wrote:
> > As I've made clear before, my work on this has been focused on the IPA
> > transport,
> > and some of this higher-level LTE architecture is new to me. But it
> > seems pretty clear that an abstracted WWAN subsystem is a good plan,
> > be
Hi Alex, all,
> > Exactly correct. This is what Johannes is discussing in his "cellular
> > modem APIs - take 2" thread about how this should all be organized at
> > the driver level and I think we should figure that out before we commit
> > to IPA-with-a-useless-netdev that requires rmnets to be
On 5/30/19 10:53 PM, Alex Elder wrote:
> This series presents the driver for the Qualcomm IP Accelerator (IPA).
>
> This is version 2 of the series. This version has addressed almost
> all of the feedback received in the first version:
> https://lore.kernel.org/lkml/20190512012508.10608-1-el...
On 5/31/19 5:08 PM, Alex Elder wrote:
> On 5/31/19 4:12 PM, Arnd Bergmann wrote:
>> On Fri, May 31, 2019 at 10:47 PM Alex Elder wrote:
>>> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
> On 5/31/19 9:58 AM, Dan Williams wrote:
>> On Thu, 2
On 6/4/19 4:29 PM, Dan Williams wrote:
> On Tue, 2019-06-04 at 22:04 +0200, Arnd Bergmann wrote:
>> On Tue, Jun 4, 2019 at 5:18 PM Dan Williams wrote:
>>> On Tue, 2019-06-04 at 10:13 +0200, Arnd Bergmann wrote:
Can you describe what kind of multiplexing is actually going on?
I'm still un
On Tue, 2019-06-04 at 22:04 +0200, Arnd Bergmann wrote:
> On Tue, Jun 4, 2019 at 5:18 PM Dan Williams wrote:
> > On Tue, 2019-06-04 at 10:13 +0200, Arnd Bergmann wrote:
> > > Can you describe what kind of multiplexing is actually going on?
> > > I'm still unclear about what we actually use multipl
On Tue, Jun 4, 2019 at 5:18 PM Dan Williams wrote:
> On Tue, 2019-06-04 at 10:13 +0200, Arnd Bergmann wrote:
> >
> > Can you describe what kind of multiplexing is actually going on?
> > I'm still unclear about what we actually use multiple logical
> > interfaces for here, and how they relate to on
On Mon, 2019-06-03 at 13:04 -0600, Subash Abhinov Kasiviswanathan
wrote:
> > > I can't (or won't) comment right now on whether IPA needs its own
> > > netdev for rmnet to use. The IPA endpoints used for the modem
> > > network interfaces are enabled when the netdev is opened and
> > > disabled whe
On Tue, 2019-06-04 at 10:13 +0200, Arnd Bergmann wrote:
> On Mon, Jun 3, 2019 at 3:32 PM Alex Elder wrote:
> > On 6/3/19 5:04 AM, Arnd Bergmann wrote:
> > > On Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan
> > >
> > > - What I'm worried about most here is the flow control handling
>
On Mon, Jun 3, 2019 at 3:32 PM Alex Elder wrote:
> On 6/3/19 5:04 AM, Arnd Bergmann wrote:
> > On Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan
> >
> > - What I'm worried about most here is the flow control handling on the
> > transmit side. The IPA driver now uses the modern BQL me
I can't (or won't) comment right now on whether IPA needs its own
netdev for rmnet to use. The IPA endpoints used for the modem
network interfaces are enabled when the netdev is opened and
disabled when closed. Outside of that, TX and RX are pretty
much immediately passed through to the layer be
On Mon, 2019-06-03 at 10:52 -0500, Alex Elder wrote:
> On 6/3/19 9:54 AM, Dan Williams wrote:
> > > To be perfectly honest, at first I thought having IPA use rmnet
> > > was a cargo cult thing like Dan suggested, because I didn't see
> > To be clear I only meant cargo-culting the naming, not any
>
On 6/3/19 9:54 AM, Dan Williams wrote:
>> To be perfectly honest, at first I thought having IPA use rmnet
>> was a cargo cult thing like Dan suggested, because I didn't see
> To be clear I only meant cargo-culting the naming, not any
> functionality. Clearly IPA/rmnet/QMAP are pretty intimately con
On Fri, 2019-05-31 at 15:47 -0500, Alex Elder wrote:
> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > On Fri, May 31, 2019 at 6:36 PM Alex Elder
> > wrote:
> > > On 5/31/19 9:58 AM, Dan Williams wrote:
> > > > On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> > > >
> > > > My question from the
On Fri, 2019-05-31 at 17:59 -0600, Subash Abhinov Kasiviswanathan
wrote:
> On 2019-05-31 17:33, Bjorn Andersson wrote:
> > On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
> >
> > > On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > > > On Fri, May 31, 2019 at 6:36 PM Alex Elder
> > > > wrote:
> > > > >
On 6/3/19 5:04 AM, Arnd Bergmann wrote:
> On Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan
> wrote:
>> On 2019-05-31 17:33, Bjorn Andersson wrote:
>>> On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
On 5/31/19 2:19 PM, Arnd Bergmann wrote:
>>> But any such changes would either be
On Sat, Jun 1, 2019 at 1:59 AM Subash Abhinov Kasiviswanathan
wrote:
> On 2019-05-31 17:33, Bjorn Andersson wrote:
> > On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
> >> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > But any such changes would either be years into the future or for
> > specific de
On 2019-05-31 17:33, Bjorn Andersson wrote:
On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
>> On 5/31/19 9:58 AM, Dan Williams wrote:
>>> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
>>>
>>> M
On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
> >> On 5/31/19 9:58 AM, Dan Williams wrote:
> >>> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> >>>
> >>> My question from the Nov 2018 IPA rm
On Fri 31 May 12:19 PDT 2019, Arnd Bergmann wrote:
> On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
> > On 5/31/19 9:58 AM, Dan Williams wrote:
> > > On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
[..]
> > So basically, the purpose of the rmnet driver is to handle QMAP
> > protocol conne
On 5/31/19 4:12 PM, Arnd Bergmann wrote:
> On Fri, May 31, 2019 at 10:47 PM Alex Elder wrote:
>> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
>>> On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
On 5/31/19 9:58 AM, Dan Williams wrote:
> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
>
On Fri, May 31, 2019 at 10:47 PM Alex Elder wrote:
> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
> >> On 5/31/19 9:58 AM, Dan Williams wrote:
> >>> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> >
> > Does this mean that IPA can only be u
On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
>> On 5/31/19 9:58 AM, Dan Williams wrote:
>>> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
>>>
>>> My question from the Nov 2018 IPA rmnet driver still stands; how does
>>> this relate to net/ethe
On Fri, May 31, 2019 at 6:36 PM Alex Elder wrote:
> On 5/31/19 9:58 AM, Dan Williams wrote:
> > On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> >
> > My question from the Nov 2018 IPA rmnet driver still stands; how does
> > this relate to net/ethernet/qualcomm/rmnet/ if at all? And if this
On 5/31/19 9:58 AM, Dan Williams wrote:
> On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
>> This series presents the driver for the Qualcomm IP Accelerator
>> (IPA).
>>
>> This is version 2 of the series. This version has addressed almost
>> all of the feedback received in the first version:
On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> This series presents the driver for the Qualcomm IP Accelerator
> (IPA).
>
> This is version 2 of the series. This version has addressed almost
> all of the feedback received in the first version:
>
> https://lore.kernel.org/lkml/201905120
This series presents the driver for the Qualcomm IP Accelerator (IPA).
This is version 2 of the series. This version has addressed almost
all of the feedback received in the first version:
https://lore.kernel.org/lkml/20190512012508.10608-1-el...@linaro.org/
More detail is included in the indiv
77 matches
Mail list logo
