1. 03 8月, 2012 6 次提交
  2. 31 7月, 2012 1 次提交
  3. 02 7月, 2012 1 次提交
  4. 25 6月, 2012 6 次提交
  5. 22 6月, 2012 1 次提交
  6. 04 6月, 2012 4 次提交
    • M
      usb: musb: host: Disable MUSB DMA mode incase of DMA channel request failure · 2ed9127c
      Mantesh Sarasetti 提交于
      Currently in case of MUSB DMA channel request failure we are not
      clearing MUSB_RXCSR_DMAENAB, MUSB_RXCSR_H_AUTOREQ and
      MUSB_RXCSR_AUTOCLEAR bits of MUSB RXCSR of MUSB DMA. Which is
      causing failure in receipt of data packets in next transfer.
      
      Fix is to disable the MUSB DMA mode and related bits incase of
      DMA channel request fails
      Signed-off-by: NMantesh Sarashetti <mantesh@ti.com>
      Signed-off-by: NRuslan Bilovol <ruslan.bilovol@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2ed9127c
    • 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
    • J
      usb: musb: davinci: Fix build breakage · 6594b2d7
      Jon Povey 提交于
      This appears to have been broken by
      commit 5cfb19ac
      (ARM: davinci: streamline sysmod access)
      
      For now, fix by hardcoding USB_PHY_CTRL and DM355_DEEPSLEEP
      
      Tested on DM365 with defconfig changes.
      Signed-off-by: NJon Povey <jon.povey@racelogic.co.uk>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      CC: Felipe Balbi <balbi@ti.com>
      Cc: <stable@vger.kernel.org> # v3.4.x
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      6594b2d7
    • 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
  7. 15 5月, 2012 1 次提交
  8. 04 5月, 2012 2 次提交
  9. 23 4月, 2012 1 次提交
  10. 18 4月, 2012 2 次提交
  11. 11 4月, 2012 6 次提交
    • S
      usb: musb: omap: fix the error check for pm_runtime_get_sync · ad579699
      Shubhrajyoti D 提交于
      pm_runtime_get_sync returns a signed integer. In case of errors
      it returns a negative value. This patch fixes the error check
      by making it signed instead of unsigned thus preventing register
      access if get_sync_fails. Also passes the error cause to the
      debug message.
      
      Cc: stable@vger.kernel.org
      Cc:  Kishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      ad579699
    • K
      usb: musb: omap: fix crash when musb glue (omap) gets initialized · 3006dc8c
      Kishon Vijay Abraham I 提交于
      pm_runtime_enable is being called after omap2430_musb_init. Hence
      pm_runtime_get_sync in omap2430_musb_init does not have any effect (does
      not enable clocks) resulting in a crash during register access. It is
      fixed here.
      
      Cc: stable@vger.kernel.org # v3.0, v3.1, v3.2, v3.3
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      3006dc8c
    • G
      usb: musb: wake the device before ulpi transfers · bf070bc1
      Grazvydas Ignotas 提交于
      musb can be suspended at the time some other driver wants to do ulpi
      transfers using usb_phy_io_* functions, and that can cause data abort,
      as it happened with isp1704_charger:
      http://article.gmane.org/gmane.linux.kernel/1226122
      
      Add pm_runtime to ulpi functions to rectify this. This also adds io_dev
      to usb_phy so that pm_runtime_* functions can be used.
      
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      bf070bc1
    • A
      usb: musb: fix bug in musb_cleanup_urb · 692933b2
      Ajay Kumar Gupta 提交于
      Control transfers with data expected from device to host will use usb_rcvctrlpipe()
      for urb->pipe so for such urbs 'is_in' will be set causing control urb to fall
      into the first "if" condition in musb_cleanup_urb().
      
      Fixed by adding logic to check for non control endpoints.
      Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      692933b2
    • G
      usb: musb: fix some runtime_pm issues · c04352a5
      Grazvydas Ignotas 提交于
      When runtime_pm was originally added, it was done in rather confusing
      way: omap2430_musb_init() (called from musb_init_controller) would do
      runtime_pm_get_sync() and musb_init_controller() itself would do
      runtime_pm_put to balance it out. This is not only confusing but also
      wrong if non-omap2430 glue layer is used.
      
      This confusion resulted in commit 772aed45 "usb: musb: fix
      pm_runtime mismatch", that removed runtime_pm_put() from
      musb_init_controller as that looked unbalanced, and also happened to
      fix unrelated isp1704_charger crash. However this broke runtime PM
      functionality (musb is now always powered, even without gadget active).
      
      Avoid these confusing runtime pm dependences by making
      musb_init_controller() and omap2430_musb_init() do their own runtime
      get/put pairs; also cover error paths. Remove unneeded runtime_pm_put
      in omap2430_remove too. isp1704_charger crash that motivated
      772aed45 will be fixed by following patch.
      
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c04352a5
    • V
      usb: musb: fix oops on omap2430 module unload · afb76df1
      Vladimir Zapolskiy 提交于
      This change prevents runtime suspend and resume actual execution, if
      omap2430 controller driver is loaded after musb-hdrc, and therefore the
      controller isn't initialized properly.
      
      The problem is reproducible with 3.1.y and 3.2 kernels.
      
      Kernel configuration of musb:
      
        % cat .config | egrep 'MUSB|GADGET'
        CONFIG_USB_MUSB_HDRC=y
        # CONFIG_USB_MUSB_TUSB6010 is not set
        CONFIG_USB_MUSB_OMAP2PLUS=m
        # CONFIG_USB_MUSB_AM35X is not set
        CONFIG_MUSB_PIO_ONLY=y
        CONFIG_USB_GADGET=y
        # CONFIG_USB_GADGET_DEBUG is not set
        # CONFIG_USB_GADGET_DEBUG_FILES is not set
        # CONFIG_USB_GADGET_DEBUG_FS is not set
        CONFIG_USB_GADGET_VBUS_DRAW=2
        CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
        CONFIG_USB_GADGET_MUSB_HDRC=m
        CONFIG_USB_GADGET_DUALSPEED=y
        CONFIG_USB_GADGETFS=m
        # CONFIG_USB_MIDI_GADGET is not set
      
      Fixes the following oops on module unloading:
      
        Unable to handle kernel NULL pointer dereference at virtual address 00000220
        ----8<----
        [<bf162088>] (omap2430_runtime_resume+0x24/0x54 [omap2430]) from [<c0302e34>] (pm_generic_runtime_resume+0x3c/0x50)
        [<c0302e34>] (pm_generic_runtime_resume+0x3c/0x50) from [<c0031a24>] (_od_runtime_resume+0x28/0x2c)
        [<c0031a24>] (_od_runtime_resume+0x28/0x2c) from [<c0306cb0>] (__rpm_callback+0x60/0xa0)
        [<c0306cb0>] (__rpm_callback+0x60/0xa0) from [<c0307f2c>] (rpm_resume+0x3fc/0x6e4)
        [<c0307f2c>] (rpm_resume+0x3fc/0x6e4) from [<c030851c>] (__pm_runtime_resume+0x5c/0x90)
        [<c030851c>] (__pm_runtime_resume+0x5c/0x90) from [<c02fd0dc>] (__device_release_driver+0x2c/0xd0)
        [<c02fd0dc>] (__device_release_driver+0x2c/0xd0) from [<c02fda18>] (driver_detach+0xe8/0xf4)
        [<c02fda18>] (driver_detach+0xe8/0xf4) from [<c02fcf88>] (bus_remove_driver+0xa0/0x104)
        [<c02fcf88>] (bus_remove_driver+0xa0/0x104) from [<c02fde54>] (driver_unregister+0x60/0x80)
        [<c02fde54>] (driver_unregister+0x60/0x80) from [<c02ff2d4>] (platform_driver_unregister+0x1c/0x20)
        [<c02ff2d4>] (platform_driver_unregister+0x1c/0x20) from [<bf162928>] (omap2430_exit+0x14/0x1c [omap2430])
        [<bf162928>] (omap2430_exit+0x14/0x1c [omap2430]) from [<c007d8bc>] (sys_delete_module+0x1f4/0x264)
        [<c007d8bc>] (sys_delete_module+0x1f4/0x264) from [<c000f000>] (ret_fast_syscall+0x0/0x30)
      Signed-off-by: NVladimir Zapolskiy <vladimir.zapolskiy@nokia.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org # 3.1
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      afb76df1
  12. 21 3月, 2012 1 次提交
  13. 02 3月, 2012 1 次提交
  14. 27 2月, 2012 2 次提交
  15. 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
  16. 22 2月, 2012 1 次提交
  17. 13 2月, 2012 2 次提交
  18. 03 2月, 2012 1 次提交
    • C
      usb: musb: fix a build error on mips · 976d98cb
      Cong Wang 提交于
      On mips, we got:
      
      drivers/usb/musb/musb_io.h:44: error: conflicting types for 'readsl'
      arch/mips/include/asm/io.h:529: error: previous definition of 'readsl' was here
      drivers/usb/musb/musb_io.h:46: error: conflicting types for 'readsw'
      arch/mips/include/asm/io.h:528: error: previous definition of 'readsw' was here
      drivers/usb/musb/musb_io.h:48: error: conflicting types for 'readsb'
      
      so, should add !defined(CONFIG_MIPS) too.
      
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      976d98cb