1. 18 Feb, 2014 16 commits
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: FunctionFS: staticize functions used only in f_fs.c · 10b69ce0
      Andrzej Pietrasiewicz authored
      ffs_alloc_dev and ffs_free_dev are used only in f_fs.c,
      so make them static.
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      10b69ce0
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: code cleanup · ab13cb0c
      Andrzej Pietrasiewicz authored
      Remove trailing whitespace
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      ab13cb0c
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: FunctionFS: dereference ffs_dev conditionally · ea365922
      Andrzej Pietrasiewicz authored
      ffs_dev->ffs_release_dev_callback should be accessed only if ffs_dev
      is not NULL.
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      ea365922
    • Markus Pargmann's avatar
      usb: musb: dsps, use devm_kzalloc · de9db572
      Markus Pargmann authored
      Replace kzalloc by devm_kzalloc and remove the kfree() calls.
      Signed-off-by: default avatarMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      de9db572
    • Wolfram Sang's avatar
      usb: dwc3: omap: don't check resource with devm_ioremap_resource · 30bbae9f
      Wolfram Sang authored
      devm_ioremap_resource does sanity checks on the given resource. No need to
      duplicate this in the driver.
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      30bbae9f
    • Robert Baldyga's avatar
      usb: gadget: s3c-hsotg: stall ep0 in set_halt function · c9f721b2
      Robert Baldyga authored
      When s3c_hsotg_ep_sethalt() function is called for ep0 it should be stalled
      in the same way that it is in s3c_hsotg_process_control() function, because
      SET_HALT for ep0 is delayed response for setup request. Endpoint 0, if
      halted, it doesn't need CLEAR_HALT because it clears "stalled" state
      automatically when next setup request is received.
      
      For this reason this patch moves code setting ep0 to "stalled" state to new
      function named s3c_hsotg_stall_ep0() which is called in
      s3c_hsotg_process_control() function as an immediate response for setup
      request, and in s3c_hsotg_ep_sethalt() function as a delayed response for
      setup request.
      Signed-off-by: default avatarRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      c9f721b2
    • wenlin.kang's avatar
      usb: gadget: printer: fix memory leak · 7e98f600
      wenlin.kang authored
      When read data from g_printer, we see a Segmentation fault. eg:
      
      Unable to handle kernel paging request at virtual address bf048000 pgd
      = cf038000 [bf048000] *pgd=8e8cf811, *pte=00000000, *ppte=00000000
      Internal error: Oops: 7 [#1] PREEMPT ARM Modules linked in: bluetooth
      rfcomm g_printer
      CPU: 0    Not tainted  (3.4.43-WR5.0.1.9_standard #1)
      PC is at __copy_to_user_std+0x310/0x3a8 LR is at 0x4c808010
      pc : [<c036e990>]    lr : [<4c808010>]    psr: 20000013
      sp : cf883ea8  ip : 80801018  fp : cf883f24
      r10: bf04706c  r9 : 18a21205  r8 : 21953888
      r7 : 201588aa  r6 : 5109aa16  r5 : 0705aaa2  r4 : 5140aa8a
      r3 : 0000004c  r2 : 00000fdc  r1 : bf048000  r0 : bef5fc3c
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 8f038019  DAC: 00000015 Process
      g_printer_test. (pid: 661, stack limit = 0xcf8822e8)
      Stack: (0xcf883ea8 to 0xcf884000)
      3ea0:                   bf047068 00001fff bef5ecb9 cf882000 00001fff bef5ecb9
      3ec0: 00001fff 00000000 cf2e8724 bf044d3c 80000013 80000013 00000001
      bf04706c
      3ee0: cf883f24 cf883ef0 c012e5ac c0324388 c007c8ac c0046298 00008180
      cf29b900
      3f00: 00002000 bef5ecb8 cf883f68 00000003 cf882000 cf29b900 cf883f54
      cf883f28
      3f20: c012ea08 bf044b0c c000eb88 00000000 cf883f7c 00000000 00000000
      00002000
      3f40: bef5ecb8 00000003 cf883fa4 cf883f58 c012eae8 c012e960 00000001
      bef60cb8
      3f60: 000000a8 c000eb88 00000000 00000000 cf883fa4 00000000 c014329c
      00000000
      3f80: 000000d4 41af63f0 00000003 c000eb88 cf882000 00000000 00000000
      cf883fa8
      3fa0: c000e920 c012eaa4 00000000 000000d4 00000003 bef5ecb8 00002000
      bef5ecb8
      3fc0: 00000000 000000d4 41af63f0 00000003 b6f534c0 00000000 419f9000
      00000000
      3fe0: 00000000 bef5ecac 000086d9 41a986bc 60000010 00000003 0109608a
      0088828a
      Code: f5d1f07c e8b100f0 e1a03c2e e2522020 (e8b15300) ---[ end trace
      97e2618e250e3377 ]--- Segmentation fault
      
      The root cause is the dev->rx_buffers list has been broken.
      When we call printer_read(), the following call tree is triggered:
      
      printer_read()
      	|
      	+---setup_rx_reqs(req)
      	|	|
      	|	+---usb_ep_queue(req)
      	|	|	|
      	|	|	+---...
      	|	|		|
      	|	|		+---rx_complete(req).
      	|	|
      	|	+---add the req to dev->rx_reqs_active
      	|
      	+---while(!list_empty(&dev->rx_buffers)))
      
      The route happens when we don't use DMA or fail to start DMA in USB
      driver. We can see: in the case, in rx_complete() it will add the req
      to dev->rx_buffers. meanwhile we see that we will also add the req to
      dev->rx_reqs_active after usb_ep_queue() return, so this adding will
      break the dev->rx_buffers out.
      
      After, when we call list_empty() to check dev->rx_buffers in while(),
      due to can't check correctly dev->rx_buffers, so the Segmentation fault
      occurs when copy_to_user() is called.
      Signed-off-by: default avatarwenlin.kang <wenlin.kang@windriver.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      7e98f600
    • wenlin.kang's avatar
      usb: gadget: printer: fix possible deadlock · 2c2b0425
      wenlin.kang authored
      The problem occurs in follow path.
      
      printer_read()
      	|
      	+---setup_rx_reqs()
      		|
      		+---usb_ep_queue()
      			|
      			+---...
      				|
      				+---rx_complete()
      
      Although it is clear from code, we can't get it normally.
      only when we enable some spin_lock debug config option, we can find it.
      eg:
      BUG: spinlock lockup on CPU#0, g_printer_test_/584
       lock: bf05e158, .magic: dead4ead, .owner: g_printer_test_/584, .owner_cpu: 0
      [<c0016e1c>] (unwind_backtrace+0x0/0x104) from [<c067aef8>] (dump_stack+0x20/0x24)
      [<c067aef8>] (dump_stack+0x20/0x24) from [<c0680bec>] (spin_dump+0x8c/0x94)
      [<c0680bec>] (spin_dump+0x8c/0x94) from [<c039071c>] (do_raw_spin_lock+0x128/0x154)
      [<c039071c>] (do_raw_spin_lock+0x128/0x154) from [<c0685618>] (_raw_spin_lock_irqsave+0x64/0x70)
      [<c0685618>] (_raw_spin_lock_irqsave+0x64/0x70) from [<bf05b4e8>] (rx_complete+0x54/0x10c [g_printer])
      [<bf05b4e8>] (rx_complete+0x54/0x10c [g_printer]) from [<c0480478>] (musb_g_giveback+0x78/0x88)
      [<c0480478>] (musb_g_giveback+0x78/0x88) from [<c048060c>] (rxstate+0xa0/0x10c)
      [<c048060c>] (rxstate+0xa0/0x10c) from [<c0480d50>] (musb_ep_restart+0x44/0x70)
      [<c0480d50>] (musb_ep_restart+0x44/0x70) from [<c0480fe4>] (musb_gadget_queue+0xe8/0xf8)
      [<c0480fe4>] (musb_gadget_queue+0xe8/0xf8) from [<bf05b2b0>] (setup_rx_reqs+0xa4/0x178 [g_printer])
      [<bf05b2b0>] (setup_rx_reqs+0xa4/0x178 [g_printer]) from [<bf05bb58>] (printer_read+0x9c/0x3f4 [g_printer])
      [<bf05bb58>] (printer_read+0x9c/0x3f4 [g_printer]) from [<c01387f0>] (vfs_read+0xb4/0x144)
      [<c01387f0>] (vfs_read+0xb4/0x144) from [<c01388d0>] (sys_read+0x50/0x124)
      [<c01388d0>] (sys_read+0x50/0x124) from [<c000e900>] (ret_fast_syscall+0x0/0x3c)
      
      The root cause is that we use the same lock two time in a path, so to avoid
      the deadlock, we need to unlock in setup_rx_reqs(), and only unlock.
      Signed-off-by: default avatarwenlin.kang <wenlin.kang@windriver.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      2c2b0425
    • Sachin Kamat's avatar
      usb: gadget: s3c-hsudc: remove unused label · 236064c2
      Sachin Kamat authored
      Fixes the following compilation warning:
      drivers/usb/gadget/s3c-hsudc.c: In function ‘s3c_hsudc_probe’:
      drivers/usb/gadget/s3c-hsudc.c:1347:1: warning: label ‘err_add_device’
      defined but not used [-Wunused-label]
      Signed-off-by: default avatarSachin Kamat <sachin.kamat@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      236064c2
    • Sachin Kamat's avatar
      usb: gadget: s3c2410_udc: Fix build error · e362115a
      Sachin Kamat authored
      Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'.
      Fixes the following compilation error introduced by commit e117e742
      ("usb: gadget: add "maxpacket_limit" field to struct usb_ep"):
      
      drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’:
      drivers/usb/gadget/s3c2410_udc.c:1632:3: error:
      cannot take address of bit-field ‘maxpacket’
         usb_ep_set_maxpacket_limit(&ep->ep, &ep->ep.maxpacket);
      Signed-off-by: default avatarSachin Kamat <sachin.kamat@linaro.org>
      Reviewed-by: default avatarRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      e362115a
    • Julia Lawall's avatar
      usb: gadget: fix error return code · abcdcc29
      Julia Lawall authored
      Set the return variable to an error code as done elsewhere in the function.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      (
      if@p1 (\(ret < 0\|ret != 0\))
       { ... return ret; }
      |
      ret@p1 = 0
      )
      ... when != ret = e1
          when != &ret
      *if(...)
      {
        ... when != ret = e2
            when forall
       return ret;
      }
      
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      abcdcc29
    • Jingoo Han's avatar
      usb: gadget: s3c-hsotg: use %pad for dma_addr_t · 8b3bc14f
      Jingoo Han authored
      Use %pad for dma_addr_t to avoid the following build warnings
      in printks.
      
      drivers/usb/gadget/s3c-hsotg.c: In function 's3c_hsotg_start_req'
      drivers/usb/gadget/s3c-hsotg.c:722:3: warning: format '%x' expects argument of type 'unsigned int' but argument 6 has type
      'dma_addr_t' [-Wformat]
      drivers/usb/gadget/s3c-hsotg.c:792:3: warning: format '%x' expects argument of type 'unsigned int' but argument 5 has type
      'dma_addr_t' [-Wformat]
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      8b3bc14f
    • Matt Porter's avatar
      usb: gadget: s3c-hsotg: fix build on x86 and other architectures · 1a7ed5be
      Matt Porter authored
      The readsl and writesl I/O accessors are only defined on some
      architectures. The driver currently depends on CONFIG_ARM because
      the build breaks on x86, in particular. Switch to use of ioread32_rep
      and iowrite32_rep to fix build on all architectures and remove the
      CONFIG_ARM dependency.
      
      Also update printk formatting to handle a long long dma_addr_t to avoid
      warnings on !32-bit architectures.
      Signed-off-by: default avatarMatt Porter <mporter@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      1a7ed5be
    • George Cherian's avatar
      usb: musb: musb_cppi41: Handle ISOCH differently and not use the hrtimer. · 1af54b7a
      George Cherian authored
      In case of ISOCH transfers the hrtimer workaround for the hardware issue
      is not very reliable. Instead of checking musb_is_tx_fifo_empty() in hrtimer
      routine, schedule a completion work and check the same in completion work.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      1af54b7a
    • George Cherian's avatar
      usb: musb: musb_cppi41: Make CPPI aware of high bandwidth transfers · f82503f5
      George Cherian authored
      Enable CPPI to handle high bandwidth transfers, especially to support
      webcam captures. Use a single bd to get the whole of the data in case of
      high bandwidth transfers.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      f82503f5
    • George Cherian's avatar
      usb: musb: musb_host: Enable ISOCH IN handling for AM335x host · c57c41d2
      George Cherian authored
      Enable the isochrounous IN handling for AM335x HOST.
      Reprogram CPPI to receive consecutive ISOCH frames in the same URB.
      Signed-off-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      c57c41d2
  2. 15 Feb, 2014 5 commits
  3. 11 Feb, 2014 7 commits
  4. 07 Feb, 2014 8 commits
  5. 04 Feb, 2014 4 commits