An error occurred fetching the project authors.
  1. 27 Jan, 2015 1 commit
    • Amit Virdi's avatar
      usb: dwc3: gadget: Fix TRB preparation during SG · 94b762f0
      Amit Virdi authored
      commit ec512fb8 upstream.
      
      When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
      request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
      only when it is the last TRB being prepared from the last dwc3_request entry.
      
      The current implementation uses list_is_last to check if the dwc3_request is the
      last entry from the request_list. However, list_is_last returns false for the
      last entry too. This is because, while preparing the first TRB from a request,
      the function dwc3_prepare_one_trb modifies the request's next and prev pointers
      while moving the URB to req_queued. Hence, list_is_last always returns false no
      matter what.
      
      The correct way is not to access the modified pointers of dwc3_request but to
      use list_empty macro instead.
      
      Fixes: e5ba5ec8 (usb: dwc3: gadget: fix scatter gather implementation)
      Signed-off-by: default avatarAmit Virdi <amit.virdi@st.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94b762f0
  2. 14 Nov, 2014 2 commits
  3. 01 Jul, 2014 1 commit
  4. 20 Dec, 2013 1 commit
  5. 27 Sep, 2013 1 commit
  6. 04 Aug, 2013 1 commit
  7. 28 May, 2013 1 commit
  8. 18 Mar, 2013 12 commits
  9. 04 Mar, 2013 1 commit
  10. 24 Jan, 2013 1 commit
    • Felipe Balbi's avatar
      usb: dwc3: gadget: change HIRD threshold to 12 · 1a947746
      Felipe Balbi authored
      First of all, that 28 value makes no sense as
      HIRD threshold is a 4-bit value, second of all
      it's causing issues for OMAP5.
      
      Using 12 because commit cbc725b3 (usb: dwc3:
      keep default hird threshold value as 4b1100)
      had the intention of setting the maximum allowed
      value of 0xc.
      
      Also, original code has been wrong forever, so
      this should be backported as far back as
      possible.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      1a947746
  11. 18 Jan, 2013 10 commits
  12. 21 Nov, 2012 1 commit
  13. 15 Oct, 2012 1 commit
    • Felipe Balbi's avatar
      usb: dwc3: gadget: fix 'endpoint always busy' bug · 041d81f4
      Felipe Balbi authored
      If a USB transfer has already been started, meaning
      we have already issued StartTransfer command to that
      particular endpoint, DWC3_EP_BUSY flag has also
      already been set.
      
      When we try to cancel this transfer which is already
      in controller's cache, we will not receive XferComplete
      event and we must clear DWC3_EP_BUSY in order to allow
      subsequent requests to be properly started.
      
      The best place to clear that flag is right after issuing
      DWC3_DEPCMD_ENDTRANSFER.
      
      Cc: stable@vger.kernel.org # v3.4 v3.5 v3.6
      Reported-by: default avatarMoiz Sonasath <m-sonasath@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      041d81f4
  14. 06 Sep, 2012 2 commits
    • Pratyush Anand's avatar
      usb: dwc3: gadget: fix pending isoc handling · f4a53c55
      Pratyush Anand authored
      If xfernotready is received and there is no request in request_list then
      REQUEST_PENDING flag must be set, so that next request in ep queue is executed.
      
      In case of isoc transfer, if xfernotready is already elapsed and even first
      request has not been queued to request_list, then issue END TRANSFER, so that
      you can receive xfernotready again and can have notion of current microframe.
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      f4a53c55
    • Pratyush Anand's avatar
      usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced · 0416e494
      Pratyush Anand authored
      In case of ep0 out, if length is not aligned to maxpacket size then we use
      dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have
      alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to
      issue cache sync function. In fact, cache sync function will bring wrong data
      in request->buf from request->dma in this scenario.
      
      So, cache sync function must not be executed in case of ep0 bounced.
      
      Cc: <stable@vger.kernel.org> # v3.4 v3.5
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      0416e494
  15. 31 Aug, 2012 1 commit
    • Chanho Park's avatar
      usb: dwc3: set up burst size only superspeed mode · d2e9a13a
      Chanho Park authored
      When connection is established non-ss mode, endpoint.maxburst is correctly set
      to 0, this means that current code will set maxburst bitfield on DEPCFG's
      parameter 0 to the highest possible value (0x0f) which is wrong.
      
      Even though this hasn't caused any issues so far (HW seems to ignore that when
      not running in SS mode) we want to make sure maxburst bitfield is only set to
      anything other than zero if we're running on SuperSpeed mode. In order to
      achieve that, let's check for gadget's operating speed before setting maxburst
      bitfield when issuing DEPCFG command.
      
      [ balbi@ti.com : improved commit log a bit in order to clarify the situation ]
      Signed-off-by: default avatarChanho Park <chanho61.park@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      d2e9a13a
  16. 15 Aug, 2012 1 commit
    • Felipe Balbi's avatar
      usb: dwc3: gadget: warn about endpoint already enabled before changing ep name · c6f83f38
      Felipe Balbi authored
      In case some gadget driver tries to enable an endpoint
      which is already enabled, we print a nice WARN so we
      can track broken gadget drivers. The only problem is that
      we're printing the WARN when we already changed endpoint's
      name, which would result in endpoints named as:
      
      ep1in-bulk-bulk-bulk-bulk-bulk-bulk-bulk
      
      To prevent that, we will continue to print the WARN,
      but do so before changing endpoint's name and return
      early.
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      c6f83f38
  17. 09 Aug, 2012 1 commit
  18. 07 Aug, 2012 1 commit