summaryrefslogtreecommitdiff
path: root/drivers/net/wwan
AgeCommit message (Collapse)Author
2021-06-22wwan: core: relocate ops registering codeSergey Ryazanov
It is unlikely that RTNL callbacks will call WWAN ops (un-)register functions, but it is highly likely that the ops (un-)register functions will use RTNL link create/destroy handlers. So move the WWAN network interface ops (un-)register functions below the RTNL callbacks to be able to call them without forward declarations. No functional changes, just code relocation. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan_hwsim: support network interface creationSergey Ryazanov
Add support for networking interface creation via the WWAN core by registering the WWAN netdev creation ops for each simulated WWAN device. Implemented minimalistic netdev support where the xmit callback just consumes all egress skbs. This should help with WWAN network interfaces creation testing. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: iosm: remove an unnecessary NULL checkDan Carpenter
The address of &ipc_mux->ul_adb can't be NULL because it points to the middle of a non-NULL struct. Fixes: 9413491e20e1 ("net: iosm: encode or decode datagram") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-18net: wwan: Allow WWAN drivers to provide blocking tx and poll functionStephan Gerhold
At the moment, the WWAN core provides wwan_port_txon/off() to implement blocking writes. The tx() port operation should not block, instead wwan_port_txon/off() should be called when the TX queue is full or has free space again. However, in some cases it is not straightforward to make use of that functionality. For example, the RPMSG API used by rpmsg_wwan_ctrl.c does not provide any way to be notified when the TX queue has space again. Instead, it only provides the following operations: - rpmsg_send(): blocking write (wait until there is space) - rpmsg_trysend(): non-blocking write (return error if no space) - rpmsg_poll(): set poll flags depending on TX queue state Generally that's totally sufficient for implementing a char device, but it does not fit well to the currently provided WWAN port ops. Most of the time, using the non-blocking rpmsg_trysend() in the WWAN tx() port operation works just fine. However, with high-frequent writes to the char device it is possible to trigger a situation where this causes issues. For example, consider the following (somewhat unrealistic) example: # dd if=/dev/zero bs=1000 of=/dev/wwan0qmi0 dd: error writing '/dev/wwan0qmi0': Resource temporarily unavailable 1+0 records out This fails immediately after writing the first record. It's likely only a matter of time until this triggers issues for some real application (e.g. ModemManager sending a lot of large QMI packets). The rpmsg_char device does not have this problem, because it uses rpmsg_trysend() and rpmsg_poll() to support non-blocking operations. Make it possible to use the same in the RPMSG WWAN driver by adding two new optional wwan_port_ops: - tx_blocking(): send data blocking if allowed - tx_poll(): set additional TX poll flags This integrates nicely with the RPMSG API and does not require any change in existing WWAN drivers. With these changes, the dd example above blocks instead of exiting with an error. Cc: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-18net: wwan: Add RPMSG WWAN CTRL driverStephan Gerhold
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-16net: iosm: remove the repeated declaration and commentShaokun Zhang
Function 'ipc_mmio_get_cp_version' is declared twice, so remove the repeated declaration and wrong comments. Cc: M Chetan Kumar <m.chetan.kumar@intel.com> Cc: Intel Corporation <linuxwwan@intel.com> Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Reviewed-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-16net: iosm: add missing MODULE_DEVICE_TABLEZou Wei
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-14net: wwan: Fix WWAN config symbolsLoic Poulain
There is not strong reason to have both WWAN and WWAN_CORE symbols, Let's build the WWAN core framework when WWAN is selected, in the same way as for other subsystems. This fixes issue with mhi_net selecting WWAN_CORE without WWAN and reported by kernel test robot: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for WWAN_CORE Depends on NETDEVICES && WWAN Selected by - MHI_NET && NETDEVICES && NET_CORE && MHI_BUS Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-14net: wwan: iosm: Remove DEBUG flagLoic Poulain
Author forgot to remove that flag. Fixes: f7af616c632e ("net: iosm: infrastructure") Reported-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: infrastructureM Chetan Kumar
1) Kconfig & Makefile changes for IOSM Driver compilation. 2) Add IOSM Driver documentation. 3) Modified MAINTAINER file for IOSM Driver addition. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: net driverM Chetan Kumar
1) Create net device & implement net operations for data/IP communication. 2) Bind IP Link to mux IP session for simultaneous IP traffic. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: uevent supportM Chetan Kumar
Report modem status via uevent. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: protocol operationsM Chetan Kumar
1) Update UL/DL transfer descriptors in message ring. 2) Define message set for pipe/sleep protocol. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory protocolM Chetan Kumar
1) Defines messaging protocol for handling Transfer Descriptor in both UL/DL direction. 2) Ring buffer management. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: power managementM Chetan Kumar
Implements state machine to handle host & device sleep. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: encode or decode datagramM Chetan Kumar
1) Encode UL packet into datagram. 2) Decode DL datagram and route it to network layer. 3) Supports credit based flow control. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: multiplex IP sessionsM Chetan Kumar
Establish IP session between host-device & session management. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: bottom halfM Chetan Kumar
1) Bottom half(tasklet) for IRQ and task processing. 2) Tasks are processed asynchronous and synchronously. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: wwan port control deviceM Chetan Kumar
Implements wwan port for MBIM & AT protocol communication Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: channel configurationM Chetan Kumar
Defines pipes & channel configurations like channel type, pipe mappings, No. of transfer descriptors and transfer buffer size etc. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory I/O operationsM Chetan Kumar
1) Binds logical channel between host-device for communication. 2) Implements device specific(Char/Net) IO operations. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: shared memory IPC interfaceM Chetan Kumar
1) Initializes shared memory for host-device communication. 2) Allocate resources required for control & data operations. 3) Transfers the Device IRQ to IPC execution thread. 4) Defines the timer cbs for async events. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: mmio scratchpadM Chetan Kumar
1) Initializes the Scratchpad region for Host-Device communication. 2) Exposes device capabilities like chip info and device execution stages. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: irq handlingM Chetan Kumar
1) Request interrupt vector, frees allocated resource. 2) Registers IRQ handler. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-13net: iosm: entry pointM Chetan Kumar
1) Register IOSM driver with kernel to manage Intel WWAN PCIe device(PCI_VENDOR_ID_INTEL, INTEL_CP_DEVICE_7560_ID). 2) Exposes the EP PCIe device capability to Host PCIe core. 3) Initializes PCIe EP configuration and defines PCIe driver probe, remove and power management OPS. 4) Allocate and map(dma) skb memory for data communication from device to kernel and vice versa. Signed-off-by: M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-12wwan: add interface creation supportJohannes Berg
Add support to create (and destroy) interfaces via a new rtnetlink kind "wwan". The responsible driver has to use the new wwan_register_ops() to make this possible. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: purge rx queue on port closeSergey Ryazanov
Purge the rx queue as soon as a user closes the port, just after the port stop callback invocation. This is to prevent feeding a user that will open the port next time with outdated and possibly unrelated data. While at it also remove the odd skb_queue_purge() call in the port device destroy callback. The queue will be purged just before the callback is ivoncated in the wwan_remove_port() function. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: implement terminal ioctls for AT portSergey Ryazanov
It is not unreasonable to assume that users will use terminal emulation software to communicate directly with a WWAN device over the AT port. But terminal emulators will refuse to work with a device that does not support terminal IOCTLs (e.g. TCGETS, TCSETS, TIOCMSET, etc.). To make it possible to interact with the WWAN AT port using a terminal emulator, implement a minimal set of terminal IOCTLs. The implementation is rather stub, no passed data are actually used to control a port behaviour. An obtained configuration is kept inside the port structure and returned back by a request. The latter is done to fool a program that will test the configuration status by comparing the readed back data from the device with earlier configured ones. Tested with fresh versions of minicom and picocom terminal apps. MBIM, QMI and other ports for binary protocols can hardly be considered a terminal device, so terminal IOCTLs are only implemented for the AT port. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: implement TIOCINQ ioctlSergey Ryazanov
It is quite common for a userpace program to fetch the buffered amount of data in the rx queue to avoid the read block. Implement the TIOCINQ ioctl to make the migration to the WWAN port usage smooth. Despite the fact that the read call will return no more data than the size of a first skb in the queue, TIOCINQ returns the entire amount of buffered data (sum of all queued skbs). This is done to prevent the breaking of programs that optimize reading, avoiding it if the buffered amount of data is too small. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: expand ports number limitSergey Ryazanov
Currently, we limit the total ports number to 256. It is quite common for PBX or SMS gateway to be equipped with a lot of modems. In now days, a modem could have 2-4 control ports or even more, what only accelerates the ports exhausing rate. To avoid facing the port number limitation issue reports, increase the limit up the maximum number of minors (i.e. up to 1 << MINORBITS). Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: make port names more user-friendlySergey Ryazanov
At the moment, the port name is allocated based on the parent device name, port id and the port type. Where the port id specifies nothing but the ports registration order and is only used to make the port name unique. Most likely, to configure a WWAN device, the user will look for a port of a specific type (e.g. AT port or MBIM port, etc.). The current naming scheme can make it difficult to find a port of a specific type. Consider a WWAN device that has 3 ports: AT port, MBIM port, and another one AT port. With the global port index, the port names will be: * wwan0p1at * wwan0p2mbim * wwan0p3at To find the MBIM port, user should know in advance the device ports composition (i.e. the user should know that the MBIM port is the 2nd one) or carefully examine the whole ports list. It is not unusual for USB modems to have a different composition, even if they are build on a same chipset. Moreover, some modems able to change the ports composition based on the user's configuration. All this makes port names fully unpredictable. To make naming more user-friendly, remove the global port id and enumerate ports by its type. E.g.: * wwan0p1at -> wwan0at0 * wwan0p2mbim -> wwan0mbim0 * wwan0p3at -> wwan0at1 With this naming scheme, the first AT port name will always be wwanXat0, the first MBIM port name will always be wwanXmbim0, etc. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: spell port device name in lowercaseSergey Ryazanov
Usually a device name is spelled in lowercase, let us follow this practice in the WWAN subsystem as well. The bottom line is that such name is easier to type. To keep the device type attribute contents more natural (i.e., spell abbreviations in uppercase), while making the device name lowercase, turn the port type strings array to an array of structure that contains both the port type name and the device name suffix. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: core: init port type string array using enum valuesSergey Ryazanov
This array is indexed by port type. Make it self-descriptive by using the port type enum values as indices in the array initializer. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08net: wwan: make WWAN_PORT_MAX meaning less surprisedSergey Ryazanov
It is quite unusual when some value can not be equal to a defined range max value. Also most subsystems defines FOO_TYPE_MAX as a maximum valid value. So turn the WAN_PORT_MAX meaning from the number of supported port types to the maximum valid port type. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08wwan_hwsim: add debugfs management interfaceSergey Ryazanov
wwan_hwsim creates and removes simulated control ports on module loading and unloading. It would be helpful to be able to create/remove devices and ports at run-time to trigger wwan port (un-)register actions without module reloading. Some simulator objects (e.g. ports) do not have the underling device and it is not possible to fully manage the simulator via sysfs. wwan_hsim intend for developers, so implement it as a self-contained debugfs based management interface. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-08wwan_hwsim: WWAN device simulatorSergey Ryazanov
This driver simulates a set of WWAN device with a set of AT control ports. It can be used to test WWAN kernel framework as well as user space tools. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-25net: wwan: core: Add WWAN device index sysfs attributeLoic Poulain
Add index sysfs attribute for WWAN devices. This index is used to uniquely indentify and reference a WWAN device. 'index' is the attribute name that other device classes use (wireless, v4l2-dev, rfkill, etc...). Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-17net: wwan: Add WWAN port type attributeLoic Poulain
The port type is by default part of the WWAN port device name. However device name can not be considered as a 'stable' API and may be subject to change in the future. This change adds a proper device attribute that can be used to determine the WWAN protocol/ type. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-22net: wwan: core: Return poll error in case of port removalLoic Poulain
Ensure that the poll system call returns proper error flags when port is removed (nullified port ops), allowing user side to properly fail, without further read or write. Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: wwan: mhi_wwan_ctrl: Fix RX buffer starvationLoic Poulain
The mhi_wwan_rx_budget_dec function is supposed to return true if RX buffer budget has been successfully decremented, allowing to queue a new RX buffer for transfer. However the current implementation is broken when RX budget is '1', in which case budget is decremented but false is returned, preventing to requeue one buffer, and leading to RX buffer starvation. Fixes: fa588eba632d ("net: Add Qcom WWAN control driver") Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: wwan: Fix bit ops double shiftLoic Poulain
bit operation helpers such as test_bit, clear_bit, etc take bit position as parameter and not value. Current usage causes double shift => BIT(BIT(0)). Fix that in wwan_core and mhi_wwan_ctrl. Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-16net: Add Qcom WWAN control driverLoic Poulain
The MHI WWWAN control driver allows MHI QCOM-based modems to expose different modem control protocols/ports via the WWAN framework, so that userspace modem tools or daemon (e.g. ModemManager) can control WWAN config and state (APN config, SMS, provider selection...). A QCOM-based modem can expose one or several of the following protocols: - AT: Well known AT commands interactive protocol (microcom, minicom...) - MBIM: Mobile Broadband Interface Model (libmbim, mbimcli) - QMI: QCOM MSM/Modem Interface (libqmi, qmicli) - QCDM: QCOM Modem diagnostic interface (libqcdm) - FIREHOSE: XML-based protocol for Modem firmware management (qmi-firmware-update) Note that this patch is mostly a rework of the earlier MHI UCI tentative that was a generic interface for accessing MHI bus from userspace. As suggested, this new version is WWAN specific and is dedicated to only expose channels used for controlling a modem, and for which related opensource userpace support exist. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-16net: Add a WWAN subsystemLoic Poulain
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>