1. 25 11月, 2014 11 次提交
  2. 24 11月, 2014 2 次提交
  3. 21 11月, 2014 16 次提交
  4. 18 11月, 2014 7 次提交
    • G
      usb: musb: core: Disable the Interrupts till BABBLE is fully handled · f905bc68
      George Cherian 提交于
      Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
      condition. There are chances that we could get multiple interrupts
      till the time the babble recover work gets scheduled. Sometimes
      this could even end up in an endless loop making MUSB itself unusable.
      Reported-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f905bc68
    • S
      usb: musb: musb_cppi41: recognize HS devices in hostmode · 1eec34e9
      Sebastian Andrzej Siewior 提交于
      There is a poll loop for max 25us for HS devices. Now guess what, I
      tested it in gadget mode and forgot about the little detail. Nobody seem
      to have it noticed…
      This patch adds the missing logic for hostmode so it is recognized in
      host and device mode properly.
      
      Fixes: 50aea6fc ("usb: musb: cppi41: fire hrtimer according to
      programmed channel length")
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1eec34e9
    • R
      usb: musb: replace hard coded registers with defines · c2365ce5
      Roman Byshko 提交于
      musb registers can be dumped using the file regdump
      which is created in debugfs. Up to now  hard coded
      register addresses are used for that. Different glue
      layers however have different register addresses. The
      patch addresses this issue by substituting bare register
      addresses with defines.
      Signed-off-by: NRoman Byshko <rbyshko@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c2365ce5
    • S
      usb: musb: core: make sure musb is in RPM_ACTIVE on resume · a1fc1920
      Sebastian Andrzej Siewior 提交于
      On am335x-evm with musb in host mode and using it as a wakeup source the
      following happens once the CPU comes out of suspend to ram:
      |PM: Wakeup source MPU_WAKE
      |PM: noirq resume of devices complete after 15.453 msecs
      |PM: early resume of devices complete after 2.222 msecs
      |PM: resume of devices complete after 507.351 msecs
      |Restarting tasks ...
      |------------[ cut here ]------------
      |WARNING: CPU: 0 PID: 322 at drivers/usb/core/urb.c:339 usb_submit_urb+0x494/0x4c8()
      |URB cc0db380 submitted while active
      |[<c0348e64>] (usb_submit_urb) from [<c0340f94>] (hub_activate+0x2b8/0x49c)
      |[<c0340f94>] (hub_activate) from [<c03411dc>] (hub_resume+0x14/0x1c)
      |[<c03411dc>] (hub_resume) from [<c034be10>] (usb_resume_interface.isra.4+0xdc/0x110)
      |[<c034be10>] (usb_resume_interface.isra.4) from [<c034beb0>] (usb_resume_both+0x6c/0x13c)
      |[<c034beb0>] (usb_resume_both) from [<c034cca4>] (usb_runtime_resume+0x10/0x14)
      |[<c034cca4>] (usb_runtime_resume) from [<c02bbd80>] (__rpm_callback+0x2c/0x60)
      |[<c02bbd80>] (__rpm_callback) from [<c02bbdd4>] (rpm_callback+0x20/0x74)
      |[<c02bbdd4>] (rpm_callback) from [<c02bcc48>] (rpm_resume+0x380/0x548)
      |[<c02bcc48>] (rpm_resume) from [<c02bcb00>] (rpm_resume+0x238/0x548)
      |[<c02bcb00>] (rpm_resume) from [<c02bd08c>] (__pm_runtime_resume+0x64/0x94)
      |[<c02bd08c>] (__pm_runtime_resume) from [<c034b5a4>] (usb_autopm_get_interface+0x18/0x5c)
      |[<c034b5a4>] (usb_autopm_get_interface) from [<c03438b8>] (hub_thread+0x10c/0x115c)
      |[<c03438b8>] (hub_thread) from [<c005a70c>] (kthread+0xbc/0xd8)
      |---[ end trace 036aa5fe78203142 ]---
      |hub 1-0:1.0: activate --> -16
      |hub 2-0:1.0: activate --> -16
      
      The reason for this backtrace is the attempt of the USB code to resume
      the HUB twice and thus enqueue the status URB twice.
      Alan Stern was a great help by explaining how the USB code supposed to
      work and what is most likely the problem. The root problem is that after
      resume the musb runtime-suspend state remains RPM_SUSPENDED.
      According to git log it RPM was added for the omap2430 platform. If I
      understand it correct the omap2430 invokes a get on musb once a cable is
      connected and a put once the cable is gone. In between the device could
      go auto-idle/off. Not sure what happens when the device goes into suspend
      but then I guess it was gadget only.
      On DSPS I see only a get in probe and put in remove function. This would
      forbid RPM from working but then the devices enterns suspended state
      anyway :)
      
      To get rid of this warning, I set the device state to RPM_ACTIVE which
      the expected state.
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      a1fc1920
    • D
      usb: gadget: f_hid: fix error handling in ghid_setup() · 0448d38c
      Dan Carpenter 提交于
      There were a two issues here.
      
      1) We returned PTR_ERR(NULL) which means success if class_create()
         failed.
      2) If alloc_chrdev_region() failed then we should clean up before
         returning.
      
      Also kernel style is to have "error handling" as opposed to "success
      handling".  In the original code checking for "if (!status) " is
      confusing and this bad style is what lead to bug #2.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      0448d38c
    • D
      usb: gadget: f_hid: use after free in hidg_alloc_inst() · 828f6148
      Dan Carpenter 提交于
      We free "opts" on the error path and then dereference it.
      
      Fixes: 21a9476a ('usb: gadget: hid: add configfs support')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      828f6148
    • A
      usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC · efed421a
      Ashwini Pahuja 提交于
      This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core named BDC.
      BDC supports control traffic on ep0 and bulk/Int/Isoch traffic on all other
      endpoints.
      
      [ balbi@ti.com : fix build error on randconfig due to lack of
      	<linux/dmapool.h> ]
      Signed-off-by: NAshwini Pahuja <ashwini.linux@gmail.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      efed421a
  5. 15 11月, 2014 4 次提交