Hi Johan, 2015-11-13 11:58 GMT+01:00 Johan Hovold <johan@xxxxxxxxxx>: > On Thu, Nov 12, 2015 at 02:55:04PM +0100, Bjørn Mork wrote: >> Daniele Palmas <dnlplm@xxxxxxxxx> writes: > >> > But I see that Infineon flashing devices in newer chipsets have become >> > an only bulk serial link device (see device 0x8087/0x0716 in >> > usb-serial-simple), so maybe this has a meaning... >> >> Yes. I have a Sierra Wireless EM7345 modem which is based on the same >> chipset. I haven't really paid much attemtion to the flashloader >> functionality before, but this is how that modem looks before it loads >> its Sierra firmware: > >> So this device looks very much like an ACM device, except that it is >> missing the necessary control interface and status endpoint. And >> without a control interface there is of course no way to send a properly >> formatted CDC control request either. >> >> I assume the different vendors also use the same Intel provided firmware >> toolkit, making the firmwares share basic functionality like bootloader >> and flashing. But the USB descriptors are likely configurable by the >> vendor. Telit might have tried to "improve" the above into a proper ACM >> device. >> >> I believe this supports the assumption that Infineon Flash Loader >> devices have some ACM descriptors without actually being ACM class >> devices, and that it is best to just collect them all in the >> usb-serial-simple "flashloader" driver. > > I'm still not convinced. The device at hand does look and apparently > behaves like a compliant ACM device, and I think we need to figure out > why it does not work with this particular proprietary user-space tool > before modifying the kernel. > > For example, using usb-serial-simple means that no line-control requests > are sent. Perhaps the tool simply needs to set the termios settings to > something else than the default 9600N81 that the cdc-acm driver uses. > > Modem control-requests would not be sent either (and HUPCL determines if > DTR/RTS is lowered at close). > > Daniele, could you provide some more details about what happens when the > proprietary tool fails. Do you have access to the sources? I'll try to explain how the whole thing should work. This is what happens when the device is turned on (without modifying the drivers): [155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci [155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 255, changing to 11 [155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041 [155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device This is the flashing device that is caught by the cdc-acm driver. Once the ttyACM appears, the application starts sending a magic string (simple write on the file descriptor) to keep the device in flashing mode. If this magic string is not properly received in a certain time interval, the modem goes on in normal operative mode: [155493.748094] usb 1-3: USB disconnect, device number 27 [155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci [155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021 [155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM [155495.059989] usb 1-3: Manufacturer: Telit [155495.059992] usb 1-3: SerialNumber: 359658044004697 [155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device [155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device [155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device [155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device [155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device [155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device [155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at usb-0000:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14 Using the cdc-acm driver, the string, though being sent in the same way than using the usb-serial-simple driver (I can confirm that the data is passing properly since I used an hw usb sniffer), does not make the device to stay in flashing mode. I thought that the problem was something done by the acm driver when opening the port that is not accepted well by the flashing device on the firmware side, so I tried also in the past to debug the driver, but without success. I can start again to understand which is really the problem with cdc-acm, but my fear is that to have a working solution with cdc-acm will be more complicated (e.g. adding a new quirk) than adding support in the usb-serial-simple driver. Consider also that this is not really a communication device with subclass modem, as wrongly stated by the usb descriptors, since it is simply a flashing device. Another interesting piece of the puzzle is that in Windows this device requires a specific flashloader driver and does not use the acm driver suggested by the vendor. > > Johan Thanks, Daniele -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
