Problem with AirCard 340U on embedded Linux

[Aleksander Morgado]

On Tue, Aug 16, 2016 at 7:26 PM, Evade Flow <evadeflow at gmail.com> wrote:
> On a slightly different subject, I wonder if I could trouble you to
> comment on which of the patches you mention in this post:
>
>   -
> https://lists.freedesktop.org/archives/libqmi-devel/2015-December/001477.html
>
> would be beneficial to include on an embedded device running kernel
> version 4.1.13 with a Sierra Wireless AC 340U?
>
>> 34a55d5 net: qmi_wwan: ignore bogus CDC Union descriptors
>> 6c73008 net: qmi_wwan: should hold RTNL while changing netdev type
>> 32f7adf net: qmi_wwan: support "raw IP" mode
>> 81e0ce7 usbnet: allow mini-drivers to consume L2 headers
>> 544c8f6 net: qmi_wwan: remove 1199:9070 device id
>> 9372514 net: qmi_wwan: MDM9x30 specific power management
>> 68242a5 net: qmi_wwan: add XS Stick W100-2 from 4G Systems
>> b3d8cf0 USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe module
>> 7091079 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module
>> 0db65fc qmi_wwan: add Sierra Wireless MC74xx/EM74xx
>> e704059 net: qmi_wwan: Sierra Wireless MC73xx -> Sierra Wireless
>> MC7304/MC7354
>
> I applied all of them (in desperation, to be honest) to see if they
> might fix my problem. Since it turns out to have been something
> unrelated, I reverted them all. And I *am* still able to connect; but I
> noticed at least one difference. This command no longer works:
>
> root at embedded-dev $ qmicli -d /dev/cdc-wdm0 --get-expected-data-format
> error: couldn't create QmiDevice: Couldn't query file info: Error when
> getting information for file '/dev/cdc-wdm0': No such file or directory
>
> Since I can still connect, anyway, I'm wondering whether I should bother
> with any patches. It's easy enough to include them, I'm just worried I
> don't have the expertise to vet them properly. If you have a minute, and
> can say off the top of your head, I'd be very interested to know your
> opinion.

If you're going to stick to forcing 802-3 LLP in your device using the
--wda-set-data-format, I think you can ignore all those patches.

The "--get-expected-data-format" command will only work if your kernel
has raw-ip support (32f7adf, which you had cherry-picked already).
Which takes me to the next question, which is, why did qmi-network not
work for you before you cherry-picked those patches? If qmi-network
detects an error in "--get-expected-data-format", it should default to
the old behavior of defaulting to 802-3 with WDA...

-- 
Aleksander
https://aleksander.es