1. 14 Mar, 2017 1 commit
  2. 09 Feb, 2017 1 commit
  3. 03 Feb, 2017 4 commits
  4. 05 Jan, 2017 1 commit
    • Bin Liu's avatar
      usb: musb: dsps: implement clear_ep_rxintr() callback · c48400ba
      Bin Liu authored
      
      
      During dma teardown for dequque urb, if musb load is high, musb might
      generate bogus rx ep interrupt even when the rx fifo is flushed. In such
      case any of the follow log messages could happen.
      
          musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0
      
          musb_host_rx 1936: RX3 dma busy, csr 2020
      
      As mentioned in the current inline comment, clearing ep interrupt in the
      teardown path avoids the bogus interrupt, so implement clear_ep_rxintr()
      callback.
      
      This bug seems to be existing since the initial driver for musb support,
      but I only validated the fix back to v4.1, so only cc stable for v4.1+.
      
      cc: stable@vger.kernel.org # 4.1+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c48400ba
  5. 17 Nov, 2016 2 commits
  6. 13 Sep, 2016 2 commits
  7. 16 Jul, 2016 1 commit
  8. 27 Sep, 2015 3 commits
  9. 21 Sep, 2015 1 commit
  10. 05 Aug, 2015 1 commit
  11. 04 Aug, 2015 1 commit
  12. 07 May, 2015 2 commits
  13. 03 Apr, 2015 1 commit
  14. 24 Mar, 2015 1 commit
    • Tony Lindgren's avatar
      usb: musb: Fix fifo reads for dm816x with musb_dsps · 3e457371
      Tony Lindgren authored
      
      
      Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
      up musb-dsps with a custom read_fifo function based on the compatible
      flag.
      
      Otherwise we can get the following errors when starting dhclient on a
      asix USB Ethernet adapter:
      
      asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0xffff003c, offset 4
      
      While at it, let's also remove pointless cast of the driver data.
      
      Cc: Bin Liu <binmlist@gmail.com>
      Cc: Brian Hutchinson <b.hutchman@gmail.com>
      Cc: George Cherian <george.cherian@ti.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      3e457371
  15. 11 Mar, 2015 2 commits
  16. 10 Mar, 2015 8 commits
  17. 23 Feb, 2015 2 commits
  18. 25 Nov, 2014 1 commit
  19. 07 Nov, 2014 1 commit
  20. 03 Nov, 2014 3 commits
  21. 23 Oct, 2014 1 commit
    • Sebastian Andrzej Siewior's avatar
      usb: musb: musb_dsps: fix NULL pointer in suspend · f042e9cb
      Sebastian Andrzej Siewior authored
      
      
      So testing managed to configure musb in DMA mode but not load the
      matching cppi41 driver for DMA. This results in
      
      |musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
      |musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
      |platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
      
      which is "okay". Once the driver is loaded we re-try probing and
      everyone is happy. Until then if you try suspend say
          echo mem > /sys/power/state
      then you go boom
      
      |Unable to handle kernel NULL pointer dereference at virtual address 000003a4
      |pgd = cf50c000
      |[000003a4] *pgd=8f6a3831, *pte=00000000, *ppte=00000000
      |Internal error: Oops: 17 [#1] ARM
      |PC is at dsps_suspend+0x18/0x9c [musb_dsps]
      |LR is at dsps_suspend+0x18/0x9c [musb_dsps]
      |pc : [<bf08e268>] lr : [<bf08e268>] psr: a0000013
      |sp : cbd97e00 ip : c0af4394 fp : 00000000
      |r10: c0831d90 r9 : 00000002 r8 : cf6da410
      |r7 : c03ba4dc r6 : bf08f224 r5 : 00000000 r4 : cbc5fcd0
      |r3 : bf08e250 r2 : bf08f264 r1 : cf6da410 r0 : 00000000
      |[<bf08e268>] (dsps_suspend [musb_dsps]) from [<c03ba508>] (platform_pm_suspend+0x2c/0x54)
      |Code: e1a04000 e9900041 e2800010 eb4caa8e (e59053a4)
      
      because platform_get_drvdata(glue->musb) returns a NULL pointer as long as the
      device is not fully probed.
      
      Tested-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      f042e9cb