Re: [PATCH net-next v3] net: Add Qcom WWAN control driver

[Greg KH]

On Tue, Mar 09, 2021 at 09:01:11AM -0700, Jeffrey Hugo wrote:
> On 3/9/2021 3:33 AM, Greg KH wrote:
> > On Tue, Mar 09, 2021 at 11:28:49AM +0100, Loic Poulain wrote:
> > > Hi Greg,
> > > 
> > > On Tue, 9 Mar 2021 at 10:35, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > 
> > > > On Tue, Mar 09, 2021 at 09:42:16AM +0100, Loic Poulain wrote:
> > > > > The MHI WWWAN control driver allows MHI Qcom based modems to expose
> > > > > different modem control protocols/ports to userspace, 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)
> > > > > 
> > > > > The different interfaces are exposed as character devices, in the same
> > > > > way as for USB modem variants (known as modem 'ports').
> > > > > 
> > > > > 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 user support exist. Other MHI channels
> > > > > not fitting the requirements will request either to be plugged to
> > > > > the right Linux subsystem (when available) or to be discussed as a
> > > > > new MHI driver (e.g AI accelerator, WiFi debug channels, etc...).
> > > > > 
> > > > > This change introduces a new drivers/net/wwan directory, aiming to
> > > > > be the common place for WWAN drivers.
> > > > > 
> > > > > Co-developed-by: Hemant Kumar <hemantk@xxxxxxxxxxxxxx>
> > > > > Signed-off-by: Hemant Kumar <hemantk@xxxxxxxxxxxxxx>
> > > > > Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxx>
> > > > > ---
> > > > >   v2: update copyright (2021)
> > > > >   v3: Move driver to dedicated drivers/net/wwan directory
> > > > > 
> > > > >   drivers/net/Kconfig              |   2 +
> > > > >   drivers/net/Makefile             |   1 +
> > > > >   drivers/net/wwan/Kconfig         |  26 ++
> > > > >   drivers/net/wwan/Makefile        |   6 +
> > > > >   drivers/net/wwan/mhi_wwan_ctrl.c | 559 +++++++++++++++++++++++++++++++++++++++
> > > > >   5 files changed, 594 insertions(+)
> > > > >   create mode 100644 drivers/net/wwan/Kconfig
> > > > >   create mode 100644 drivers/net/wwan/Makefile
> > > > >   create mode 100644 drivers/net/wwan/mhi_wwan_ctrl.c
> > > > > 
> > > > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > > > > index 1ebb4b9..28b18f2 100644
> > > > > --- a/drivers/net/Kconfig
> > > > > +++ b/drivers/net/Kconfig
> > > > > @@ -501,6 +501,8 @@ source "drivers/net/wan/Kconfig"
> > > > > 
> > > > >   source "drivers/net/ieee802154/Kconfig"
> > > > > 
> > > > > +source "drivers/net/wwan/Kconfig"
> > > > > +
> > > > >   config XEN_NETDEV_FRONTEND
> > > > >        tristate "Xen network device frontend driver"
> > > > >        depends on XEN
> > > > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> > > > > index f4990ff..5da6424 100644
> > > > > --- a/drivers/net/Makefile
> > > > > +++ b/drivers/net/Makefile
> > > > > @@ -68,6 +68,7 @@ obj-$(CONFIG_SUNGEM_PHY) += sungem_phy.o
> > > > >   obj-$(CONFIG_WAN) += wan/
> > > > >   obj-$(CONFIG_WLAN) += wireless/
> > > > >   obj-$(CONFIG_IEEE802154) += ieee802154/
> > > > > +obj-$(CONFIG_WWAN) += wwan/
> > > > > 
> > > > >   obj-$(CONFIG_VMXNET3) += vmxnet3/
> > > > >   obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o
> > > > > diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig
> > > > > new file mode 100644
> > > > > index 0000000..643aa10
> > > > > --- /dev/null
> > > > > +++ b/drivers/net/wwan/Kconfig
> > > > > @@ -0,0 +1,26 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > > > +#
> > > > > +# Wireless WAN device configuration
> > > > > +#
> > > > > +
> > > > > +menuconfig WWAN
> > > > > +       bool "Wireless WAN"
> > > > > +       help
> > > > > +         This section contains Wireless WAN driver configurations.
> > > > > +
> > > > > +if WWAN
> > > > > +
> > > > > +config MHI_WWAN_CTRL
> > > > > +     tristate "MHI WWAN control driver for QCOM based PCIe modems"
> > > > > +     depends on MHI_BUS
> > > > > +     help
> > > > > +       MHI WWAN CTRL allow 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.
> > > > > +
> > > > > +endif # WWAN
> > > > > diff --git a/drivers/net/wwan/Makefile b/drivers/net/wwan/Makefile
> > > > > new file mode 100644
> > > > > index 0000000..994a80b
> > > > > --- /dev/null
> > > > > +++ b/drivers/net/wwan/Makefile
> > > > > @@ -0,0 +1,6 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +#
> > > > > +# Makefile for the Linux WWAN device drivers.
> > > > > +#
> > > > > +
> > > > > +obj-$(CONFIG_MHI_WWAN_CTRL) += mhi_wwan_ctrl.o
> > > > > diff --git a/drivers/net/wwan/mhi_wwan_ctrl.c b/drivers/net/wwan/mhi_wwan_ctrl.c
> > > > > new file mode 100644
> > > > > index 0000000..3904cd0
> > > > > --- /dev/null
> > > > > +++ b/drivers/net/wwan/mhi_wwan_ctrl.c
> > > > > @@ -0,0 +1,559 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > +/* Copyright (c) 2018-2021, The Linux Foundation. All rights reserved.*/
> > > > > +
> > > > > +#include <linux/kernel.h>
> > > > > +#include <linux/mhi.h>
> > > > > +#include <linux/mod_devicetable.h>
> > > > > +#include <linux/module.h>
> > > > > +#include <linux/poll.h>
> > > > > +
> > > > > +#define MHI_WWAN_CTRL_DRIVER_NAME "mhi_wwan_ctrl"
> > > > 
> > > > So a driver name is the same as the class that is being created?
> > > > 
> > > > That feels wrong, shouldn't the "class" be wwan?
> > > 
> > > The driver does not aim to be THE wwan implementation, given the
> > > heterogeneity of WWAN interfaces, so 'wwan' is probably too generic
> > > for this bus/vendor specific driver. But since we create a new wwan
> > > subdir, maybe we should create a minimal wwan_sysfs.c, that would
> > > initially just offer a common class for all WWAN devices (wwan or
> > > wwan-ports), as a first step to if not standardize, at least group
> > > such devices under the same hat. Otherwise, we can just use the misc
> > > class... Any thoughts?
> > 
> > Why isn't this a good api for all wwan devices?  Do you think that this
> > will not work for others?
> > 
> > A common class would be good, if they all work the same with regards to
> > a user/kernel api, otherwise it's pointless and not needed :)
> > 
> > And if we are back to the "custom user/kernel api just for this one
> > driver", then yes, the misc api is the easiest and simplest to use, but
> > I would wish for better than that for the first wwan driver...
> 
> I'm thinking this doesn't fit with the misc api due to the number of device
> minors that could be expected to be consumed.

That's why I asked how many minors do you need :)

> Each device supported by this driver is going to create 2-5 chardevs. Having
> two devices in a system is common for "endusers".  Development,
> manufacturing, and test (including the community, not just talking Qualcomm
> here) commonly have 12+ of these devices in a system.  12 * 5 = 60.  Thats a
> lot of misc minor numbers to chew up just from one driver given that the
> limit of dynamic minors is 128.  Looking at a random x86 server that I have
> which could be used for such a usecase already has 30 misc minor numbers
> used, and this particular server has a fresh distro install on it.  I would
> expect that number to go up as it gets provisioned for use.

Look at a phone these days, I see way more misc devices used than just
"30" :(

> I guess, the question to you is, how many misc minor numbers is "too much"
> for a single driver to expect to consume?

If you expect more than 10, I would say to use a real major number.  But
be explicit as to what you are expecting here, it was not obvious at
all.

thanks,

greg k-h