1. 26 Oct, 2012 1 commit
    • Tilman Schmidt's avatar
      bas_gigaset: fix pre_reset handling · c6fdd8e5
      Tilman Schmidt authored
      The delayed work function int_in_work() may call usb_reset_device()
      and thus, indirectly, the driver's pre_reset method. Trying to
      cancel the work synchronously in that situation would deadlock.
      Fix by avoiding cancel_work_sync() in the pre_reset method.
      
      If the reset was NOT initiated by int_in_work() this might cause
      int_in_work() to run after the post_reset method, with urb_int_in
      already resubmitted, so handle that case gracefully.
      Signed-off-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6fdd8e5
  2. 10 Oct, 2012 1 commit
  3. 03 Oct, 2012 1 commit
  4. 13 Sep, 2012 2 commits
  5. 03 Sep, 2012 1 commit
  6. 20 Aug, 2012 1 commit
    • Tejun Heo's avatar
      workqueue: deprecate flush[_delayed]_work_sync() · 43829731
      Tejun Heo authored
      flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
      and convert all users to flush[_delayed]_work().
      
      If you're cc'd and wondering what's going on: Now all workqueues are
      non-reentrant and the regular flushes guarantee that the work item is
      not pending or running on any CPU on return, so there's no reason to
      use the sync flushes at all and they're going away.
      
      This patch doesn't make any functional difference.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Mattia Dongili <malattia@linux.it>
      Cc: Kent Yoder <key@linux.vnet.ibm.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: Anton Vorontsov <cbou@mail.ru>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Avi Kivity <avi@redhat.com> 
      43829731
  7. 13 Aug, 2012 3 commits
  8. 06 Aug, 2012 1 commit
    • Karsten Keil's avatar
      mISDN: Bugfix for layer2 fixed TEI mode · 25099335
      Karsten Keil authored
      If a fixed TEI is used, the initial state of the layer 2 statmachine need to be
      4 (TEI assigned). This was true only for Point to Point connections, but not
      for the other fixed TEIs. It was not found before, because usually only the
      TEI 0 is used as fixed TEI for PtP mode, but if you try X31 packet mode
      connections with SAPI 16, TEI 1, it did fail.
      Signed-off-by: default avatarKarsten Keil <keil@b1-systems.de>
      Cc: <stable@vger.kernel.org> # 3.5.x
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25099335
  9. 03 Aug, 2012 1 commit
    • Wu Fengguang's avatar
      isdnloop: fix and simplify isdnloop_init() · 77f00f63
      Wu Fengguang authored
      Fix a buffer overflow bug by removing the revision and printk.
      
      [   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
      [   22.097508] isdnloop: (loop0) virtual card added
      [   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
      [   22.174400]
      [   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb13-dirty #129
      [   22.624071] Call Trace:
      [   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
      [   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
      [   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
      [   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
      [   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
      [   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
      Signed-off-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77f00f63
  10. 30 Jul, 2012 1 commit
  11. 18 Jul, 2012 2 commits
  12. 17 Jul, 2012 1 commit
  13. 16 Jul, 2012 1 commit
  14. 09 Jul, 2012 1 commit
  15. 22 May, 2012 1 commit
  16. 18 May, 2012 1 commit
    • Sarah Sharp's avatar
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      Sarah Sharp authored
      Hub-initiated LPM is not good for USB communications devices.  Comms
      devices should be able to tell when their link can go into a lower power
      state, because they know when an incoming transmission is finished.
      Ideally, these devices would slam their links into a lower power state,
      using the device-initiated LPM, after finishing the last packet of their
      data transfer.
      
      If we enable the idle timeouts for the parent hubs to enable
      hub-initiated LPM, we will get a lot of useless LPM packets on the bus
      as the devices reject LPM transitions when they're in the middle of
      receiving data.  Worse, some devices might blindly accept the
      hub-initiated LPM and power down their radios while they're in the
      middle of receiving a transmission.
      
      The Intel Windows folks are disabling hub-initiated LPM for all USB
      communications devices under a xHCI USB 3.0 host.  In order to keep
      the Linux behavior as close as possible to Windows, we need to do the
      same in Linux.
      
      Set the disable_hub_initiated_lpm flag for for all USB communications
      drivers.  I know there aren't currently any USB 3.0 devices that
      implement these class specifications, but we should be ready if they do.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Jan Dumon <j.dumon@option.com>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Roland Vossen <rvossen@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Kan Yan <kanyan@broadcom.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Daniel Drake <dsd@gentoo.org>
      Cc: Ulrich Kunitz <kune@deine-taler.de>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1f12eb6
  17. 17 May, 2012 1 commit
  18. 16 May, 2012 8 commits
  19. 15 May, 2012 1 commit
  20. 07 May, 2012 8 commits
  21. 04 May, 2012 2 commits