[RFC] No multiplexing by default in MM 1.18

[Reinhard Speyerer]

Hi Aleksander, hi Daniele,

On Tue, Aug 03, 2021 at 12:23:37PM +0200, Daniele Palmas wrote:
> Hi Aleksander,
> 
> Il giorno lun 2 ago 2021 alle ore 16:41 Aleksander Morgado <
> aleksander at aleksander.es> ha scritto:
> 
> > Hey all,
> >
> > I've been testing with all my modems for the next 1.18 release, and
> > for the QMI and MBIM ones I've done tests with and without
> > multiplexing support (i.e. connecting normally as we did until now,
> > and also connecting with multiplexing enabled).
> >
> > All the QMI modems I have tested with have worked fine. If QMAP wasn't
> > supported by the modem and we were requesting multiplexing, it would
> > automatically just fallback to no multiplexing (802.3 or plain
> > raw-ip), and that was it.
> >
> > Most of the MBIM modems I have tested with have worked fine as well,
> > with the exception of the Netgear AC340U, which would reply with
> > "InvalidParameters" if we were attempting to connect any session with
> > id != 0. All the other modems have been able to correctly setup
> > multiplexing when requested without issues.
> >
> > Even if the tests have been quite satisfactory overall (I've tested
> > >60 different modems in the past month), I think that for 1.18 we
> > should not enable multiplexing by default (except for IPA), and still
> > leave it as a requirement from the user at connect time. So, if the
> > user wants to setup a connection with multiplexing enabled, it should
> > pass either "multiplex=requested" or "multiplex=required" in the
> > connection settings explicitly
> >
> >
> I think it makes sense.
> 

I too think it makes sense to not enable multiplexing by default at
this point in time.

Since commit 44f82312fe91 ("qmi_wwan: add network device usage statistics
for qmimux devices") of my "qmi_wwan: fix QMAP handling" series
https://lore.kernel.org/netdev/cover.1560287477.git.rspmn@arcor.de
was not backported to 4.14.x and 4.19.x longterm kernels by Sasha Levin's
"AUTOSEL" patches this would introduce a regression for users of those
kernel versions with MM 1.18 otherwise.

The reason for this is probably that it violates the "It cannot be bigger
than 100 lines, with context." rule from
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html .

Perhaps it would make sense to split up the patch into two parts if required
to meet formal criteria and submit it for 4.14.y and 4.19.y kernels so
that users don't have to resort to building qmi_wwan.ko from out-of-tree
drivers like https://forum.sierrawireless.com/t/rc7620-and-linux-driver/24308
to avoid the regression?

Regards,
Reinhard