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
