[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMZdPi82NpijmiAd2-Fku5ZzcrpZpDsi-8h9qgAu=Xz6VWVQhQ@mail.gmail.com>
Date: Thu, 11 Mar 2021 18:14:45 +0100
From: Loic Poulain <loic.poulain@...aro.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Jakub Kicinski <kuba@...nel.org>,
David Miller <davem@...emloft.net>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Aleksander Morgado <aleksander@...ksander.es>,
open list <linux-kernel@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Hemant Kumar <hemantk@...eaurora.org>,
Jeffrey Hugo <jhugo@...eaurora.org>
Subject: Re: [PATCH net-next v4 1/2] net: Add a WWAN subsystem
On Thu, 11 Mar 2021 at 17:48, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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?
Yes sorry, I've overwritten my changelog with my last format-patch,
going to address your comment and add that in the next series.
Regards,
Loic
Powered by blists - more mailing lists