OpenCloudOS-Kernel/drivers/net/wwan/Makefile

16 lines
403 B
Makefile
Raw Normal View History

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
#
# Makefile for the Linux WWAN device drivers.
#
obj-$(CONFIG_WWAN) += wwan.o
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
wwan-objs += wwan_core.o
obj-$(CONFIG_WWAN_HWSIM) += wwan_hwsim.o
obj-$(CONFIG_MHI_WWAN_CTRL) += mhi_wwan_ctrl.o
obj-$(CONFIG_MHI_WWAN_MBIM) += mhi_wwan_mbim.o
net: wwan: Add Qualcomm BAM-DMUX WWAN network driver 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. It is built using a simple protocol layer on top of a DMA engine (Qualcomm BAM) and bidirectional interrupts to coordinate power control. The modem announces a fixed set of channels by sending an OPEN command. The driver exports each channel as separate network interface so that a connection can be established via QMI from userspace. The network interface can work either in Ethernet or Raw-IP mode (configurable via QMI). However, Ethernet mode seems to be broken with most firmwares (network packets are actually received as Raw-IP), therefore the driver only supports Raw-IP mode. Note that the control channel (QMI/AT) is entirely separate from BAM-DMUX and is already supported by the RPMSG_WWAN_CTRL driver. The driver uses runtime PM to coordinate power control with the modem. TX/RX buffers are put in a kind of "ring queue" and submitted via the bam_dma driver of the DMAEngine subsystem. The basic architecture looks roughly like this: +------------+ +-------+ [IPv4/6] | BAM-DMUX | | | [Data...] | | | | ---------->|wwan0 | [DMUX chan: x] | | [IPv4/6] | (chan: 0) | [IPv4/6] | | [Data...] | | [Data...] | | ---------->|wwan1 |--------------->| Modem | | (chan: 1) | BAM | | [IPv4/6] | ... | (DMA Engine) | | [Data...] | | | | ---------->|wwan7 | | | | (chan: 7) | | | +------------+ +-------+ Note that some newer firmware versions support QMAP ("rmnet" driver) as additional multiplexing layer on top of BAM-DMUX, but this is not currently supported by this driver. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-28 01:31:08 +08:00
obj-$(CONFIG_QCOM_BAM_DMUX) += qcom_bam_dmux.o
net: wwan: Add RPMSG WWAN CTRL driver The remote processor messaging (rpmsg) subsystem provides an interface to communicate with other remote processors. On many Qualcomm SoCs this is used to communicate with an integrated modem DSP that implements most of the modem functionality and provides high-level protocols like QMI or AT to allow controlling the modem. For QMI, most older Qualcomm SoCs (e.g. MSM8916/MSM8974) have a standalone "DATA5_CNTL" channel that allows exchanging QMI messages. Note that newer SoCs (e.g. SDM845) only allow exchanging QMI messages via a shared QRTR channel that is available via a socket API on Linux. For AT, the "DATA4" channel accepts at least a limited set of AT commands, on many older and newer Qualcomm SoCs, although QMI is typically the preferred control protocol. Often there are additional QMI/AT channels (usually named DATA*_CNTL for QMI and DATA* for AT), but it is not clear if those are really functional on all devices. Also, at the moment there is no use case for having multiple QMI/AT ports. If needed more channels could be added later after more testing. Note that the data path (network interface) is entirely separate from the control path and varies between Qualcomm SoCs, e.g. "IPA" on newer Qualcomm SoCs or "BAM-DMUX" on some older ones. The RPMSG WWAN CTRL driver exposes the QMI/AT control ports via the WWAN subsystem, and therefore allows userspace like ModemManager to set up the modem. Until now, ModemManager had to use the RPMSG-specific rpmsg-char where the channels must be explicitly exposed as a char device first and don't show up directly in sysfs. The driver is a fairly simple glue layer between WWAN and RPMSG and is mostly based on the existing mhi_wwan_ctrl.c and rpmsg_char.c. Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-19 01:36:10 +08:00
obj-$(CONFIG_RPMSG_WWAN_CTRL) += rpmsg_wwan_ctrl.o
obj-$(CONFIG_IOSM) += iosm/