1. 15 Mar, 2012 4 commits
  2. 14 Mar, 2012 2 commits
    • Jim Paris's avatar
      USB: ftdi_sio: add support for FT-X series devices · dc0827c1
      Jim Paris authored
      Add PID 0x6015, corresponding to the new series of FT-X chips
      (FT220XD, FT201X, FT220X, FT221X, FT230X, FT231X, FT240X).  They all
      appear as serial devices, and seem indistinguishable except for the
      default product string stored in their EEPROM.  The baudrate
      generation matches FT232RL devices.
      
      Tested with a FT201X and FT230X at various baudrates (100 - 3000000).
      
      Sample dmesg:
          ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
          usb 2-1: new full-speed USB device number 6 using ohci_hcd
          usb 2-1: New USB device found, idVendor=0403, idProduct=6015
          usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
          usb 2-1: Product: FT230X USB Half UART
          usb 2-1: Manufacturer: FTDI
          usb 2-1: SerialNumber: DC001WI6
          ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
          drivers/usb/serial/ftdi_sio.c: ftdi_sio_port_probe
          drivers/usb/serial/ftdi_sio.c: ftdi_determine_type: bcdDevice = 0x1000, bNumInterfaces = 1
          usb 2-1: Detected FT-X
          usb 2-1: Number of endpoints 2
          usb 2-1: Endpoint 1 MaxPacketSize 64
          usb 2-1: Endpoint 2 MaxPacketSize 64
          usb 2-1: Setting MaxPacketSize 64
          drivers/usb/serial/ftdi_sio.c: read_latency_timer
          drivers/usb/serial/ftdi_sio.c: write_latency_timer: setting latency timer = 1
          drivers/usb/serial/ftdi_sio.c: create_sysfs_attrs
          drivers/usb/serial/ftdi_sio.c: sysfs attributes for FT-X
          usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
      Signed-off-by: default avatarJim Paris <jim@jtan.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc0827c1
    • Donald Lee's avatar
      USB: serial: mos7840: Fixed MCS7820 device attach problem · 093ea2d3
      Donald Lee authored
      A MCS7820 device supports two serial ports and a MCS7840 device supports
      four serial ports. Both devices use the same driver, but the attach function
      in driver was unable to correctly handle the port numbers for MCS7820
      device. This problem has been fixed in this patch and this fix has been
      verified on x86 Linux kernel 3.2.9 with both MCS7820 and MCS7840 devices.
      Signed-off-by: default avatarDonald Lee <donald@asix.com.tw>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      093ea2d3
  3. 13 Mar, 2012 19 commits
  4. 12 Mar, 2012 4 commits
  5. 10 Mar, 2012 6 commits
  6. 09 Mar, 2012 5 commits
    • Hugh Dickins's avatar
      memcg: revert fix to mapcount check for this release · be22aece
      Hugh Dickins authored
      Respectfully revert commit e6ca7b89 "memcg: fix mapcount check
      in move charge code for anonymous page" for the 3.3 release, so that
      it behaves exactly like releases 2.6.35 through 3.2 in this respect.
      
      Horiguchi-san's commit is correct in itself, 1 makes much more sense
      than 2 in that check; but it does not go far enough - swapcount
      should be considered too - if we really want such a check at all.
      
      We appear to have reached agreement now, and expect that 3.4 will
      remove the mapcount check, but had better not make 3.3 different.
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      be22aece
    • Bjørn Mork's avatar
      net: qmi_wwan: add Gobi and Pantech UML290 device IDs · b086cf04
      Bjørn Mork authored
      Adding the Pantech UML290 and all non-QDL Gobi device IDs from the
      qcserial driver now that we have support for shared net/QMI USB
      interfaces.  Most of these are not yet tested with this driver, but
      should be mostly identical to tested devices, except for device IDs.
      
      Gobi devices provide several different interfaces (serial/net/other)
      using the exact same class, subclass and protocol values.  This driver
      will only support the net/QMI function while there are other drivers
      supporting other device functions. The net/QMI interface number may
      also differ from device to device.  It has been noted that all the
      other interfaces have additional functional descriptors, so we use that
      to detect the interface supported by this driver.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b086cf04
    • Bjørn Mork's avatar
      net: qmi_wwan: support devices having a shared QMI/wwan interface · c3ecb08a
      Bjørn Mork authored
      Use the new cdc-wdm subdriver interface to create a device management
      device even for USB devices having a single combined QMI/wwan USB
      interface with three endpoints (int, bulk in, bulk out) instead of
      separate data and control interfaces.
      
      Some Huawei devices can be switched to a single interface mode for
      use with other operating systems than Linux.  This adds support
      for these devices when they run in such non-Linux modes.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3ecb08a
    • Bjørn Mork's avatar
      net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices · 423ce8ca
      Bjørn Mork authored
      Some WWAN LTE/3G devices based on chipsets from Qualcomm provide
      near standard CDC ECM interfaces in addition to the usual serial
      interfaces.   The Huawei E392/E398 are examples of such devices.
      
      These typically cannot be fully configured using AT commands
      over a serial interface.  It is necessary to speak the proprietary
      Qualcomm MSM Interface (QMI) protocol to the device to enable the
      ethernet proxy functionality.
      
      The devices embed the QMI protocol in CDC on the control interface,
      using standard CDC commands and notifications. The do not otherwise
      use CDC commands for the ethernet function.  This driver does
      therefore not need access to any other aspects of the control
      interface than the descriptors attached to it.
      
      Another driver, cdc-wdm, will provide userspace access to the
      QMI protocol independently of this driver.  To facilitate this,
      this driver avoids binding to the control interface, and uses
      only the associated data interface after parsing the common CDC
      functional descriptors on the control interface.
      
      You will want both the cdc-wdm and option drivers as companions to
      this driver, to have full access to all interfaces and protocols
      exported by the device.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      423ce8ca
    • Thomas Gleixner's avatar
      x86: Derandom delay_tsc for 64 bit · a7f4255f
      Thomas Gleixner authored
      Commit f0fbf0ab ("x86: integrate delay functions") converted
      delay_tsc() into a random delay generator for 64 bit.  The reason is
      that it merged the mostly identical versions of delay_32.c and
      delay_64.c.  Though the subtle difference of the result was:
      
       static void delay_tsc(unsigned long loops)
       {
      -	unsigned bclock, now;
      +	unsigned long bclock, now;
      
      Now the function uses rdtscl() which returns the lower 32bit of the
      TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
      bit this fails when the lower 32bit are close to wrap around when
      bclock is read, because the following check
      
             if ((now - bclock) >= loops)
             	  	break;
      
      evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
      because the unsigned long (now - bclock) of these values results in
      0xffffffff00000001 which is definitely larger than the loops
      value. That explains Tvortkos observation:
      
      "Because I am seeing udelay(500) (_occasionally_) being short, and
       that by delaying for some duration between 0us (yep) and 491us."
      
      Make those variables explicitely u32 again, so this works for both 32
      and 64 bit.
      Reported-by: default avatarTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org # >= 2.6.27
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a7f4255f