[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-wireless
Subject:    Re: [RFC] wwan: add a new WWAN subsystem
From:       Dan Williams <dcbw () redhat ! com>
Date:       2020-02-26 22:15:53
Message-ID: bd04741b8a8f07e1f1b622cf28ac1ed89d964509.camel () redhat ! com
[Download RAW message or body]

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
> 

[prev in list] [next in list] [prev in thread] [next in thread]