On Tue, 2020-02-25 at 16:39 +0100, Johannes Berg wrote: > On Tue, 2020-02-25 at 16:15 +0100, Andrew Lunn wrote: > > > Looking at it bottom up, is the WWAN device itself made up of > > multiple > > devices? Are the TTYs separate drivers to the packet moving > > engines? > > Possibly, yes, it depends a bit. > > > They have there own USB end points, and could just be standard CDC > > ACM? > > Yeah, for a lot of USB devices that's indeed the case. For exmaple, the most common non-embedded case is USB WWAN cards (whether sticks or M.2/PCIe minicard): * one or more "control" ports, either CDC-ACM that speak AT commands or CDC-WDM that speak QMI, AT, or MBIM. Exposed by drivers like cdc-acm, cdc-wdm, option, qcserial, qcaux, hso, sierra, etc. * one or more "data" ports that are exposed by USB network drivers. Exposed by drivers like cdc-ether, cdc-ncm, qmi-wwan, sierra-net, hso, etc. In most cases the data port needs to be configured using specific commands from the control ports to be useful and pass traffic. They are logically the same device, but use totally separate kernel drivers and sometimes buses. But that's only for USB. Qualcomm embedded stuff will use a different bus, other devices use PCI, some have both platform serial and USB connections. But I don't think we need a perfect solution, just something that handles a bunch of the cases that we can improve over time. Dan > > driver/base/component.c could be useful for bringing together these > > individual devices to form the whole WWAN device. > > Huh, I was unaware of this, I'll take a look! > > A very brief look suggests that it wants to have a driver for the > whole > thing in the end, which isn't really true here, but perhaps we could > "make one up" and have that implement the userspace API. I need to > take > a closer look, thanks for the pointer. > > > Plus you need to avoid confusion by not adding another "component > > framework" which means something totally different to the existing > > component framework. > > :) > > johannes >
