On Thu, 2017-06-08 at 23:05 +0200, Dominik Strnad wrote: > Hi Aleksander, > > thank you.... > > On Thu, Jun 8, 2017 at 10:56 PM, Aleksander Morgado < > [email protected]> wrote: > > > Hey, > > > > > > > > so my card is not listed in rfkill at all: > > > > > > litin@x220:~$ rfkill list all > > > 0: hci0: Bluetooth > > > Soft blocked: no > > > Hard blocked: no > > > 1: tpacpi_bluetooth_sw: Bluetooth > > > Soft blocked: no > > > Hard blocked: no > > > 2: phy0: Wireless LAN > > > Soft blocked: no > > > Hard blocked: no > > > > > > And I have no idea why.... So I would not say that card is > > > blocked by > > > rfkill, because it seem to be not registered to rfkill at > > > all...the fun > > > > is, > > > > Hum, ok... no idea :/ > > > > I read something about rfkill and to me it seems qmi driver should > register > itself to rfkill / kernel...
The QMI driver should not actually register itself with rfkill, since it doesn't actually have anything to do with rfkill. rfkill for most devices is currently handled by platform drivers that read state from the BIOS, which is what usually twiddles the hardware W_DISABLE pins. If there is no platform BIOS driver (eg, tpacpi_wwan_sw) or that driver doesn't have correct IDs for your laptop, then that platform driver needs to be fixed. It may also be the case that your modified whitelisted BIOS is incompletely modified and the whitelist addition is only to allow the bootup to proceed, but does not allow correct rfkill handling of the device. qmi_wwan is a simple conduit that just lets a process speak QMI to a device. It doesn't have any idea what is actually being spoken, so it doesn't know about any of the device's state like whether it's in LPM or not. For "soft" LPM, eg "CFUN=4" or the QMI equivalent, that is all done at the protocol level (and thus not in the kernel) and is handled by stuff in userspace like ModemManager or another daemon that reads that state using AT, QMI, MIBM, etc and exposes it somehow (like dbus). Dan > > > > > > that it seem to be registered twice in kernel: > > > > > > litin@x220:~$ dmesg | grep qmi > > > [ 3.247730] qmi_wwan 2-1.4:1.8: cdc-wdm0: USB WDM device > > > [ 3.262419] qmi_wwan 2-1.4:1.8 wwan0: register 'qmi_wwan' at > > > usb-0000:00:1d.0-1.4, WWAN/QMI device, 86:43:0f:24:2c:93 > > > [ 3.267585] qmi_wwan 2-1.4:1.10: cdc-wdm1: USB WDM device > > > [ 3.268927] qmi_wwan 2-1.4:1.10 wwan1: register 'qmi_wwan' at > > > usb-0000:00:1d.0-1.4, WWAN/QMI device, 86:43:0f:24:2c:93 > > > [ 3.269028] usbcore: registered new interface driver qmi_wwan > > > [ 3.695620] qmi_wwan 2-1.4:1.10 wwp0s29u1u4i10: renamed from > > > wwan1 > > > [ 3.734681] qmi_wwan 2-1.4:1.8 wwp0s29u1u4i8: renamed from > > > wwan0 > > > > > > > That is normal; the modem is exposing two QMI+WWAN pairs, one from > > if#8 and another one from if#10. > > > > Ok, thanks for explanation. > > > > > > > > > litin@x220:~$ lsusb > > > Bus 002 Device 003: ID 1199:9071 Sierra Wireless, Inc. > > > Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate > > > Matching Hub > > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > Bus 001 Device 006: ID 04f2:b217 Chicony Electronics Co., Ltd > > > Lenovo > > > > > > And that: Couldn't open device, some information will be missing > > > seems > > > > to be > > > intriguing. > > > > > > > You should have run it as root :) > > > > > Yes sorry, you are completely right.... > > litin@x220:~$ sudo lsusb -v > [sudo] password for litin: > > Bus 002 Device 003: ID 1199:9071 Sierra Wireless, Inc. > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x1199 Sierra Wireless, Inc. > idProduct 0x9071 > bcdDevice 0.06 > iManufacturer 1 Sierra Wireless, Incorporated > iProduct 2 Sierra Wireless MC7455 Qualcomm® > Snapdragon™ X7 > LTE-A > iSerial 3 LQ71474124021020 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 190 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xa0 > (Bus Powered) > Remote Wakeup > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 00 > ** UNRECOGNIZED: 04 24 02 02 > ** UNRECOGNIZED: 05 24 06 00 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x000a 1x 10 bytes > bInterval 9 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 00 > ** UNRECOGNIZED: 04 24 02 02 > ** UNRECOGNIZED: 05 24 06 00 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x000a 1x 10 bytes > bInterval 9 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 8 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x87 EP 7 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 9 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x86 EP 6 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x04 EP 4 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 10 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x89 EP 9 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 9 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x88 EP 8 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x05 EP 5 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Binary Object Store Descriptor: > bLength 5 > bDescriptorType 15 > wTotalLength 12 > bNumDeviceCaps 1 > USB 2.0 Extension Device Capability: > bLength 7 > bDescriptorType 16 > bDevCapabilityType 2 > bmAttributes 0x00000000 > (Missing must-be-set LPM bit!) > Device Status: 0x0000 > (Bus Powered) > > > > > Actually I have no idea how to continue at all. Do you think it will > be > please possible for you to update PPA with MM 1.6.6 so I can try it? > Thank > you. > > BR > Dominik > _______________________________________________ > ModemManager-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
