1. 21 10月, 2014 5 次提交
    • F
      usb: dwc3: gadget: fix set_halt() bug with pending transfers · 7a608559
      Felipe Balbi 提交于
      According to our Gadget Framework API documentation,
      ->set_halt() *must* return -EAGAIN if we have pending
      transfers (on either direction) or FIFO isn't empty (on
      TX endpoints).
      
      Fix this bug so that the mass storage gadget can be used
      without stall=0 parameter.
      
      This patch should be backported to all kernels since v3.2.
      
      Cc: <stable@vger.kernel.org> # v3.2+
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7a608559
    • F
      usb: dwc3: gadget: hold the lock through set_wedge()'s life · 95aa4e8d
      Felipe Balbi 提交于
      Instead of releasing the lock and calling locked
      versions of our set_halt() methods, let's hold
      the lock all the way through and call unlocked
      versions of those functions.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      95aa4e8d
    • F
      usb: dwc3: gadget: move isoc endpoint check to unlocked set_halt · 5ad02fb8
      Felipe Balbi 提交于
      __dwc3_gadget_ep_set_halt() is the function which
      handles the actual halt feature. In order to cope
      with some extra cleanup comming as a follow-up patch
      let's move the isochronous endpoint check there too.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      5ad02fb8
    • F
      usb: dwc3: ep0: hold our lock in dwc3_gadget_ep0_set_halt · 33fb691b
      Felipe Balbi 提交于
      dwc3_gadget_ep0_set_halt() will be called without
      locks held in some cases, so we must hold the lock
      on our own. While at that, also add a version without
      locks to be called in certain conditions.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      33fb691b
    • F
      usb: dwc3: trace: don't dereference pointers · 4ac4fc93
      Felipe Balbi 提交于
      The way trace works is that it won't decode strings
      until we read the actual trace. Because of that, we
      can't make assumptions of pointers still being valid
      at the time we read the trace. In order to avoid that,
      just copy all fields from every struct pointer we need
      for our traces.
      
      Ths patch fixes the following bug:
      
      [ 2940.039229] Unable to handle kernel paging request at virtual address 814efa9e
      [ 2940.046904] pgd = ec3dc000
      [ 2940.049737] [814efa9e] *pgd=00000000
      [ 2940.053552] Internal error: Oops: 5 [#1] SMP ARM
      [ 2940.058379] Modules linked in: usb_f_acm u_serial g_serial usb_f_uac2 libcomposite configfs xhci_hcd dwc3 udc_core matrix_keypad dwc3_omap lis3lv02d_i2c lis3lv02d input_polldev [last unloaded: g_audio]
      [ 2940.077238] CPU: 0 PID: 3020 Comm: tail Tainted: G        W
      3.17.0-rc5-dirty #1097
      [ 2940.085596] task: ed1b1040 ti: ed07c000 task.ti: ed07c000
      [ 2940.091258] PC is at strnlen+0x18/0x68
      [ 2940.095177] LR is at 0xfffffffe
      [ 2940.098454] pc : [<c0356df8>]    lr : [<fffffffe>]    psr: a0000013
      [ 2940.098454] sp : ed07ddb0  ip : ed07ddc0  fp : ed07ddbc
      [ 2940.110445] r10: c070ff70  r9 : ed07de70  r8 : 00000000
      [ 2940.115906] r7 : 814efa9e  r6 : ffffffff  r5 : ed4b6087  r4 : ed4b50c7
      [ 2940.122726] r3 : 00000000  r2 : 814efa9e  r1 : ffffffff  r0 : 814efa9e
      [ 2940.129546] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
      [ 2940.137000] Control: 10c5387d  Table: ac3dc059  DAC: 00000015
      [ 2940.143006] Process tail (pid: 3020, stack limit = 0xed07c248)
      [ 2940.149098] Stack: (0xed07ddb0 to 0xed07e000)
      [ 2940.153660] dda0:                                     ed07dde4 ed07ddc0 c0359628 c0356dec
      [ 2940.162203] ddc0: 00000000 ed4b50c7 bf03ae9c ed4b6087 bf03ae9e 00000002 ed07de3c ed07dde8
      [ 2940.170740] dde0: c035ab50 c0359600 ffffffff ffffffff ff0a0000 ffffffff ed07de30 ed4b5088
      [ 2940.179275] de00: ed4b50c7 00000fc0 ff0a0004 ffffffff ed4b5088 ed4b5088 00000000 00001000
      [ 2940.187810] de20: 00001008 00000fc0 ed4b5088 00000000 ed07de68 ed07de40 c00f1e64 c035a9c4
      [ 2940.196341] de40: bf03dae0 ed07de70 ed4b4000 ec25b280 ed4b4000 ec25b280 bf03dae0 ed07de9c
      [ 2940.204886] de60: ed07de78 bf033324 c00f1e0c bf03ae9c 814efa9e ed428bc0 814eca3e 00000000
      [ 2940.213428] de80: 814eba3e ed4b4000 03bd1201 c0c34790 ed07ded4 ed07dea0 c00edc0c bf0332d0
      [ 2940.221994] dea0: 000002c7 ed07df10 ed07decc ed07deb8 ed4b4000 0000209c ec278ac0 00000000
      [ 2940.230536] dec0: 00002000 ec0db340 ed07def4 ed07ded8 c00ee7ec c00eda90 c00ee7b0 ec278ac0
      [ 2940.239075] dee0: ed4b4000 000002d5 ed07df44 ed07def8 c018b8d0 c00ee7bc c0166d3c ec278af0
      [ 2940.247621] df00: 0001f090 ed07df78 000002c7 00000000 000002c8 00000000 00000000 ec0db340
      [ 2940.256173] df20: 0001f090 ed07df78 ec0db340 00002000 0001f090 00000000 ed07df74 ed07df48
      [ 2940.264729] df40: c0166e98 c018b5f4 00000001 c018535c 000168c1 00000000 ec0db340 ec0db340
      [ 2940.273284] df60: 00002000 0001f090 ed07dfa4 ed07df78 c01675c4 c0166e0c 000168c1 00000000
      [ 2940.281829] df80: 00002000 0000000a 0001f090 00000003 c000f064 ed07c000 00000000 ed07dfa8
      [ 2940.290365] dfa0: c000ede0 c0167584 00002000 0000000a 00000003 0001f090 00002000 00000000
      [ 2940.298909] dfc0: 00002000 0000000a 0001f090 00000003 7fffe000 0001e1e0 00002004 0000002f
      [ 2940.307445] dfe0: 00000000 beed38ec 000104c8 b6e6397c 40000010 00000003 00000000 00000000
      [ 2940.315992] [<c0356df8>] (strnlen) from [<c0359628>] (string.isra.8+0x34/0xe8)
      [ 2940.323534] [<c0359628>] (string.isra.8) from [<c035ab50>] (vsnprintf+0x198/0x3fc)
      [ 2940.331461] [<c035ab50>] (vsnprintf) from [<c00f1e64>] (trace_seq_printf+0x68/0x94)
      [ 2940.339494] [<c00f1e64>] (trace_seq_printf) from [<bf033324>] (ftrace_raw_output_dwc3_log_request+0x60/0x78 [dwc3])
      [ 2940.350424] [<bf033324>] (ftrace_raw_output_dwc3_log_request [dwc3]) from [<c00edc0c>] (print_trace_line+0x188/0x418)
      [ 2940.361507] [<c00edc0c>] (print_trace_line) from [<c00ee7ec>] (s_show+0x3c/0x12c)
      [ 2940.369330] [<c00ee7ec>] (s_show) from [<c018b8d0>] (seq_read+0x2e8/0x4a0)
      [ 2940.376519] [<c018b8d0>] (seq_read) from [<c0166e98>] (vfs_read+0x98/0x158)
      [ 2940.383796] [<c0166e98>] (vfs_read) from [<c01675c4>] (SyS_read+0x4c/0xa0)
      [ 2940.390981] [<c01675c4>] (SyS_read) from [<c000ede0>] (ret_fast_syscall+0x0/0x48)
      [ 2940.398792] Code: e24cb004 e3510000 e241e001 0a000011 (e5d01000)
      [ 2940.406980] ---[ end trace d8b38370fbb531f3 ]---
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      4ac4fc93
  2. 29 9月, 2014 1 次提交
  3. 25 9月, 2014 1 次提交
  4. 13 9月, 2014 1 次提交
  5. 05 9月, 2014 6 次提交
  6. 04 9月, 2014 4 次提交
  7. 21 8月, 2014 1 次提交
  8. 19 8月, 2014 1 次提交
  9. 16 7月, 2014 4 次提交
  10. 10 7月, 2014 2 次提交
  11. 01 7月, 2014 2 次提交
  12. 19 6月, 2014 3 次提交
    • G
      usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in prepare/complete · 02dae36a
      George Cherian 提交于
      The dwc3 wrapper driver should not be fiddling with the core interrupts.
      Disabling the core interrupts in prepare stops xhci from proper operation.
      So remove disable/enable of core interrupts from prepare/complete.
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      02dae36a
    • G
      usb: dwc3: dwc3-omap: Fix the crash on module removal · c5a1fbca
      George Cherian 提交于
      Following crash is seen on dwc3_omap removal
      Unable to handle kernel NULL pointer dereference at virtual address 00000018
      pgd = ec098000
      [00000018] *pgd=ad1f9831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] SMP ARM
      Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm u_ether libcomposite configfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hwdep snd_soc_omap snd_pcm_dmaengine snd_soc_core snd_compress snd_pcm snd_tim]
      CPU: 0 PID: 1296 Comm: rmmod Tainted: G        W     3.15.0-rc4-02716-g95c4e18-dirty #10
      task: ed05a080 ti: ec368000 task.ti: ec368000
      PC is at release_resource+0x14/0x7c
      LR is at release_resource+0x10/0x7c
      pc : [<c0044724>]    lr : [<c0044720>]    psr: 60000013
      sp : ec369ec0  ip : 60000013  fp : 00021008
      r10: 00000000  r9 : ec368000  r8 : c000e7a4
      r7 : 00000081  r6 : bf0062c0  r5 : ed7cd000  r4 : ed7d85c0
      r3 : 00000000  r2 : 00000000  r1 : 00000011  r0 : c086d08c
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: ac098059  DAC: 00000015
      Process rmmod (pid: 1296, stack limit = 0xec368248)
      Stack: (0xec369ec0 to 0xec36a000)
      9ec0: 00000000 00000001 ed7cd000 c034de94 ed7cd010 ed7cd000 00000000 c034e194
      9ee0: 00000000 bf0062cc ed7cd010 c03490b0 ed154cc0 ed4c2570 ed2b8410 ed156810
      ed156810 bf006d24 c034db9c c034db84 c034c518
      9f20: bf006d24 ed156810 bf006d24 c034cd2c bf006d24 bf006d68 00000800 c034c340
      9f40: 00000000 c00a9e5c 00000020 00000000 bf006d68 00000800 ec369f4c 33637764
      9f60: 616d6f5f 00000070 00000001 ec368000 ed05a080 c000e670 00000001 c0084010
      9f80: 00021088 00000800 00021088 00000081 80000010 0000e6f4 00021088 00000800
      9fa0: 00021088 c000e5e0 00021088 00000800 000210b8 00000800 e04f6d00 e04f6d00
      9fc0: 00021088 00000800 00021088 00000081 00000001 00000000 be91de08 00021008
      9fe0: 4d768880 be91dbb4 b6fc5984 4d76888c 80000010 000210b8 00000000 00000000
      [<c0044724>] (release_resource) from [<c034de94>] (platform_device_del+0x6c/0x9c)
      [<c034de94>] (platform_device_del) from [<c034e194>] (platform_device_unregister+0xc/0x18)
      [<c034e194>] (platform_device_unregister) from [<bf0062cc>] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
      [<bf0062cc>] (dwc3_omap_remove_core [dwc3_omap]) from [<c03490b0>] (device_for_each_child+0x34/0x74)
      [<c03490b0>] (device_for_each_child) from [<bf0062b4>] (dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
      [<bf0062b4>] (dwc3_omap_remove [dwc3_omap]) from [<c034db9c>] (platform_drv_remove+0x18/0x1c)
      [<c034db9c>] (platform_drv_remove) from [<c034c518>] (__device_release_driver+0x70/0xc8)
      [<c034c518>] (__device_release_driver) from [<c034cd2c>] (driver_detach+0xb4/0xb8)
      [<c034cd2c>] (driver_detach) from [<c034c340>] (bus_remove_driver+0x4c/0x90)
      [<c034c340>] (bus_remove_driver) from [<c00a9e5c>] (SyS_delete_module+0x10c/0x198)
      [<c00a9e5c>] (SyS_delete_module) from [<c000e5e0>] (ret_fast_syscall+0x0/0x48)
      Code: e1a04000 e59f0068 eb14505e e5943010 (e5932018)
      ---[ end trace 7e2a8746ff4fc811 ]---
      Segmentation fault
      
      [ balbi@ti.com : add CONFIG_OF dependency ]
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c5a1fbca
    • Z
      usb: dwc3: gadget: check link trb after free_slot is increased · 5cd8c48d
      Zhuang Jin Can 提交于
      In ISOC transfers, when free_slot points to the last TRB (i.e. Link
      TRB), and all queued requests meet Missed Interval Isoc error, busy_slot
      points to trb0.
      	busy_slot->trb0
      		   trb1
      		   ...
      	free_slot->trb31(Link TRB)
      
      After end transfer and receiving the XferNotReady event, trb_left is
      caculated as 1 which is wrong, and no TRB will be primed to the
      endpoint.
      
      The root cause is free_slot is not increased the same way as busy_slot.
      When busy_slot is increased by one, it checks if points to a link TRB
      after increasement, but free_slot checks it before increasement.
      free_slot should behave the same as busy_slot to make the trb_left
      caculation correct.
      Reviewed-by: NPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
      Signed-off-by: NJiebing Li <jiebing.li@intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      5cd8c48d
  13. 15 5月, 2014 2 次提交
  14. 26 4月, 2014 3 次提交
  15. 22 4月, 2014 4 次提交