Fwd: K5150 - revisted

Bjørn Mork bjorn at mork.no
Mon Mar 9 02:36:33 PDT 2015


>> From: Markus Gothe <nietzsche at lysator.liu.se>
>> Subject: K5150 - revisted
>> Date: 6 Mar 2015 16:32:48 GMT+1
>> To: "libqmi (development)" <libqmi-devel at lists.freedesktop.org>
>> 
>> With this variant, https://code.google.com/p/wl500g/source/browse/trunk/kernel-2.6/273-usb-cdc_ncm.patch?spec=svn4960&r=4960, of cdc_ncm.c the K5150 works good.
>> 
>> However with https://code.google.com/p/wl500g/source/browse/trunk/kernel-2.6/273-usb-cdc_ncm.patch?spec=svn5650&r=5513 I am unable to set NTH16-mode for the K5150. Which is very weird. For a simpler MBIM device this file version works good.
>> 
>> Any clues?

See

commit ff0992e9036e9810e7cd45234fa32ca1e79750e2
Author: Bjørn Mork <bjorn at mork.no>
Date:   Mon Mar 17 16:25:18 2014 +0100

    net: cdc_ncm: fix control message ordering
    
    This is a context modified revert of commit 6a9612e2cb22
    ("net: cdc_ncm: remove ncm_parm field") which introduced
    a NCM specification violation, causing setup errors for
    some devices. These errors resulted in the device and
    host disagreeing about shared settings, with complete
    failure to communicate as the end result.
    
    The NCM specification require that many of the NCM specific
    control reuests are sent only while the NCM Data Interface
    is in alternate setting 0. Reverting the commit ensures that
    we follow this requirement.
    
    Fixes: 6a9612e2cb22 ("net: cdc_ncm: remove ncm_parm field")
    Reported-and-tested-by: Pasi Kärkkäinen <pasik at iki.fi>
    Reported-by: Thomas Schäfer <tschaefer at t-online.de>
    Signed-off-by: Bjørn Mork <bjorn at mork.no>
    Signed-off-by: David S. Miller <davem at davemloft.net>



According to the NCM spec, the "set NTH16-mode" message is only valid
*before* we do

  temp = usb_set_interface(dev->udev, iface_no, data_altsetting);

But many devices will accept it anyway.  Which is why I didn't notice
introducing this bug while reordering the bind/setup code.  All my
modems will work either way, but I got many reports of Huawei modems
failing due to this driver bug.

Looks like you've backported a buggy version of the driver...



Bjørn


More information about the libmbim-devel mailing list