1. 19 2月, 2014 1 次提交
    • R
      usb: musb: core: Fix remote-wakeup resume · 33f8d75f
      Roger Quadros 提交于
      During resume don't touch SUSPENDM/RESUME bits of POWER register
      while restoring controller context. These bits might be changed
      by the controller during resume operation and so will be different
      than what they were during suspend.
      
      e.g. SUSPENDM bit is set by software during USB global suspend but
      automatically cleared by the controller during remote wakeup or
      during resume. Setting this bit back while restoring context
      causes undesired behaviour. i.e. Babble interrupt is generated
      and USB is broken.
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      33f8d75f
  2. 09 1月, 2014 1 次提交
  3. 04 1月, 2014 1 次提交
  4. 27 12月, 2013 1 次提交
  5. 20 12月, 2013 1 次提交
    • D
      usb: musb: finish suspend/reset work independently from musb_hub_control() · 8ed1fb79
      Daniel Mack 提交于
      Currently, resume and reset is completed when the USB core calls back
      the root hub, asking for the port's state. This results in
      unpredictable timing of state assertion, which in turn renders some
      USB devices unusable after resume.
      
      Fix this by moving the logic to end the reset and suspend state out of
      musb_hub_control() into separate functions called from delayed workers.
      GetPortStatus only reports the current state now, without taking any
      real action.
      
      The rh_timeout variable is kept in order to define a minimum time gap
      between reset and resume only.
      
      FWIW, in my case, a Verbatim "STORE N GO" mass storage device won't
      resume cleanly without this patch.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      8ed1fb79
  6. 27 11月, 2013 2 次提交
  7. 26 11月, 2013 1 次提交
    • S
      usb: musb: only cancel work if it is initialized · 66fadea5
      Sebastian Andrzej Siewior 提交于
      Since commit c5340bd1 ("usb: musb: cancel work on removal") the workqueue
      is cancelled but then if we bail out before the workqueue is setup we
      get this:
      
      |INFO: trying to register non-static key.
      |the code is fine but needs lockdep annotation.
      |turning off the locking correctness validator.
      |CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435
      |[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec)
      |[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134)
      |[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc])
      |[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc])
      |[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
      |[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224)
      |[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c)
      |[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4)
      |[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac)
      |[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8)
      |[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c)
      |[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps])
      |[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
      |platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
      |musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
      
      This patch moves the init part to earlier part so it can be cleaned as
      part of the fail3 label because now it is surrounded by the fail4 label.
      Step two is to remove it from musb_free() and add it to the two cleanup
      paths (error path and device removal) separately.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      66fadea5
  8. 18 10月, 2013 3 次提交
  9. 12 10月, 2013 1 次提交
  10. 11 10月, 2013 2 次提交
    • 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
    • S
      usb: musb: cancel work on removal · c5340bd1
      Sebastian Andrzej Siewior 提交于
      So I captured this:
      
      |WARNING: CPU: 0 PID: 2078 at /home/bigeasy/work/new/TI/linux/lib/debugobjects.c:260 debug_print_object+0x94/0xc4()
      |ODEBUG: free active (active state 0) object type: work_struct hint: musb_irq_work+0x0/0x38 [musb_hdrc]
      |CPU: 0 PID: 2078 Comm: rmmod Not tainted 3.12.0-rc4+ #338
      |[<c0014d38>] (unwind_backtrace+0x0/0xf4) from [<c001249c>] (show_stack+0x14/0x1c)
      |[<c001249c>] (show_stack+0x14/0x1c) from [<c0037720>] (warn_slowpath_common+0x64/0x84)
      |[<c0037720>] (warn_slowpath_common+0x64/0x84) from [<c00377d4>] (warn_slowpath_fmt+0x30/0x40)
      |[<c00377d4>] (warn_slowpath_fmt+0x30/0x40) from [<c022ae90>] (debug_print_object+0x94/0xc4)
      |[<c022ae90>] (debug_print_object+0x94/0xc4) from [<c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228)
      |[<c022b7e0>] (debug_check_no_obj_freed+0x1c0/0x228) from [<c00f1f38>] (kfree+0xf8/0x228)
      |[<c00f1f38>] (kfree+0xf8/0x228) from [<c02921c4>] (release_nodes+0x1a8/0x248)
      |[<c02921c4>] (release_nodes+0x1a8/0x248) from [<c028f70c>] (__device_release_driver+0x98/0xf0)
      |[<c028f70c>] (__device_release_driver+0x98/0xf0) from [<c028f840>] (device_release_driver+0x24/0x34)
      |[<c028f840>] (device_release_driver+0x24/0x34) from [<c028ebe8>] (bus_remove_device+0x148/0x15c)
      |[<c028ebe8>] (bus_remove_device+0x148/0x15c) from [<c028d120>] (device_del+0x104/0x1c0)
      |[<c028d120>] (device_del+0x104/0x1c0) from [<c02911e4>] (platform_device_del+0x18/0xac)
      |[<c02911e4>] (platform_device_del+0x18/0xac) from [<c029179c>] (platform_device_unregister+0xc/0x18)
      |[<c029179c>] (platform_device_unregister+0xc/0x18) from [<bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps])
      |[<bf1902fc>] (dsps_remove+0x20/0x4c [musb_dsps]) from [<c0290d7c>] (platform_drv_remove+0x1c/0x24)
      |[<c0290d7c>] (platform_drv_remove+0x1c/0x24) from [<c028f704>] (__device_release_driver+0x90/0xf0)
      |[<c028f704>] (__device_release_driver+0x90/0xf0) from [<c028f818>] (driver_detach+0xb4/0xb8)
      |[<c028f818>] (driver_detach+0xb4/0xb8) from [<c028e6e8>] (bus_remove_driver+0x98/0xec)
      |[<c028e6e8>] (bus_remove_driver+0x98/0xec) from [<c008fc70>] (SyS_delete_module+0x1e0/0x24c)
      |[<c008fc70>] (SyS_delete_module+0x1e0/0x24c) from [<c000e680>] (ret_fast_syscall+0x0/0x48)
      |---[ end trace d79045419a3e51ec ]---
      
      The workqueue is only scheduled from the ep0 and never canceled in case
      the musb is removed before the work has a chance to run.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c5340bd1
  11. 30 7月, 2013 1 次提交
  12. 29 7月, 2013 4 次提交
  13. 25 7月, 2013 1 次提交
  14. 29 5月, 2013 8 次提交
  15. 22 3月, 2013 2 次提交
  16. 18 3月, 2013 3 次提交
  17. 12 3月, 2013 1 次提交
  18. 05 3月, 2013 1 次提交
    • F
      usb: musb: fix compile warning · e574d570
      Felipe Balbi 提交于
      When running 100 randconfig iterations, I found
      the following warning:
      
      drivers/usb/musb/musb_core.c: In function ‘musb_init_controller’:
      drivers/usb/musb/musb_core.c:1981:1: warning: label ‘fail5’ defined \
      	but not used [-Wunused-label]
      
      this patch fixes it by removing the unnecessary
      ifdef CONFIG_SYSFS.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e574d570
  19. 17 1月, 2013 1 次提交
  20. 18 12月, 2012 1 次提交
  21. 13 12月, 2012 1 次提交
  22. 22 11月, 2012 2 次提交