netdev - Re: [RFC] wwan: add a new WWAN subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Feb 2020 16:15:53 -0600
From:   Dan Williams <dcbw@...hat.com>
To:     Johannes Berg <johannes@...solutions.net>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        Alex Elder <elder@...aro.org>, m.chetan.kumar@...el.com,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [RFC] wwan: add a new WWAN subsystem

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
>