[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YEpJwsSy52HFB/IY@kroah.com>
Date: Thu, 11 Mar 2021 17:48:02 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Loic Poulain <loic.poulain@...aro.org>
Cc: kuba@...nel.org, davem@...emloft.net,
linux-arm-msm@...r.kernel.org, aleksander@...ksander.es,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
bjorn.andersson@...aro.org, manivannan.sadhasivam@...aro.org,
hemantk@...eaurora.org, jhugo@...eaurora.org
Subject: Re: [PATCH net-next v4 1/2] net: Add a WWAN subsystem
On Thu, Mar 11, 2021 at 05:39:05PM +0100, Loic Poulain wrote:
> This change introduces initial support for a WWAN subsystem. 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 components/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 that as character devices, and
> user daemons such as ModemManager learnt how to deal with that. This
> initial version adds the concept of WWAN port, which can be registered
> by any driver to expose one of these protocols. The WWAN core takes
> care of the generic part, including character device creation and lets
> the driver implementing access (fops) to the selected protocol.
>
> Since the different components/devices do no necesserarly know about
> each others, and can be created/removed in different orders, the
> WWAN core ensures that devices being part of the same hardware are
> also represented as a unique 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@...aro.org>
> ---
> drivers/net/Kconfig | 2 +
> drivers/net/Makefile | 1 +
> drivers/net/wwan/Kconfig | 19 ++++++
> drivers/net/wwan/Makefile | 8 +++
> drivers/net/wwan/wwan_core.c | 150 +++++++++++++++++++++++++++++++++++++++++++
> drivers/net/wwan/wwan_core.h | 20 ++++++
> drivers/net/wwan/wwan_port.c | 136 +++++++++++++++++++++++++++++++++++++++
> include/linux/wwan.h | 121 ++++++++++++++++++++++++++++++++++
> 8 files changed, 457 insertions(+)
> create mode 100644 drivers/net/wwan/Kconfig
> create mode 100644 drivers/net/wwan/Makefile
> create mode 100644 drivers/net/wwan/wwan_core.c
> create mode 100644 drivers/net/wwan/wwan_core.h
> create mode 100644 drivers/net/wwan/wwan_port.c
> create mode 100644 include/linux/wwan.h
What changed from the last version(s)? That should be below the ---
somewhere, right?
v5?
thanks,
greg k-h
Powered by blists - more mailing lists