net: Add a WWAN subsystem
This change introduces initial support for a WWAN framework. Given the
complexity and heterogeneity of existing WWAN hardwares and interfaces,
there is no strict definition of what a WWAN device is and how it should
be represented. It's often a collection of multiple devices that perform
the global WWAN feature (netdev, tty, chardev, etc).
One usual way to expose modem controls and configuration is via high
level protocols such as the well known AT command protocol, MBIM or
QMI. The USB modems started to expose them as character devices, and
user daemons such as ModemManager learnt to use them.
This initial version adds the concept of WWAN port, which is a logical
pipe to a modem control protocol. The protocols are rawly exposed to
user via character device, allowing straigthforward support in existing
tools (ModemManager, ofono...). The WWAN core takes care of the generic
part, including character device management, and relies on port driver
operations to receive/submit protocol data.
Since the different devices exposing protocols for a same WWAN hardware
do not necessarily know about each others (e.g. two different USB
interfaces, PCI/MHI channel devices...) and can be created/removed in
different orders, the WWAN core ensures that all WAN ports contributing
to the 'whole' WWAN feature are grouped under the same virtual WWAN
device, relying on the provided parent device (e.g. mhi controller,
USB device). It's a 'trick' I copied from Johannes's earlier WWAN
subsystem proposal.
This initial version is purposely minimalist, it's essentially moving
the generic part of the previously proposed mhi_wwan_ctrl driver inside
a common WWAN framework, but the implementation is open and flexible
enough to allow extension for further drivers.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-16 08:36:33 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
#
|
|
|
|
|
# Wireless WAN device configuration
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
menuconfig WWAN
|
|
|
|
|
bool "Wireless WAN"
|
|
|
|
|
help
|
|
|
|
|
This section contains Wireless WAN configuration for WWAN framework
|
|
|
|
|
and drivers.
|
|
|
|
|
|
|
|
|
|
if WWAN
|
|
|
|
|
|
|
|
|
|
config WWAN_CORE
|
|
|
|
|
tristate "WWAN Driver Core"
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you want to use the WWAN driver core. This driver
|
|
|
|
|
provides a common framework for WWAN drivers.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called wwan.
|
|
|
|
|
|
2021-06-08 04:02:32 +00:00
|
|
|
config WWAN_HWSIM
|
|
|
|
|
tristate "Simulated WWAN device"
|
|
|
|
|
depends on WWAN_CORE
|
|
|
|
|
help
|
|
|
|
|
This driver is a developer testing tool that can be used to test WWAN
|
|
|
|
|
framework.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called wwan_hwsim. If unsure, say N.
|
|
|
|
|
|
2021-04-16 08:36:34 +00:00
|
|
|
config MHI_WWAN_CTRL
|
|
|
|
|
tristate "MHI WWAN control driver for QCOM-based PCIe modems"
|
|
|
|
|
select WWAN_CORE
|
|
|
|
|
depends on MHI_BUS
|
|
|
|
|
help
|
|
|
|
|
MHI WWAN CTRL allows QCOM-based PCIe modems to expose different modem
|
|
|
|
|
control protocols/ports to userspace, including AT, MBIM, QMI, DIAG
|
|
|
|
|
and FIREHOSE. These protocols can be accessed directly from userspace
|
|
|
|
|
(e.g. AT commands) or via libraries/tools (e.g. libmbim, libqmi,
|
|
|
|
|
libqcdm...).
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called mhi_wwan_ctrl.
|
|
|
|
|
|
net: Add a WWAN subsystem
This change introduces initial support for a WWAN framework. Given the
complexity and heterogeneity of existing WWAN hardwares and interfaces,
there is no strict definition of what a WWAN device is and how it should
be represented. It's often a collection of multiple devices that perform
the global WWAN feature (netdev, tty, chardev, etc).
One usual way to expose modem controls and configuration is via high
level protocols such as the well known AT command protocol, MBIM or
QMI. The USB modems started to expose them as character devices, and
user daemons such as ModemManager learnt to use them.
This initial version adds the concept of WWAN port, which is a logical
pipe to a modem control protocol. The protocols are rawly exposed to
user via character device, allowing straigthforward support in existing
tools (ModemManager, ofono...). The WWAN core takes care of the generic
part, including character device management, and relies on port driver
operations to receive/submit protocol data.
Since the different devices exposing protocols for a same WWAN hardware
do not necessarily know about each others (e.g. two different USB
interfaces, PCI/MHI channel devices...) and can be created/removed in
different orders, the WWAN core ensures that all WAN ports contributing
to the 'whole' WWAN feature are grouped under the same virtual WWAN
device, relying on the provided parent device (e.g. mhi controller,
USB device). It's a 'trick' I copied from Johannes's earlier WWAN
subsystem proposal.
This initial version is purposely minimalist, it's essentially moving
the generic part of the previously proposed mhi_wwan_ctrl driver inside
a common WWAN framework, but the implementation is open and flexible
enough to allow extension for further drivers.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-16 08:36:33 +00:00
|
|
|
endif # WWAN
|