Date:   Sun, 26 Nov 2017 16:16:31 +0100
From:   Reinhard Speyerer <rspmn@...or.de>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     netdev@...r.kernel.org, oliver.graute@...il.com
Subject: Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8

On Fri, Nov 24, 2017 at 07:25:19PM +0100, Bjørn Mork wrote:
> Reinhard Speyerer <rspmn@...or.de> writes:
> 
> > before posting this problem report
> > https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017
> > in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes
> > you suggested above and apart from having two working QMI interfaces
> > the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were
> > also gone when using WDSStartNetworkInterface and the QMI interface in
> > raw IP mode instead.
> 
> Right. I did not know about the "carrier off" issue. But messed up
> ethernet headers is a well known problem with all these Qualcomm based
> modems. Switching them to raw IP mode is often the only way to make them
> work consistently.
> 
> Having seen this problem with multiple vendors, where some even have
> borrowed our workarounds for their own out-of-tree drivers, makes me
> pretty sure that it isn't easily fixable. It's a Qualcomm bug, and I
> guess no one is allowed to even look at the code.  Much less change it.
> Which makes sense given the mess it must be...
> 
> > Unfortunately Gemalto does no seems to be willing to provide an
> > alternative USB composition which includes QMI interfaces for the
> > PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might
> > make the PLS8 network interfaces stop working when Gemalto decides to
> > replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when
> > releasing a firmware update.
> 
> I don't think this is necessarily a problem. Only the QMI control
> channel will stop working should this happen.  The qmi_wwan driver will
> provide the same network device support as cdc_ether, using CDC ECM
> framing.
> 
> And to be honest, such a redesign of the modem application for a mature
> product is very unlikely, isn't it?  Why would Gemalto want to do all
> that extra work, taking the risks involved?  For what possible purpose?
> This is probably the reason they don't want to mess with alternative USB
> compositions either.
> 
> In any case, I think it is worth adding this device to qmi_wwan if it
> works with current firmwares and you, or anyone else, finds it useful.
> And it does sound like that based on the IPv6 issues you mention..
> 
> But I'll leave the decision to you or anyone else with such a device.

Hi Bjørn,

given that the PLS8 USB PID 0x0061 is also used by firmware version
02.x which has been relased quite some time ago I'm afraid switching
it from cdc_ether to qmi_wwan in the mainline Linux kernel now might
break too many existing/working setups even if only for the changed
interface name.

Since Gemalto also seems to have moved away from supporting USB
compositions with a QMI interface with newer firmware versions in
general they might as well reserve the right to reject problem reports
submitted to them when not using their AT^SWWAN/CDCECM setup.

Therefore I will not submit patches which switch PLS8 with USB PID
0x0061 from the cdc_ether to the qmi_wwan driver. If there are other
PLS8 users who don't share my concerns: please feel free to submit the
patches yourself.

Let's hope that Gemalto is able to fix the AT^SWWAN/CDCECM-specific
IPv6/dualstack problems in their forthcoming PLS8 firmware version 04.x
or provides an alternative USB composition if the effort for fixing the
bugs would be too high.

Regards,
Reinhard

Powered by blists - more mailing lists