1. 10 4月, 2012 11 次提交
    • A
      UHCI: hub_status_data should indicate if ports are resuming · b446b96f
      Alan Stern 提交于
      This patch (as1538) causes uhci_hub_status_data() to return a nonzero
      value when any port is undergoing a resume transition while the root
      hub is suspended.  This will allow usbcore to handle races between
      root-hub suspend and port wakeup.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b446b96f
    • A
      EHCI: keep track of ports being resumed and indicate in hub_status_data · a448e4dc
      Alan Stern 提交于
      This patch (as1537) adds a bit-array to ehci-hcd for keeping track of
      which ports are undergoing a resume transition.  If any of the bits
      are set when ehci_hub_status_data() is called, the routine will return
      a nonzero value even if no ports have any status changes pending.
      This will allow usbcore to handle races between root-hub suspend and
      port wakeup.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      CC: Chen Peter-B29397 <B29397@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a448e4dc
    • A
      USB: fix race between root-hub suspend and remote wakeup · 879d38e6
      Alan Stern 提交于
      This patch (as1533) fixes a race between root-hub suspend and remote
      wakeup.  If a wakeup event occurs while a root hub is suspending, it
      might not cause the suspend to fail.  Although the host controller
      drivers check for pending wakeup events at the start of their
      bus_suspend routines, they generally do not check for wakeup events
      while the routines are running.
      
      In addition, if a wakeup event occurs any time after khubd is frozen
      and before the root hub is fully suspended, it might not cause a
      system sleep transition to fail.  For example, the host controller
      drivers do not fail root-hub suspends when a connect-change event is
      pending.
      
      To fix both these issues, this patch causes hcd_bus_suspend() to query
      the controller driver's hub_status_data method after a root hub is
      suspended, if the root hub is enabled for wakeup.  Any pending status
      changes will count as wakeup events, causing the root hub to be
      resumed and the overall suspend to fail with -EBUSY.
      
      A significant point is that not all events are reflected immediately
      in the status bits.  Both EHCI and UHCI controllers notify the CPU
      when remote wakeup begins on a port, but the port's suspend-change
      status bit doesn't get set until after the port has completed the
      transition out of the suspend state, some 25 milliseconds later.
      Consequently, the patch will interpret any nonzero return value from
      hub_status_data as indicating a pending event, even if none of the
      status bits are set in the data buffer.  Follow-up patches make the
      necessary changes to ehci-hcd and uhci-hcd.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      CC: Chen Peter-B29397 <B29397@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      879d38e6
    • A
      USB: sierra: add support for Sierra Wireless MC7710 · c5d703dc
      Anton Samokhvalov 提交于
      Just add new device id. 3G works fine, LTE not tested.
      Signed-off-by: NAnton Samokhvalov <pg83@yandex.ru>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5d703dc
    • S
      USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort of TIOCMIWAIT when the device is removed · 876ae50d
      Simon Arlott 提交于
      There are two issues here, one is that the device is generating
      spurious very fast modem status line changes somewhere:
      
      CTS becomes high then low 18µs later:
      [121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
      [121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
      [121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
      (wake_up_interruptible is called)
      [121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
      [121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
      [121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
      (wake_up_interruptible is called)
      
      This wakes up the task in TIOCMIWAIT:
      [121226.924405] ftdi_ioctl: 19451 rng=0->0 dsr=10->10 dcd=0->0 cts=6->8
      (wait from 20:51:46 returns and observes both changes)
      
      Which then calls TIOCMIWAIT again:
      20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
      22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
      22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
      (the second wake_up_interruptible takes effect and an I/O error occurs)
      
      The other issue is that TIOCMIWAIT will wait forever (unless the task is
      interrupted) if the device is removed.
      
      This change removes the -EIO return that occurs if the counts don't
      appear to have changed. Multiple counts may have been processed as
      one or the waiting task may have started waiting after recording the
      current count.
      
      It adds a bool to indicate that the device has been removed so that
      TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
      return -EIO.
      Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      876ae50d
    • S
      USB: ftdi_sio: fix status line change handling for TIOCMIWAIT and TIOCGICOUNT · fca5430d
      Simon Arlott 提交于
      Handling of TIOCMIWAIT was changed by commit 1d749f9a
       USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers
      
      FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
      it indicates the value of the current modem status lines. An xor is
      still required to determine which lines have changed.
      
      The count was only being incremented if the line was high. The only
      reason TIOCMIWAIT still worked was because the status packet is
      repeated every 1ms, so the count was always changing. The wakeup
      itself still ran based on the status lines changing.
      
      This change fixes handling of updates to the modem status lines and
      allows multiple processes to use TIOCMIWAIT concurrently.
      
      Tested with two processes waiting on different status lines being
      toggled independently.
      Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
      Cc: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fca5430d
    • A
      USB: don't ignore suspend errors for root hubs · cd4376e2
      Alan Stern 提交于
      This patch (as1532) fixes a mistake in the USB suspend code.  When the
      system is going to sleep, we should ignore errors in powering down USB
      devices, because they don't really matter.  The devices will go to low
      power anyway when the entire USB bus gets suspended (except for
      SuperSpeed devices; maybe they will need special treatment later).
      
      However we should not ignore errors in suspending root hubs,
      especially if the error indicates that the suspend raced with a wakeup
      request.  Doing so might leave the bus powered on while the system was
      supposed to be asleep, or it might cause the suspend of the root hub's
      parent controller device to fail, or it might cause a wakeup request
      to be ignored.
      
      The patch fixes the problem by ignoring errors only when the device in
      question is not a root hub.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NChen Peter <B29397@freescale.com>
      CC: <stable@vger.kernel.org>
      Tested-by: NChen Peter <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd4376e2
    • A
      USB: fix bug in serial driver unregistration · 891a3b1f
      Alan Stern 提交于
      This patch (as1536) fixes a bug in the USB serial core.  Unloading and
      reloading a serial driver while a serial device is plugged in causes
      errors because of the code in usb_serial_disconnect() that tries to
      make sure the port_remove method is called.  With the new order of
      driver registration introduced in the 3.4 kernel, this is definitely
      not the right thing to do (if indeed it ever was).
      
      The patch removes that whole section code, along with the mechanism
      for keeping track of each port's registration state, which is no
      longer needed.  The driver core can handle all that stuff for us.
      
      Note: This has been tested only with one or two USB serial drivers.
      In theory, other drivers might still run into trouble.  But if they
      do, it will be the fault of the drivers, not of this patch -- that is,
      the drivers will need to be fixed.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      891a3b1f
    • A
      USB: serial: metro-usb: Fix idProduct for Uni-Directional mode. · 3a450850
      Aleksey Babahin 提交于
      The right idProduct for Metrologic Bar Code Scanner
      in Uni-Directional Serial Emulation mode is 0x0700.
      
      Also rename idProduct for Bi-Directional mode to be a bit more informative.
      Signed-off-by: NAleksey Babahin <tamerlan311@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a450850
    • S
      USB: option: re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array · 9ac2feb2
      Santiago Garcia Mantinan 提交于
      Re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
      Signed-off-by: NSantiago Garcia Mantinan <manty@debian.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ac2feb2
    • J
      USB: pl2303: fix DTR/RTS being raised on baud rate change · ce5c9851
      Johan Hovold 提交于
      DTR/RTS should only be raised when changing baudrate from B0 and not on
      any baud rate change (> B0).
      Reported-by: NSøren Holm <sgh@sgh.dk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce5c9851
  2. 07 4月, 2012 5 次提交
    • M
      USB: remove compile warning on gadget/inode.c · a2457ee6
      Michael BRIGHT 提交于
      Removed unused "restart:" label, which was causing compiler warning.
      Signed-off-by: NMichael BRIGHT <mjbrightfr+git-kernel@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2457ee6
    • A
      USB documentation: explain lifetime rules for unlinking URBs · da8bfb09
      Alan Stern 提交于
      This patch (as1534c) updates the documentation for usb_unlink_urb and
      related functions.  It explains that the caller must prevent the URB
      being unlinked from getting deallocated while the unlink is taking
      place.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Ming Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da8bfb09
    • A
      USB: don't clear urb->dev in scatter-gather library · bcf39853
      Alan Stern 提交于
      This patch (as1517b) fixes an error in the USB scatter-gather library.
      The library code uses urb->dev to determine whether or nor an URB is
      currently active; the completion handler sets urb->dev to NULL.
      However the core unlinking routines need to use urb->dev.  Since
      unlinking always racing with completion, the completion handler must
      not clear urb->dev -- it can lead to invalid memory accesses when a
      transfer has to be cancelled.
      
      This patch fixes the problem by getting rid of the lines that clear
      urb->dev after urb has been submitted.  As a result we may end up
      trying to unlink an URB that failed in submission or that has already
      completed, so an extra check is added after each unlink to avoid
      printing an error message when this happens.  The checks are updated
      in both sg_complete() and sg_cancel(), and the second is updated to
      match the first (currently it prints out unnecessary warning messages
      if a device is unplugged while a transfer is in progress).
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NIllia Zaitsev <I.Zaitsev@adbglobal.com>
      CC: Ming Lei <tom.leiming@gmail.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcf39853
    • M
      usb: storage: fix lockdep warning inside usb_stor_pre_reset(v2) · c825bab0
      Ming Lei 提交于
      This patch fixes one lockdep warning[1] inside usb_stor_pre_reset.
      
      If the current configuration includes multiple mass storage interfaces,
      the 'AA' lockdep warning will be triggered since the lock class of
      'us->dev_mutex' is acquired two times in .reset path. It isn't
      a real deadlock, so just take the lockdep_set_class annotation to
      remove the warning.
      
      [1], lockdep warning log
      :[ INFO: possible recursive locking detected ]
      :3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Tainted: G        W
      :---------------------------------------------
      :usb-storage/14846 is trying to acquire lock:
      : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      :but task is already holding lock:
      : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      :other info that might help us debug this:
      : Possible unsafe locking scenario:
      :       CPU0
      :       ----
      :  lock(&(us->dev_mutex));
      :  lock(&(us->dev_mutex));
      : *** DEADLOCK ***
      : May be due to missing lock nesting notation
      :2 locks held by usb-storage/14846:
      : #0:  (&__lockdep_no_validate__){......}, at: [<ffffffff8147e6a5>] usb_lock_device_for_reset+0x95/0x100
      : #1:  (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      :stack backtrace:
      :Pid: 14846, comm: usb-storage Tainted: G        W 3.3.0-0.rc5.git3.1.fc17.x86_64 #1
      :Call Trace:
      : [<ffffffff810cbdaf>] __lock_acquire+0x168f/0x1bb0
      : [<ffffffff81021083>] ? native_sched_clock+0x13/0x80
      : [<ffffffff810210f9>] ? sched_clock+0x9/0x10
      : [<ffffffff810210f9>] ? sched_clock+0x9/0x10
      : [<ffffffff810a2975>] ? sched_clock_local+0x25/0xa0
      : [<ffffffff810cc9a1>] lock_acquire+0xa1/0x1e0
      : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      : [<ffffffff81699c86>] mutex_lock_nested+0x76/0x3a0
      : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      : [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
      : [<ffffffff8148184d>] usb_reset_device+0x7d/0x190
      : [<ffffffffa048119c>] usb_stor_port_reset+0x7c/0x80 [usb_storage]
      : [<ffffffffa0481234>] usb_stor_invoke_transport+0x94/0x560 [usb_storage]
      : [<ffffffff810cd3b2>] ? mark_held_locks+0xb2/0x130
      : [<ffffffff8169dbd0>] ? _raw_spin_unlock_irq+0x30/0x50
      : [<ffffffffa047fe3e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
      : [<ffffffffa0481ae3>] usb_stor_control_thread+0x173/0x280 [usb_storage]
      : [<ffffffffa0481970>] ? fill_inquiry_response+0x20/0x20 [usb_storage]
      : [<ffffffff8108a3f7>] kthread+0xb7/0xc0
      : [<ffffffff816a7d34>] kernel_thread_helper+0x4/0x10
      : [<ffffffff8169e0f4>] ? retint_restore_args+0x13/0x13
      : [<ffffffff8108a340>] ? kthread_worker_fn+0x1a0/0x1a0
      : [<ffffffff816a7d30>] ? gs_change+0x13/0x13
      Reported-By: NDave Jones <davej@redhat.com>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c825bab0
    • D
      usb: Put USB Kconfig items back under USB. · a8edc42a
      David Daney 提交于
      commit 53c6bc24 (usb: Don't make
      USB_ARCH_HAS_{XHCI,OHCI,EHCI} depend on USB_SUPPORT.)  Removed the
      dependency of the USB_ARCH_HAS_* symbols on USB_SUPPORT.  However the
      resulting Kconfig somehow caused many of the USB configuration items
      to appear under the top level devices menu.
      
      To fix this we reunite the 'menuconfig USB_SUPPORT' with the 'if
      USB_SUPPORT', and the config items magically go back to their desired
      location.
      Reported-by: NJulian Wollrath <jwollrath@web.de>
      Reported-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Reported-by: NBorislav Petkov <bp@alien8.de>
      Reported-by: NRupesh Gujare <rgujare@ozmodevices.com>
      Reported-by: NFeng King <ronyjin@tencent.com>
      Reported-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Tested-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8edc42a
  3. 06 4月, 2012 1 次提交
    • S
      simple_open: automatically convert to simple_open() · 234e3405
      Stephen Boyd 提交于
      Many users of debugfs copy the implementation of default_open() when
      they want to support a custom read/write function op.  This leads to a
      proliferation of the default_open() implementation across the entire
      tree.
      
      Now that the common implementation has been consolidated into libfs we
      can replace all the users of this function with simple_open().
      
      This replacement was done with the following semantic patch:
      
      <smpl>
      @ open @
      identifier open_f != simple_open;
      identifier i, f;
      @@
      -int open_f(struct inode *i, struct file *f)
      -{
      (
      -if (i->i_private)
      -f->private_data = i->i_private;
      |
      -f->private_data = i->i_private;
      )
      -return 0;
      -}
      
      @ has_open depends on open @
      identifier fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...
      -.open = open_f,
      +.open = simple_open,
      ...
      };
      </smpl>
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      234e3405
  4. 05 4月, 2012 5 次提交
  5. 31 3月, 2012 1 次提交
  6. 29 3月, 2012 1 次提交
  7. 28 3月, 2012 1 次提交
  8. 26 3月, 2012 2 次提交
  9. 24 3月, 2012 6 次提交
  10. 21 3月, 2012 5 次提交
  11. 17 3月, 2012 2 次提交