1. 25 6月, 2012 2 次提交
  2. 12 5月, 2012 12 次提交
  3. 11 5月, 2012 1 次提交
  4. 10 5月, 2012 7 次提交
  5. 09 5月, 2012 3 次提交
  6. 04 5月, 2012 1 次提交
  7. 28 4月, 2012 1 次提交
  8. 27 2月, 2012 2 次提交
  9. 24 2月, 2012 1 次提交
  10. 12 12月, 2011 4 次提交
  11. 15 11月, 2011 3 次提交
    • M
      USB: ci13xxx_udc: fix debug trace code · 194fa47e
      Marc Kleine-Budde 提交于
      This patch fixes the following compile errors that show up if switching
      on the debug trace code:
      
      drivers/usb/gadget/ci13xxx_udc.c: In function 'ci13xxx_wakeup':
      drivers/usb/gadget/ci13xxx_udc.c:2517:3: error: 'dev' undeclared (first use in this function)
      drivers/usb/gadget/ci13xxx_udc.c:2517:3: note: each undeclared identifier is reported only once for each function it appears in
      drivers/usb/gadget/ci13xxx_udc.c: In function 'udc_probe':
      drivers/usb/gadget/ci13xxx_udc.c:2867:2: error: 'name' undeclared (first use in this function)
      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>
      194fa47e
    • M
      USB: ci13xxx_udc: fix deadlock during rmmod · fd537c04
      Marc Kleine-Budde 提交于
      The inline documentation of _gadget_stop_activity() states that the
      function should be called holding the udc->lock. This however will
      result in a deadlock, because _gadget_stop_activity() takes the udc->lock.
      
      During normal operation _gadget_stop_activity() is always called unlocked,
      but in ci13xxx_stop() it's called locked, this results in the following
      deadlock during rmmod of a gadget driver.
      
      This patch fixes the deadlock by calling _gadget_stop_activity() always
      unlocked, the inline documentation is adjusted accordingly.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      3.1.0-rc6+ #159
      ---------------------------------------------
      rmmod/121 is trying to acquire lock:
       (udc_lock){-.-...}, at: [<c0229048>] _gadget_stop_activity+0x18/0x154
      
      but task is already holding lock:
       (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(udc_lock);
        lock(udc_lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by rmmod/121:
       #0:  (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
       #1:  (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
      
      stack backtrace:
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4)
      [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) from [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc)
      [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) from [<c0059bac>] (__lock_acquire+0x494/0x8f0)
      [<c0059bac>] (__lock_acquire+0x494/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
      [<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0)
      [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
      [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
      [<c0229234>] (ci13xxx_stop+0xb0/0x164) 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 [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
      [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
      BUG: spinlock lockup on CPU#0, rmmod/121, c05b1644
      [<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c01da000>] (do_raw_spin_lock+0x128/0x144)
      [<c01da000>] (do_raw_spin_lock+0x128/0x144) from [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0)
      [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
      [<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
      [<c0229234>] (ci13xxx_stop+0xb0/0x164) 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 [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
      [<c0065f2c>] (sys_delete_module+0x1fc/0x26c) 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>
      fd537c04
    • M
      USB: ci13xxx_udc: fix logic to mark request dma addresses as invalid · 954aad8c
      Michael Grzeschik 提交于
      The current driver sets the request's dma addr (mReq->req.dma) to 0 to
      mark the DMA address as not valid. However some gadget drivers
      (e.g. gadgetfs) set the request's dma addr to DMA_ADDR_INVALID to mark
      the address as invalid. This leads to bogus data send because the
      ci13xxx_udc driver assumes the request has already been mapped.
      
      This patch fixes the problem, by using DMA_ADDR_INVALID instead of 0
      to mark the request's DMA address as invalid.
      Tested-by: NPavankumar Kondeti <pkondeti@codeaurora.org>
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      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>
      954aad8c
  12. 24 8月, 2011 1 次提交
    • K
      USB: use usb_endpoint_maxp() instead of le16_to_cpu() · 29cc8897
      Kuninori Morimoto 提交于
      Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size
      instead of le16_to_cpu(desc->wMaxPacketSize).
      This patch fix it up
      
      Cc: Armin Fuerst <fuerst@in.tum.de>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Johannes Erdfelt <johannes@erdfelt.com>
      Cc: Vojtech Pavlik <vojtech@suse.cz>
      Cc: Oliver Neukum <oliver@neukum.name>
      Cc: David Kubicek <dave@awk.cz>
      Cc: Johan Hovold <jhovold@gmail.com>
      Cc: Brad Hards <bhards@bigpond.net.au>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: David Lopo <dlopo@chipidea.mips.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>
      Cc: Xie Xiaobo <X.Xie@freescale.com>
      Cc: Li Yang <leoli@freescale.com>
      Cc: Jiang Bo <tanya.jiang@freescale.com>
      Cc: Yuan-hsin Chen <yhchen@faraday-tech.com>
      Cc: Darius Augulis <augulis.darius@gmail.com>
      Cc: Xiaochen Shen <xiaochen.shen@intel.com>
      Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com>
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Cc: Ben Dooks <ben@simtec.co.uk>
      Cc: Thomas Abraham <thomas.ab@samsung.com>
      Cc: Herbert Pötzl <herbert@13thfloor.at>
      Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
      Cc: Roman Weissgaerber <weissg@vienna.at>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Tony Olech <tony.olech@elandigitalsystems.com>
      Cc: Florian Floe Echtler <echtler@fs.tum.de>
      Cc: Christian Lucht <lucht@codemercs.com>
      Cc: Juergen Stuber <starblue@sourceforge.net>
      Cc: Georges Toth <g.toth@e-biz.lu>
      Cc: Bill Ryder <bryder@sgi.com>
      Cc: Kuba Ober <kuba@mareimbrium.org>
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      29cc8897
  13. 05 7月, 2011 1 次提交
  14. 02 7月, 2011 1 次提交