1. 31 10月, 2012 1 次提交
  2. 21 9月, 2012 1 次提交
  3. 10 9月, 2012 2 次提交
  4. 31 8月, 2012 1 次提交
    • M
      usb: gadget: get rid of USB_GADGET_{DUAL,SUPER}SPEED · 85b8614d
      Michal Nazarewicz 提交于
      This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
      Kconfig options.  Since now kernel allows many UDC drivers to be
      compiled, those options may turn to no longer be valid.  For
      instance, if someone decides to build UDC that supports super
      speed and UDC that supports high speed only, the latter will be
      "assumed" to support super speed since USB_GADGET_SUPERSPEED will
      be selected by the former.
      
      The test of whether CONFIG_USB_GADGET_*SPEED was defined was just
      an optimisation which removed otherwise dead code (ie. if UDC is
      not dual speed, there is no need to handle cases that can happen
      if speed is high).  This commit removes those checks.
      Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      85b8614d
  5. 07 4月, 2012 1 次提交
  6. 21 3月, 2012 2 次提交
  7. 03 3月, 2012 1 次提交
  8. 09 1月, 2012 1 次提交
  9. 12 12月, 2011 1 次提交
    • M
      usb: gadget: rename usb_gadget_driver::speed to max_speed · 7177aed4
      Michal Nazarewicz 提交于
      This commit renames the “speed” field of the usb_gadget_driver
      structure to “max_speed”.  This is so that to make it more
      apparent that the field represents the maximum speed gadget
      driver can support.
      
      This also make the field look more like fields with the same
      name in usb_gadget and usb_composite_driver structures.  All
      of those represent the *maximal* speed given entity supports.
      
      After this commit, there are the following fields in various
      structures:
      * usb_gadget::speed - the current connection speed,
      * usb_gadget::max_speed - maximal speed UDC supports,
      * usb_gadget_driver::max_speed - maximal speed gadget driver
        supports, and
      * usb_composite_driver::max_speed - maximal speed composite
        gadget supports.
      Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7177aed4
  10. 15 11月, 2011 1 次提交
    • M
      USB: gadgetfs: gadgetfs_disconnect: fix inconsistent lock state · 001428e4
      Marc Kleine-Budde 提交于
      Under certain circumstances lockdep finds an inconsistent lock state in
      gadgetfs. The problem can be reproduced with a hardware using the
      ci13xxx_udc driver and the gadgetfs test program (needs a patch to support
      the ci13xxx_udc, though):
      	http://www.linux-usb.org/gadget/usb.c
      Start the test program, wait to initialize, then press Ctrl+c.
      
      This patch fixes the following problem by using spin_lock_irqsave()
      instead of spin_lock().
      
      =================================
      [ INFO: inconsistent lock state ]
      3.1.0-rc6+ #158
      ---------------------------------
      inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
      {IN-HARDIRQ-W} state was registered at:
        [<c00596b8>] mark_irqflags+0x14c/0x1ac
        [<c0059bf8>] __lock_acquire+0x4e0/0x8f0
        [<c005a698>] lock_acquire+0x98/0x1a8
        [<c02f10e0>] _raw_spin_lock+0x54/0x8c
        [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
        [<c0229104>] _gadget_stop_activity+0xd4/0x154
        [<c022b130>] isr_reset_handler+0x34/0x1c0
        [<c022c320>] udc_irq+0x204/0x228
        [<c0069018>] handle_irq_event_percpu+0x64/0x3a0
        [<c0069390>] handle_irq_event+0x3c/0x5c
        [<c006ae5c>] handle_level_irq+0x8c/0x10c
        [<c0068a34>] generic_handle_irq+0x30/0x44
        [<c0009b2c>] handle_IRQ+0x30/0x84
        [<c0008ef8>] __irq_svc+0x38/0x60
        [<c0009c58>] default_idle+0x30/0x34
        [<c0009e30>] cpu_idle+0x9c/0xd8
        [<c04056f4>] start_kernel+0x278/0x2bc
      irq event stamp: 6412
      hardirqs last  enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c
      hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0
      softirqs last  enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8
      softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&dev->lock)->rlock);
        <Interrupt>
          lock(&(&dev->lock)->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by usb/113:
       #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
      
      stack backtrace:
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4)
      [<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274)
      [<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0)
      [<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac)
      [<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0)
      [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
      [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c)
      [<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs])
      [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154)
      [<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c)
      [<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
      [<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
      [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs])
      [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0)
      [<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74)
      [<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150)
      [<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      001428e4
  11. 10 9月, 2011 1 次提交
    • K
      usb gadget: clean up FSF boilerplate text · 28c9fc68
      Klaus Schwarzkopf 提交于
      remove the following two paragraphs as they are not needed:
      
      This program is distributed in the hope that it will be useful, but
      WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
      FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
      License for more details.
      
      You should have received a copy of the GNU General Public License along with
      this program; if not, write to the Free Software Foundation, Inc.,59
      Temple Place - Suite 330, Boston, MA  02111-1307, USA.
      Signed-off-by: NKlaus Schwarzkopf <schwarzkopf@sensortherm.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      28c9fc68
  12. 02 7月, 2011 1 次提交
  13. 29 6月, 2011 1 次提交
  14. 07 6月, 2011 1 次提交
  15. 14 4月, 2011 1 次提交
  16. 29 10月, 2010 1 次提交
  17. 26 10月, 2010 1 次提交
    • C
      fs: do not assign default i_ino in new_inode · 85fe4025
      Christoph Hellwig 提交于
      Instead of always assigning an increasing inode number in new_inode
      move the call to assign it into those callers that actually need it.
      For now callers that need it is estimated conservatively, that is
      the call is added to all filesystems that do not assign an i_ino
      by themselves.  For a few more filesystems we can avoid assigning
      any inode number given that they aren't user visible, and for others
      it could be done lazily when an inode number is actually needed,
      but that's left for later patches.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      85fe4025
  18. 23 10月, 2010 1 次提交
  19. 05 10月, 2010 1 次提交
    • A
      BKL: Remove BKL from USB gadgetfs · cdbd2b01
      Arnd Bergmann 提交于
      The BKL is only used in fill_super, which is  protected by the superblocks
      s_umount rw_semaphore. Therefore it is safe to remove the BKL entirely.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: linux-usb@vger.kernel.org
      cdbd2b01
  20. 11 8月, 2010 2 次提交
  21. 03 3月, 2010 1 次提交
  22. 05 10月, 2009 1 次提交
  23. 22 9月, 2009 1 次提交
  24. 16 6月, 2009 1 次提交
  25. 25 3月, 2009 1 次提交
  26. 06 1月, 2009 1 次提交
  27. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  28. 26 7月, 2008 1 次提交
  29. 22 7月, 2008 1 次提交
  30. 10 7月, 2008 1 次提交
  31. 25 4月, 2008 1 次提交
  32. 25 3月, 2008 1 次提交
  33. 02 2月, 2008 1 次提交
  34. 13 10月, 2007 2 次提交
  35. 31 7月, 2007 1 次提交
  36. 13 7月, 2007 1 次提交
    • D
      usb gadget stack: remove usb_ep_*_buffer(), part 1 · 9d8bab58
      David Brownell 提交于
      Remove usb_ep_{alloc,free}_buffer() calls, for small dma-coherent buffers.
      This patch just removes the interface and its users; later patches will
      remove controller driver support.
      
        - This interface is invariably not implemented correctly in the
          controller drivers (e.g. using dma pools, a mechanism which
          post-dates the interface by several years).
      
        - At this point no gadget driver really *needs* to use it.  In
          current kernels, any driver that needs such a mechanism could
          allocate a dma pool themselves.
      
      Removing this interface is thus a simplification and improvement.
      
      Note that the gmidi.c driver had a bug in this area; fixed.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9d8bab58