1. 01 4月, 2017 1 次提交
  2. 23 3月, 2017 1 次提交
  3. 02 3月, 2017 1 次提交
  4. 27 1月, 2017 1 次提交
    • J
      USB: cdc-acm: fix TIOCGSERIAL flags · 4ddecf76
      Johan Hovold 提交于
      The driver reports that it always uses a low-latency mode by returning
      the ASYNC_LOW_LATENCY flag through TIOCGSERIAL.
      
      Even if this behaviour could not be changed, this may have made some
      sense prior to 7a9a65ce ("cdc-acm: Fix long standing abuse of
      tty->low_latency") which removed the unconditional setting of the
      corresponding tty low_latency flag (something which had always been
      broken in itself).
      
      Since the driver does not have a low-latency mode, let's drop the flag.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ddecf76
  5. 05 12月, 2016 1 次提交
  6. 21 11月, 2016 6 次提交
  7. 10 11月, 2016 3 次提交
  8. 07 11月, 2016 1 次提交
  9. 21 9月, 2016 1 次提交
  10. 13 9月, 2016 2 次提交
  11. 09 9月, 2016 1 次提交
  12. 15 8月, 2016 1 次提交
  13. 18 7月, 2016 3 次提交
  14. 08 6月, 2016 1 次提交
  15. 01 5月, 2016 1 次提交
  16. 14 4月, 2016 1 次提交
  17. 19 3月, 2016 1 次提交
  18. 15 2月, 2016 1 次提交
  19. 25 1月, 2016 3 次提交
  20. 23 11月, 2015 1 次提交
    • J
      USB: cdc_acm: Ignore Infineon Flash Loader utility · f33a7f72
      Jonas Jonsson 提交于
      Some modems, such as the Telit UE910, are using an Infineon Flash Loader
      utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
      Data). The latter can be used as a serial interface to upgrade the
      firmware of the modem. However, that isn't possible when the cdc-acm
      driver takes control of the device.
      
      The following is an explanation of the behaviour by Daniele Palmas during
      discussion on linux-usb.
      
      "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."
      Signed-off-by: NJonas Jonsson <jonas@ludd.ltu.se>
      Tested-by: NDaniele Palmas <dnlplm@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      f33a7f72
  21. 23 7月, 2015 1 次提交
    • J
      cdc-acm: Destroy acm_minors IDR on module exit · 91b72560
      Johannes Thumshirn 提交于
      Destroy acm_minors IDR on module exit, reclaiming the allocated memory.
      
      This was detected by the following semantic patch (written by Luis Rodriguez
      <mcgrof@suse.com>)
      <SmPL>
      @ defines_module_init @
      declarer name module_init, module_exit;
      declarer name DEFINE_IDR;
      identifier init;
      @@
      
      module_init(init);
      
      @ defines_module_exit @
      identifier exit;
      @@
      
      module_exit(exit);
      
      @ declares_idr depends on defines_module_init && defines_module_exit @
      identifier idr;
      @@
      
      DEFINE_IDR(idr);
      
      @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       idr_destroy(&idr);
       ...
      }
      
      @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       +idr_destroy(&idr);
       }
      </SmPL>
      Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Acked-by: NOliver Neukum <oneukum@suse.com>
      Acked-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91b72560
  22. 09 6月, 2015 1 次提交
  23. 25 5月, 2015 2 次提交
  24. 28 4月, 2015 1 次提交
    • Q
      cdc-acm: prevent infinite loop when parsing CDC headers. · 0d3bba02
      Quentin Casasnovas 提交于
      Phil and I found out a problem with commit:
      
        7e860a6e ("cdc-acm: add sanity checks")
      
      It added some sanity checks to ignore potential garbage in CDC headers but
      also introduced a potential infinite loop.  This can happen at the first
      loop iteration (elength = 0 in that case) if the description isn't a
      DT_CS_INTERFACE or later if 'buffer[0]' is zero.
      
      It should also be noted that the wrong length was being added to 'buffer'
      in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was
      assigned after that check in the loop.
      
      A specially crafted USB device could be used to trigger this infinite loop.
      
      Fixes: 7e860a6e ("cdc-acm: add sanity checks")
      Signed-off-by: NPhil Turnbull <phil.turnbull@oracle.com>
      Signed-off-by: NQuentin Casasnovas <quentin.casasnovas@oracle.com>
      CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      CC: Oliver Neukum <oneukum@suse.de>
      CC: Adam Lee <adam8157@gmail.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d3bba02
  25. 26 3月, 2015 3 次提交