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 driver. In this way, we need to "compose" the WWAN device > > similarly, e.g. by using the underlying USB device "struct device" > > pointer to tie it together. > > > > The other is something like IPA or the Intel modem driver, where the > > device is actually a single (e.g. PCIe) device and just has a single > > driver, but that single driver offers different channels. > > I would hope we can simplify this to expect only the second model, > where you have a 'struct device' corresponding to hardware and the > driver for it creates one wwan_device that user space talks to. I'm not sure. Fundamentally, we have drivers in Linux for the ethernet part, for the TTY part, and for whatever other part might be in a given USB multi- function device. > Clearly the multi-function device hardware has to be handled somehow, > but it would seem much cleaner in the long run to do that using > a special workaround rather than putting this into the core interface. I don't think it really makes the core interface much more complex or difficult though, and it feels easier than writing a completely different USB driver yet again for all these devices? As far as I understand from Dan, sometimes they really are no different from a generic USB TTY and a generic USB ethernet, except you know that if those show up together it's a modem. > E.g. have a driver that lets you create a wwan_device by passing > netdev and a tty chardev into a configuration interface, and from that > point on use the generic wwan abstraction. 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 how to tie those together. The modules could load in completely different order, or even the ethernet module could load but the TTY one doesn't because it's not configured, or vice versa. > > Now, it's not clear to me where IPA actually falls, because so far we've > > been talking about the IPA driver only as providing *netdevs*, not any > > control channels, so I'm not actually sure where the control channel is. > > The IPA driver today only handles the data path, because Alex removed > the control channel. IPA is the driver that needs to talk to the hardware, > both for data and control when finished. rmnet is a pure software construct > that also contains both a data and control side and is designed to be > independent of the lower hardware. I'd actually be interested in what the control path should be like. Is it also muxed on QMAP in the same way? johannes
