Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver
From: Alex Elder
Date: Mon Jun 24 2019 - 12:21:37 EST
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 (like IPA) that presents a
>> connection between AP and modem, and presents an interface
>> that allows the use of that connection to be managed.
> Yes. But I was actually thinking of a "wwan_dev" to be a separate
> structure, not *directly* owned by a single driver and used to represent
> the hardware like a (hypothetical) "struct ipa_dev".
I think you're talking about creating a coordination interface
that allows multiple drivers to interact with a WWAN device,
which might implement several independent features.
>> - WWAN netdevice represents a Linux network interface, with its
>> operations and queues, etc., but implements a standardized
>> set of WWAN-specific operations. It represents a logical
>> ' channel whose data is multiplexed over the WWAN device.
> I'm not sure I'd asy it has much WWAN-specific operations? But yeah, I
> guess it might.
I want to withdraw this notion of a "WWAN netdevice"...
>> - WWAN channel is a user space abstraction that corresponds
>> with a WWAN netdevice (but I'm not clear on all the ways
>> they differ or interact).
> As Dan said, this could be a different abstraction than a netdevice,
> like a TTY, etc.
Right, I get that now.
. . .
>> - Which WWAN channel attributes must be set *before* the
>> channel is activated, and can't be changed? Are there any
>> that can be changed dynamically?
> It's a good question. I threw a "u32 pdn" in there, but I'm not actually
> sure that's what you *really* need?
> Maybe the modem and userspace just agree on some arbitrary "session
> identifier"? Dan mentions "MUX ID" or "MBIM Session ID", maybe there
> really is no good general term for this and we should just call it a
> "session identifier" and agree that it depends on the control protocol
> (MBIM vs. QMI vs. ...)?
>> And while the whole point of this is to make things generic,
>> it might be nice to have a way to implement a new feature
>> before it can be "standardized".
> Not sure I understand this?
I'm talking about a way to experiment with new functionality in a
way that's explicitly not part of the interface. But doing that
isn't necessary and it's probably not a good idea anyway.
> FWIW, I actually came to this because we want to upstream a driver for
> an Intel modem, but ... can't really make up our mind on whether or not
> to use VLAN tags, something like rmnet (but we obviously cannot use
> rmnet, so that'd be another vendor specific interface like rmnet), or
> sysfs, or any of the other methods we have today ... :-)
OK cool then we have some common needs. Let's get this defined so
we can use it for both!