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 16:36:33 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
#
|
|
|
|
|
# Wireless WAN device configuration
|
|
|
|
|
#
|
|
|
|
|
|
2021-06-15 00:56:36 +08:00
|
|
|
menu "Wireless WAN"
|
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 16:36:33 +08:00
|
|
|
|
2021-06-15 00:56:36 +08:00
|
|
|
config WWAN
|
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 16:36:33 +08:00
|
|
|
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-15 00:56:36 +08:00
|
|
|
if WWAN
|
|
|
|
|
|
2021-06-08 12:02:32 +08:00
|
|
|
config WWAN_HWSIM
|
|
|
|
|
tristate "Simulated WWAN device"
|
|
|
|
|
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 16:36:34 +08:00
|
|
|
config MHI_WWAN_CTRL
|
|
|
|
|
tristate "MHI WWAN control driver for QCOM-based PCIe modems"
|
|
|
|
|
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.
|
|
|
|
|
|
2021-08-03 21:36:28 +08:00
|
|
|
config MHI_WWAN_MBIM
|
|
|
|
|
tristate "MHI WWAN MBIM network driver for QCOM-based PCIe modems"
|
|
|
|
|
depends on MHI_BUS
|
|
|
|
|
help
|
|
|
|
|
MHI WWAN MBIM is a WWAN network driver for QCOM-based PCIe modems.
|
|
|
|
|
It implements MBIM over MHI, for IP data aggregation and muxing.
|
|
|
|
|
A default wwan0 network interface is created for MBIM data session
|
|
|
|
|
ID 0. Additional links can be created via wwan rtnetlink type.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called mhi_wwan_mbim.
|
|
|
|
|
|
2021-06-19 01:36:10 +08:00
|
|
|
config RPMSG_WWAN_CTRL
|
|
|
|
|
tristate "RPMSG WWAN control driver"
|
|
|
|
|
depends on RPMSG
|
|
|
|
|
help
|
|
|
|
|
RPMSG WWAN CTRL allows modems available via RPMSG channels to expose
|
|
|
|
|
different modem protocols/ports to userspace, including AT and QMI.
|
|
|
|
|
These protocols can be accessed directly from userspace
|
|
|
|
|
(e.g. AT commands) or via libraries/tools (e.g. libqmi, libqcdm...).
|
|
|
|
|
|
|
|
|
|
This is mainly used for modems integrated into many Qualcomm SoCs,
|
|
|
|
|
e.g. for AT and QMI on Qualcomm MSM8916 or MSM8974. Note that many
|
|
|
|
|
newer Qualcomm SoCs (e.g. SDM845) still provide an AT port through
|
|
|
|
|
this driver but the QMI messages can only be sent through
|
|
|
|
|
QRTR network sockets (CONFIG_QRTR).
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will be
|
|
|
|
|
called rpmsg_wwan_ctrl.
|
|
|
|
|
|
2021-06-13 20:50:23 +08:00
|
|
|
config IOSM
|
|
|
|
|
tristate "IOSM Driver for Intel M.2 WWAN Device"
|
|
|
|
|
depends on INTEL_IOMMU
|
|
|
|
|
help
|
|
|
|
|
This driver enables Intel M.2 WWAN Device communication.
|
|
|
|
|
|
|
|
|
|
If you have one of those Intel M.2 WWAN Modules and wish to use it in
|
|
|
|
|
Linux say Y/M here.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
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 16:36:33 +08:00
|
|
|
endif # WWAN
|
2021-06-15 00:56:36 +08:00
|
|
|
|
|
|
|
|
endmenu
|