1. 15 10月, 2013 1 次提交
  2. 11 10月, 2013 1 次提交
    • S
      usb: musb: start musb on the udc side, too · 001dd84a
      Sebastian Andrzej Siewior 提交于
      I have am335x-evm with one port running in OTG mode. Since commit
      fe4cb091 ("usb: musb: gadget: remove hcd initialization") the loaded
      gadget does non pop up on the host. All I see is
      |usb 4-5: new high-speed USB device number 52 using ehci-pci
      |usb 4-5: device descriptor read/64, error -110
      
      Since a later commit 2cc65fea ("usb: musb: add musb_host_setup() and
      musb_host_cleanup()) the gadget shows up on the host again but only
      in OTG mode (because we have the host init code running). It does not
      work in device only mode.
      If running in OTG mode and the gadget is removed and added back (rmmod
      followed by modprobe of a gadget) then the same error is pops up on the
      host side.
      
      This patch ensures that the gadget side also executes musb_start() which
      puts the chip in "connect accept" mode. With this change the device
      works in OTG & device mode and the gadget can be added & removed
      multiple times.
      A device (if musb is in OTG mode acting as a host) is only recognized if
      it is attached during module load (musb_hdrc module). After the device
      unplugged and plugged again the host does not recognize it. We get a
      buch of errors if musb running in OTG mode, attached to a host and no
      gadget is loaded. Bah.
      This is one step forward. Host & device only mode should work. I will
      look at OTG later. I looked at this before commit fe4cb091 and OTG wasn't
      working there perfectly so I am not sure that it is a regression :)
      
      Cc: <stable@vger.kernel.org> # v3.11
      Cc: Daniel Mack <zonque@gmail.com>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      001dd84a
  3. 26 9月, 2013 1 次提交
  4. 18 9月, 2013 1 次提交
    • B
      usb: musb: fix otg default state · 1374a430
      Bin Liu 提交于
      Right after the musb_hdrc driver is loaded, the otg default state
      is a_idle, and Mode=Host, which are set by musb_host_setup().
      
      This causes the following kernel message during musb gadget
      enumeration.
      
      	CAUTION: musb: Babble Interrupt Occurred
      
      This patch sets the otg default state to b_idle, and its Mode to
      Peripheral.
      
      It has been validated on TI AM335x GP EVM USB0 port with g_zero.
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1374a430
  5. 28 8月, 2013 3 次提交
  6. 14 8月, 2013 1 次提交
  7. 29 7月, 2013 1 次提交
  8. 29 5月, 2013 1 次提交
  9. 02 4月, 2013 1 次提交
  10. 22 3月, 2013 1 次提交
  11. 18 3月, 2013 8 次提交
  12. 10 1月, 2013 1 次提交
  13. 22 11月, 2012 1 次提交
  14. 31 10月, 2012 3 次提交
  15. 26 10月, 2012 1 次提交
  16. 09 8月, 2012 2 次提交
  17. 07 8月, 2012 1 次提交
  18. 03 8月, 2012 2 次提交
  19. 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
  20. 02 3月, 2012 1 次提交
  21. 27 2月, 2012 2 次提交
  22. 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
  23. 13 2月, 2012 1 次提交
  24. 31 1月, 2012 1 次提交
  25. 12 12月, 2011 1 次提交