From: "Bjørn Mork" <bjorn@mork•no>
To: Reinhard Speyerer <rspmn@arcor•de>
Cc: netdev@vger•kernel.org, oliver.graute@gmail•com
Subject: Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8
Date: Fri, 24 Nov 2017 19:25:19 +0100 [thread overview]
Message-ID: <87mv3bilf4.fsf@miraculix.mork.no> (raw)
In-Reply-To: <20171123230617.6e4lc6b4qjgaqbc6@arcor.de> (Reinhard Speyerer's message of "Fri, 24 Nov 2017 00:06:18 +0100")
Reinhard Speyerer <rspmn@arcor•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.
Bjørn
next prev parent reply other threads:[~2017-11-24 18:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 13:37 [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 Oliver Graute
2017-11-23 14:03 ` Bjørn Mork
2017-11-23 15:10 ` Oliver Graute
2017-11-23 18:15 ` Bjørn Mork
2017-11-23 23:06 ` Reinhard Speyerer
2017-11-24 12:04 ` Oliver Graute
2017-11-24 18:25 ` Bjørn Mork [this message]
2017-11-26 15:16 ` Reinhard Speyerer
2017-11-24 12:02 ` Oliver Graute
2017-12-01 12:20 ` Oliver Graute
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv3bilf4.fsf@miraculix.mork.no \
--to=bjorn@mork$(echo .)no \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oliver.graute@gmail$(echo .)com \
--cc=rspmn@arcor$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox