On Tue, 2020-02-25 at 16:39 +0100, Johannes Berg wrote:

On Tue, 2020-02-25 at 16:15 +0100, Andrew Lunn wrote:

quoted

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.

quoted

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

quoted

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.

quoted

Plus you need to avoid confusion by not adding another "component
framework" which means something totally different to the existing
component framework.

:)

johannes