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 10:36:33 +02:00
# SPDX-License-Identifier: GPL-2.0-only
#
# Wireless WAN device configuration
#
2021-06-14 18:56:36 +02: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 10:36:33 +02:00
2021-06-14 18:56:36 +02: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 10:36:33 +02: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-14 18:56:36 +02:00
if WWAN
2021-12-07 12:21:40 +03:00
config WWAN_DEBUGFS
bool "WWAN devices debugfs interface" if EXPERT
depends on DEBUG_FS
default y
help
Enables debugfs infrastructure for the WWAN core and device drivers.
If this option is selected, then you can find the debug interface
elements for each WWAN device in a directory that is corresponding to
the device name: debugfs/wwan/wwanX.
2021-06-08 07:02:32 +03: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 10:36:34 +02: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 15:36:28 +02: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-11-27 18:31:08 +01:00
config QCOM_BAM_DMUX
tristate "Qualcomm BAM-DMUX WWAN network driver"
depends on (DMA_ENGINE && PM && QCOM_SMEM_STATE) || COMPILE_TEST
help
The BAM Data Multiplexer provides access to the network data channels
of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm
MSM8916 or MSM8974. The connection can be established via QMI/AT from
userspace with control ports available through the WWAN subsystem
(CONFIG_RPMSG_WWAN_CTRL) or QRTR network sockets (CONFIG_QRTR).
To compile this driver as a module, choose M here: the module will be
called qcom_bam_dmux.
2021-06-18 19:36:10 +02: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 18:20:23 +05:30
config IOSM
tristate "IOSM Driver for Intel M.2 WWAN Device"
depends on INTEL_IOMMU
2021-09-19 22:58:35 +05:30
select NET_DEVLINK
2021-12-07 12:21:40 +03:00
select RELAY if WWAN_DEBUGFS
2021-06-13 18:20:23 +05:30
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.
2022-05-06 11:13:00 -07:00
config MTK_T7XX
tristate "MediaTek PCIe 5G WWAN modem T7xx device"
depends on PCI
help
Enables MediaTek PCIe based 5G WWAN modem (T7xx series) device.
Adapts WWAN framework and provides network interface like wwan0
and tty interfaces like wwan0at0 (AT protocol), wwan0mbim0
(MBIM protocol), etc.
To compile this driver as a module, choose M here: the module will be
called mtk_t7xx.
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 10:36:33 +02:00
endif # WWAN
2021-06-14 18:56:36 +02:00
endmenu
