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". > - 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. > - 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. > - The WWAN core is kernel code that presents abstractions > for WWAN devices and netdevices, so they can be managed > in a generic way. It is for configuration and communication > and is not at all involved in the data path. > > You're saying that the WWAN driver space calls wwan_add() > to register itself as a new WWAN device. Assuming it knows that it is in fact a WWAN device, like IPA. > You're also saying that a WWAN device "attaches" a WWAN > netdevice, which is basically notifying the WWAN core > that the new netdev/channel is available for use. > - I trust that a "tentative" attachement is necessary. But > I'm not sure what makes it transition into becoming a > "real" one, or how that event gets communicated. I think Dan explained this one well. This wasn't actually on my radar until he pointed it out. Really this only exists with USB devices that appear as multiple functions (ethernet, tty, ...) but still represent a single WWAN device, with each function not necessarily being aware of that since it's just a function driver. Hopefully at least one of the function drivers will be able to figure it out, and then we can combine all of the functions into the WWAN device abstraction. [snip - Dan's explanations are great] Dan also said: > > I read "attach" here as simply associating an existing netdev with the > > "parent" WWAN device. A purely Linux operation that is only book- > > keeping and may not have any interaction with the modem. Now I'm replying out of thread, but yes, that's what I had in mind. What I meant by attaching (in this case) is just that you actually mark that it is (or might be, if tentatively attached) part of a WWAN device. > - Are there any attributes that are only optionally supported, > and if so, how are the supported ones communicated? As Dan said, good point. I hadn't really considered that for now. I sort of know that we need it, but for the sake of simplicity decided to elide it for now. I'm just not sure what really are needed, and netlink attributes make adding them (and discovering the valid ones) pretty easy in the future, when a need arises. > - 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? 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 ... :-) johannes
