I don't think that this device is triggered by any udev rule, so usb_modeswitch won't be triggered

grep 03f0 40-usb_modeswitch.rules *
40-usb_modeswitch.rules:ATTR{idVendor}=="03f0", ATTR{idProduct}=="002a", RUN+="usb_modeswitch '%b/%k'" 40-usb_modeswitch.rules:ATTR{idVendor}=="03f0", ATTR{idProduct}=="002a", RUN+="usb_modeswitch '%b/%k'" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="271d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="261d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3a1d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3d1d", ENV{.MM_USBIFNUM}=="09", ENV{ID_MM_ERICSSON_MBM_GPS_PORT}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3d1d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="301d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-ericsson-mbm.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="2f1d", ENV{ID_MM_ERICSSON_MBM}="1" 77-mm-fix-unexpected.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="9d1d", RUN+="fix-unexpected" 77-mm-usb-device-blacklist.rules:ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="1f0a", ENV{ID_MM_DEVICE_IGNORE}="1"

Would it help to revert the option patch?

On 19.09.2016 23:02, Dan Williams wrote:
On Mon, 2016-09-19 at 22:06 +0200, Harald Jung wrote:
At this point i have no idea why cdc_mbim doen't grab the device.
Just that it is loaded but i think it is just loaded by cdc_ncm
Check usb_modeswitch/usb_modeswitch_dispatcher.  If you move them out
of the way, does that help?  Older versions (like 2.4 and earlier) than
the most recently released one would force-bind interfaces to some
drivers which could interfere with kernel device matching.

I just had this issue today for a Franklin U600 which should use cdc-
acm on interfaces 0 & 1 and qcaux on 2-5.  But the presence of
/usr/sbin/usb_modeswitch_dispatcher prevented cdc-acm from binding.
  moving it out of the way fixed the issue, as would (I presume)
updating my usb_modeswitch version.


On 19.09.2016 22:03, Bjørn Mork wrote:
Harald Jung <harald.j...@ecos.de> writes:

echo "03f0 521d" > /sys/bus/usb/drivers/cdc_mbim/new_id
had no effect
And it should not.  The driver will match the MBIM class.

usb 1-3: GSM modem (1-port) converter now attached to ttyUSB0
usbcore: registered new interface driver cdc_ncm
usbcore: registered new interface driver cdc_wdm
usbcore: registered new interface driver cdc_mbim

T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=03f0 ProdID=521d Rev=00.01
S:  Manufacturer=Hewlett-Packard
S:  Product=HP hs3110 HSPA+ Mobile Broadband Device
C:  #Ifs= 3 Cfg#= 2 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05
The cdc_mbim driver should at least try to bind to the two first
interfaces.  Don't you see any other messages from it in the log?

ModemManager-devel mailing list

ModemManager-devel mailing list

Reply via email to