1. 22 3月, 2013 1 次提交
  2. 18 3月, 2013 7 次提交
  3. 10 1月, 2013 1 次提交
  4. 22 11月, 2012 1 次提交
  5. 31 10月, 2012 3 次提交
  6. 26 10月, 2012 1 次提交
  7. 09 8月, 2012 2 次提交
  8. 07 8月, 2012 1 次提交
  9. 03 8月, 2012 2 次提交
  10. 04 6月, 2012 2 次提交
    • G
      usb: musb_gadget: fix crash caused by dangling pointer · 08f75bf1
      Grazvydas Ignotas 提交于
      usb_ep_ops.disable must clear external copy of the endpoint descriptor,
      otherwise musb crashes after loading/unloading several gadget modules
      in a row:
      
      Unable to handle kernel paging request at virtual address bf013730
      pgd = c0004000
      [bf013730] *pgd=8f26d811, *pte=00000000, *ppte=00000000
      Internal error: Oops: 7 [#1]
      Modules linked in: g_cdc [last unloaded: g_file_storage]
      CPU: 0    Not tainted  (3.2.17 #647)
      PC is at musb_gadget_enable+0x4c/0x24c
      LR is at _raw_spin_lock_irqsave+0x4c/0x58
      [<c027c030>] (musb_gadget_enable+0x4c/0x24c) from [<bf01b760>] (gether_connect+0x3c/0x19c [g_cdc])
      [<bf01b760>] (gether_connect+0x3c/0x19c [g_cdc]) from [<bf01ba1c>] (ecm_set_alt+0x15c/0x180 [g_cdc])
      [<bf01ba1c>] (ecm_set_alt+0x15c/0x180 [g_cdc]) from [<bf01ecd4>] (composite_setup+0x85c/0xac4 [g_cdc])
      [<bf01ecd4>] (composite_setup+0x85c/0xac4 [g_cdc]) from [<c027b744>] (musb_g_ep0_irq+0x844/0x924)
      [<c027b744>] (musb_g_ep0_irq+0x844/0x924) from [<c027a97c>] (musb_interrupt+0x79c/0x864)
      [<c027a97c>] (musb_interrupt+0x79c/0x864) from [<c027aaa8>] (generic_interrupt+0x64/0x7c)
      [<c027aaa8>] (generic_interrupt+0x64/0x7c) from [<c00797cc>] (handle_irq_event_percpu+0x28/0x178)
      ...
      
      Cc: stable@vger.kernel.org # v3.1+
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      08f75bf1
    • V
      usb: musb: handle nuked ep dma interrupt · abf710e6
      Vikram Pandita 提交于
      User can trigger disabling of gadget at run time while the
      transfers are going on.
      Eg: 1: rmmod of musb driver while transfers are going on
      
      Eg: 2: On android doing:
       echo 0       > /sys/class/android_usb/android0/enable
      While a big file transfer is going on via PTP/MTP.
      
      In such a case, musb_gadget_disable() calls nuke()
      but the dma interrupt may still happen for an endpoint since hw
      would raise the interrupt in anycase.
      
      This can result in a NULL pointer access crash:
      
      [  314.030426] PC is at txstate+0x74/0x20c
      [  314.034759] LR is at musb_g_tx+0x140/0x204
      [  314.039489] pc : [<c03506f4>]    lr : [<c0350bcc>]    psr: 20000193
      [  314.039520] sp : c783bc68  ip : 00000002  fp : c783bc9c
      [  314.052429] r10: 00000018  r9 : 00000000  r8 : 00000200
      [  314.058258] r7 : 00000000  r6 : fc0ab130  r5 : c781a410  r4 : c6caf640
      [  314.065643] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c781a000
      [  315.083251] Backtrace:
      [  315.086242] [<c0350680>] (txstate+0x0/0x20c) from [<c0350bcc>] (musb_g_tx+0x140/0x204)
      [  315.095123] [<c0350a8c>] (musb_g_tx+0x0/0x204) from [<c034eb00>] (musb_dma_completion+0x40/0x54)
      [  315.104980] [<c034eac0>] (musb_dma_completion+0x0/0x54) from [<c0351e6c>] (dma_controller_irq+0x118/0x184)
      [  315.115661] [<c0351d54>] (dma_controller_irq+0x0/0x184) from [<c00d86b8>] (handle_irq_event_percpu+0x54/0x188)
      
      So put protection in code to handle possiblity of getting an interrupt for an
      endpoint that might have been already nuked.
      Reported-by: NTodd Poynor <toddpoynor@google.com>
      Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      abf710e6
  11. 02 3月, 2012 1 次提交
  12. 27 2月, 2012 2 次提交
  13. 24 2月, 2012 1 次提交
    • S
      usb: musb: Reselect index reg in interrupt context · 39287076
      Supriya Karanth 提交于
      musb INDEX register is getting modified/corrupted during temporary
      un-locking in a SMP system. Set this register with proper value
      after re-acquiring the lock
      
      Scenario:
      ---------
      CPU1 is handling a data transfer completion interrupt received for
      the CLASS1 EP
      CPU2 is handling a CLASS2 thread which is queuing data to musb for
      transfer
      
      Below is the error sequence:
      
               CPU1                   |             CPU2
      --------------------------------------------------------------------
      Data transfer completion inter- |
      rupt recieved.                  |
                                      |
      musb INDEX reg set to CLASS1 EP |
                                      |
      musb LOCK is acquired.          |
                                      |
                                      | CLASS2 thread queues data.
                                      |
                                      | CLASS2 thread tries to acquire musb
                                      | LOCK but lock is already taken by
                                      | CLASS1, so CLASS2 thread is
                                      | spinning.
                                      |
      From Interrupt Context musb     |
      giveback function is called     |
                                      |
      The giveback function releases  | CLASS2 thread now acquires LOCK
      LOCK                            |
                                      |
      ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and
      lback is called                 | sets the MUSB INDEX to Class2 EP number
                                      |
      Interrupt handler for CLASS1 EP |
      tries to acquire LOCK and is    |
      spinning                        |
                                      |
      Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and
      the MUSB LOCK                   | releases the musb LOCK
                                      |
      Interrupt for Class1 EP schedul-|
      es the next data transfer       |
      but musb INDEX register is still|
      set to CLASS2 EP                |
      
      Since the MUSB INDEX register is set to a different endpoint, we
      read and modify the wrong registers. Hence data transfer will not
      happen properly. This results in unpredictable behavior
      
      So, the MUSB INDEX register is set to proper value again when
      interrupt re-acquires the lock
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSupriya Karanth <supriya.karanth@stericsson.com>
      Signed-off-by: NPraveena Nadahally <praveen.nadahally@stericsson.com>
      Reviewed-by: Nsrinidhi kasagar <srinidhi.kasagar@stericsson.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      39287076
  14. 13 2月, 2012 1 次提交
  15. 31 1月, 2012 1 次提交
  16. 12 12月, 2011 3 次提交
  17. 29 11月, 2011 1 次提交
  18. 15 11月, 2011 1 次提交
  19. 15 9月, 2011 1 次提交
  20. 09 9月, 2011 1 次提交
  21. 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
  22. 12 8月, 2011 2 次提交
    • S
      usb: musb: gadget: fix error path · 6193d699
      Sebastian Andrzej Siewior 提交于
      In case one "forgot" to load the receiver i.e. doing
      |modprobe omap2430
      |modprobe musb_hdrc
      
      he ends up with:
      
      |musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
      |HS USB OTG: no transceiver configured
      |musb-hdrc musb-hdrc: musb_init_controller failed with status -19
      |(NULL device *): gadget not registered.
      |Unable to handle kernel NULL pointer dereference at virtual address 0000001c
      |Internal error: Oops: 17 [#1] SMP
      |[<c011383c>] (sysfs_find_dirent+0x4/0x60) from [<c01138c0>] (sysfs_get_dirent+0x28/0x78)
      |[<c01138c0>] (sysfs_get_dirent+0x28/0x78) from [<c0115b78>] (sysfs_unmerge_group+0x1c/0x90)
      |[<c0115b78>] (sysfs_unmerge_group+0x1c/0x90) from [<c0179ba4>] (dpm_sysfs_remove+0x14/0x3c)
      |[<c0179ba4>] (dpm_sysfs_remove+0x14/0x3c) from [<c01742f8>] (device_del+0x40/0x1b4)
      |[<c01742f8>] (device_del+0x40/0x1b4) from [<c0174478>] (device_unregister+0xc/0x18)
      |[<c0174478>] (device_unregister+0xc/0x18) from [<bf0489b4>] (musb_free+0x24/0x88 [musb_hdrc])
      |[<bf0489b4>] (musb_free+0x24/0x88 [musb_hdrc]) from [<bf057d18>] (musb_probe+0xb50/0xe3c [musb_hdrc])
      |[<bf057d18>] (musb_probe+0xb50/0xe3c [musb_hdrc]) from [<c01779c4>] (platform_drv_probe+0x1c/0x24)
      
      The problem is that musb_free() tries to figure out what was
      initializued and what wasn't and clean up only the initialized part.
      This works well for usb_del_gadget_udc() but device_unregister() can't
      deal with it. Therefore we rely on the fact the we always have a parent
      device and only then remove the device.
      I broke this in 0f91349b ("usb: gadget: convert all users to the new udc
      infrastructure")
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      6193d699
    • J
      usb: musb: fix oops on musb_gadget_pullup · 93e098a8
      John Stultz 提交于
      an 'unhandled fault' is causes when a gadget driver calls
      usb_gadget_connect() while the USB cable isn't plugged into
      the OTG port.
      
      the fault is caused by an access to MUSB's memory space
      while its clock is turned off due to pm_runtime kicking
      in.
      
      in order to fix the fault, we enclose musb_gadget_pullup()
      with pm_runtime_get_sync() ... pm_runtime_put() calls to
      be sure we will always reach that path with clock turned on.
      
      [ balbi@ti.com : simplified commit log; removed few things
      	which didn't belong there ]
      
      Cc: stable@kernel.org
      Reported-by: NZach Pfeffer <zach.pfeffer@linaro.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      93e098a8
  23. 02 8月, 2011 1 次提交
    • J
      usb: musb: fix oops on musb_gadget_pullup · 72c487df
      John Stultz 提交于
      an 'unhandled fault' is causes when a gadget driver calls
      usb_gadget_connect() while the USB cable isn't plugged into
      the OTG port.
      
      the fault is caused by an access to MUSB's memory space
      while its clock is turned off due to pm_runtime kicking
      in.
      
      in order to fix the fault, we enclose musb_gadget_pullup()
      with pm_runtime_get_sync() ... pm_runtime_put() calls to
      be sure we will always reach that path with clock turned on.
      
      [ balbi@ti.com : simplified commit log; removed few things
      	which didn't belong there ]
      
      Cc: stable@kernel.org
      Reported-by: NZach Pfeffer <zach.pfeffer@linaro.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      72c487df
  24. 02 7月, 2011 2 次提交