"Wassenberg, Dennis" <dennis.wassenb...@secunet.com> writes:
> After that dmesg shows this: > [ 930.843781] usb 1-7: new high-speed USB device number 16 using xhci_hcd > [ 930.996572] usb 1-7: New USB device found, idVendor=8087, idProduct=07f5, > bcdDevice= 0.00 > [ 930.996577] usb 1-7: New USB device strings: Mfr=0, Product=0, > SerialNumber=0 > [ 937.683939] usb 1-7: USB disconnect, device number 16 > > So, in general I think there should be USB lines routed to the M.2 slot but I > have no idea why the device leaves the > bus. It is possible to run the script again and again but in the end it will > always disconnect automatically. I know nothing about these modems, but my guess is that this is a bootloader mode. Mostly based on the assumption that there will be one, and that the vendor-id will be something non-Intel in application mode. You can probably confirm this by capturing the full device descriptor, e.g by creating a udev rule to dump it or simply by snooping on the bus. If this assumption is correct, then the firmware was supposed to boot into an application mode and then reconnect to the USB bus with its real device ID and descriptors. This could be failing due to a firmware crash, maybe caused by this unexpected state. Or more likely: The firmware on this modem is built without support for the USB mode. Do you have any confirmation that it is actually possible to switch this firmware into USB mode? Are there other firmwares available with (possible) USB support? Anyway, FWIW, I'd explore the PCIe driver option first if I were you. That's the only mode tested by anyone, so it is more likely to work. Bjørn _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
