1. 01 11月, 2012 1 次提交
    • S
      usb: musb: remove hand-crafted id handling · 2f771164
      Sebastian Andrzej Siewior 提交于
      This replaced the handcrafted id handling by the PLATFORM_DEVID_AUTO
      value which should do the same thing.
      
      This patch probably also fixes ux500 because I did not find the "musbid"
      variable to remove. And we close a tiny-unlikely race window becuase the
      old code gave the id back before device was destroyed in the remove
      case.
      
      [ balbi@ti.com : fixed up two failed hunks when applying patch ]
      
      Cc: B, Ravi <ravibabu@ti.com>
      Cc: Santhapuri, Damodar <damodar.santhapuri@ti.com>
      Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
      Cc: Bob Liu <lliubbo@gmail.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2f771164
  2. 31 10月, 2012 3 次提交
  3. 11 9月, 2012 2 次提交
  4. 31 8月, 2012 1 次提交
  5. 09 8月, 2012 3 次提交
  6. 07 8月, 2012 2 次提交
    • B
      usb: musb: Fix bad call to kfree() in musb_free · decadacb
      Brian Downing 提交于
      Commit 62285963 (usb: musb: drop a
      gigantic amount of ifdeferry) included this change:
      
          @@ -1901,11 +1844,7 @@ static void musb_free(struct musb *musb)
                          dma_controller_destroy(c);
                  }
      
          -#ifdef CONFIG_USB_MUSB_HDRC_HCD
          -       usb_put_hcd(musb_to_hcd(musb));
          -#else
                  kfree(musb);
          -#endif
           }
      
           /*
      
      Since musb comes from struct usb_hcd's hcd_priv, which is allocated on
      the end of that struct, kfree'ing it is not going to work.  Replace
      kfree(musb) with usb_put_hcd(musb_to_hcd(musb)), which appears to be
      the right thing to do here.
      Signed-off-by: NBrian Downing <bdowning@lavos.net>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      decadacb
    • F
      usb: musb: fix sparse warnings · a156544b
      Felipe Balbi 提交于
      The following warnings are fixed:
      
      drivers/usb/musb/musb_core.c:357:6: warning: symbol 'musb_otg_timer_func' was not declared. Should it be static?
      drivers/usb/musb/musb_core.c:1339:27: warning: incorrect type in initializer (different address spaces)
      drivers/usb/musb/musb_core.c:1339:27:    expected void *mbase
      drivers/usb/musb/musb_core.c:1339:27:    got void [noderef] <asn:2>*mregs
      drivers/usb/musb/musb_core.c:1347:17: warning: incorrect type in argument 1 (different address spaces)
      drivers/usb/musb/musb_core.c:1347:17:    expected void [noderef] <asn:2>*addr
      drivers/usb/musb/musb_core.c:1347:17:    got void *mbase
      drivers/usb/musb/musb_core.h:487:27: warning: incorrect type in initializer (different address spaces)
      drivers/usb/musb/musb_core.h:487:27:    expected void *mbase
      drivers/usb/musb/musb_core.h:487:27:    got void [noderef] <asn:2>*mregs
      drivers/usb/musb/musb_core.h:491:26: warning: incorrect type in argument 1 (different address spaces)
      drivers/usb/musb/musb_core.h:491:26:    expected void const [noderef] <asn:2>*addr
      drivers/usb/musb/musb_core.h:491:26:    got void *mbase
      drivers/usb/musb/tusb6010.c:270:48: warning: incorrect type in argument 2 (different address spaces)
      drivers/usb/musb/tusb6010.c:270:48:    expected void [noderef] <asn:2>*buf
      drivers/usb/musb/tusb6010.c:270:48:    got unsigned char [usertype] *[assigned] buf
      drivers/usb/musb/tusb6010.c:164:32: warning: incorrect type in argument 1 (different address spaces)
      drivers/usb/musb/tusb6010.c:164:32:    expected void *to
      drivers/usb/musb/tusb6010.c:164:32:    got void [noderef] <asn:2>*buf
      drivers/usb/musb/tusb6010.c:172:24: warning: incorrect type in argument 1 (different address spaces)
      drivers/usb/musb/tusb6010.c:172:24:    expected void *to
      drivers/usb/musb/tusb6010.c:172:24:    got void [noderef] <asn:2>*[assigned] buf
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      a156544b
  7. 03 8月, 2012 1 次提交
  8. 25 6月, 2012 1 次提交
  9. 04 5月, 2012 1 次提交
  10. 11 4月, 2012 2 次提交
    • 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
    • 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
  11. 02 3月, 2012 1 次提交
  12. 27 2月, 2012 2 次提交
  13. 13 2月, 2012 2 次提交
  14. 31 1月, 2012 1 次提交
  15. 24 1月, 2012 2 次提交
    • G
      usb: musb: fix shutdown while usb gadget is in use · 24307cae
      Grazvydas Ignotas 提交于
      If we shutdown without stopping the gadget first or removing the cable,
      gadget manages to configure itself again:
      
      root@pandora /root# poweroff
      The system is going down NOW!
      Requesting system poweroff
      [   47.714385] musb-hm halted.
      [   48.120697]  gadget: suspend
      [   48.123748]  gadget: reset config
      [   48.127227]  gadget: ecm deactivated
      [   48.130981] usb0: gether_disconnect
      [   48.281799]  gadget: high-speed config #1: CDC Ethernet (ECM)
      [   48.287872]  gadget: init ecm
      [   48.290985]  gadget: notify connect false
      [   48.295288]  gadget: notify speed 425984000
      
      This is not only unwanted, it's also happening on half-unitialized
      state, after musb_shutdown() has returned, which sometimes causes
      hardware to fail to work after reboot. Let's better properly stop
      gadget on shutdown too.
      
      This patch moves musb_gadget_cleanup out of musb_free(), which has 2
      callsites: probe error path and musb_remove. On probe error path it was
      superflous since musb_gadget_cleanup is called explicitly there, and
      musb_remove() calls musb_shutdown(), so cleanup will get called as before.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      24307cae
    • G
      usb: musb: drop superfluous pm_runtime calls around musb_shutdown · f5579787
      Grazvydas Ignotas 提交于
      Since commit 4f9edd2d "usb: musb: Fix the crash issue during reboot"
      musb_shutdown() does pm_runtime_get_sync/pm_runtime_put by itself, so
      this no longer needs to be done by the caller. Also, musb_exit_debugfs()
      doesn't access the device, so just drop those runtime_pm calls.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Reviewed-by: NShubhrajyoti D <shubhrajyoti@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f5579787
  16. 13 1月, 2012 1 次提交
  17. 20 12月, 2011 1 次提交
  18. 12 12月, 2011 2 次提交
  19. 29 11月, 2011 1 次提交
    • K
      usb: musb: PM: fix context save/restore in suspend/resume path · 5d193ce8
      Kevin Hilman 提交于
      Currently the driver tries to save context in the suspend path, but
      will cause an abort if the device is already runtime suspended.  This
      happens, for example, if MUSB loaded/compiled-in, in host mode, but no
      USB devices are attached.  MUSB will be runtime suspended, but then
      attempting a system suspend will crash due to the context save
      being attempted while the device is disabled.
      
      On OMAP, as of v3.1, the driver's ->runtime_suspend() callback will be
      called late in the suspend path (by the PM domain layer) if the driver
      is not already runtime suspended, ensuring a full shutdown.
      
      Therefore, the context save is not needed in the ->suspend() method
      since it will be called in the ->runtime_suspend() method anyways
      (similarily for resume.)
      
      NOTE: this leaves the suspend/resume methods basically empty (with
            some FIXMEs and comments, but I'll leave it to the maintainers
            to decide whether to remove them.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5d193ce8
  20. 15 11月, 2011 2 次提交
  21. 08 7月, 2011 1 次提交
  22. 02 7月, 2011 5 次提交
  23. 24 6月, 2011 1 次提交
  24. 07 6月, 2011 1 次提交