1. 27 10月, 2014 1 次提交
  2. 29 9月, 2014 1 次提交
  3. 25 9月, 2014 1 次提交
  4. 24 9月, 2014 4 次提交
  5. 11 9月, 2014 2 次提交
  6. 23 7月, 2014 2 次提交
  7. 18 7月, 2014 1 次提交
    • A
      usb: chipidea: udc: Disable auto ZLP generation on ep0 · 953c6646
      Abbas Raza 提交于
      There are 2 methods for ZLP (zero-length packet) generation:
      1) In software
      2) Automatic generation by device controller
      
      1) is implemented in UDC driver and it attaches ZLP to IN packet if
         descriptor->size < wLength
      2) can be enabled/disabled by setting ZLT bit in the QH
      
      When gadget ffs is connected to ubuntu host, the host sends
      get descriptor request and wLength in setup packet is 255 while the
      size of descriptor which will be sent by gadget in IN packet is
      64 byte. So the composite driver sets req->zero = 1.
      In UDC driver following code will be executed then
      
              if (hwreq->req.zero && hwreq->req.length
                  && (hwreq->req.length % hwep->ep.maxpacket == 0))
                      add_td_to_list(hwep, hwreq, 0);
      
      Case-A:
      So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
      ubuntu host will request 255 byte in IN request, gadget will send 64 byte
      with ZLP and host will come to know that there is no more data.
      But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
      automatically generate the ZLP which blocks enumeration for ~6 seconds due
      to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)
      
      Case-B:
      In case when gadget ffs is connected to Apple device, Apple device sends
      setup packet with wLength=64. So descriptor->size = 64 and wLength=64
      therefore req->zero = 0 and UDC driver will not attach any ZLP to the
      IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
      further request for IN data. But ZLT=0 by default for endpoint 0 so
      hardware tries to automatically generate the ZLP which blocks enumeration
      for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
      requests (OUT/PING)
      
      According to USB2.0 specs:
      
          8.5.3.2 Variable-length Data Stage
          A control pipe may have a variable-length data phase in which the
          host requests more data than is contained in the specified data
          structure. When all of the data structure is returned to the host,
          the function should indicate that the Data stage is ended by
          returning a packet that is shorter than the MaxPacketSize for the
          pipe. If the data structure is an exact multiple of wMaxPacketSize
          for the pipe, the function will return a zero-length packet to indicate
          the end of the Data stage.
      
      In Case-A mentioned above:
      If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
      ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
      enumeration doesn't block for 6 seconds.
      
      In Case-B mentioned above:
      If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
      still blocks due to ZLP automatically generated by hardware and host not needing
      it. But if we keep software ZLP generation enabled but we set ZLT=1 for
      endpoint 0 then enumeration doesn't block for 6 seconds.
      
      So the proper solution for this issue seems to disable automatic ZLP generation
      by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
      handle the ZLP generation based on req->zero field.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAbbas Raza <Abbas_Raza@mentor.com>
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      953c6646
  8. 02 7月, 2014 1 次提交
    • P
      usb: chipidea: udc: delete td from req's td list at ep_dequeue · e4adcff0
      Peter Chen 提交于
      We need to delete un-finished td from current request's td list
      at ep_dequeue API, otherwise, this non-user td will be remained
      at td list before this request is freed. So if we do ep_queue->
      ep_dequeue->ep_queue sequence, when the complete interrupt for
      the second ep_queue comes, we search td list for this request,
      the first td (added by the first ep_queue) will be handled, and
      its status is still active, so we will consider the this transfer
      still not be completed, but in fact, it has completed. It causes
      the peripheral side considers it never receives current data for
      this transfer.
      
      We met this problem when do "Error Recovery Test - Device Configured"
      test item for USBCV2 MSC test, the host has never received ACK for
      the IN token for CSW due to peripheral considers it does not get this
      CBW, the USBCV test log like belows:
      
      --------------------------------------------------------------------------
      INFO
      Issuing BOT MSC Reset, reset should always succeed
      INFO
      Retrieving status on CBW endpoint
      INFO
      CBW endpoint status = 0x0
      INFO
      Retrieving status on CSW endpoint
      INFO
      CSW endpoint status = 0x0
      INFO
      Issuing required command (Test Unit Ready) to verify device has recovered
      INFO
      Issuing CBW (attempt #1):
      INFO
      |----- CBW LUN                  = 0x0
      INFO
      |----- CBW Flags                = 0x0
      INFO
      |----- CBW Data Transfer Length = 0x0
      INFO
      |----- CBW CDB Length           = 0x6
      INFO
      |----- CBW CDB-00 = 0x0
      INFO
      |----- CBW CDB-01 = 0x0
      INFO
      |----- CBW CDB-02 = 0x0
      INFO
      |----- CBW CDB-03 = 0x0
      INFO
      |----- CBW CDB-04 = 0x0
      INFO
      |----- CBW CDB-05 = 0x0
      INFO
      Issuing CSW : try 1
      INFO
      CSW Bulk Request timed out!
      ERROR
      Failed CSW phase : should have been success or stall
      FAIL
      (5.3.4) The CSW status value must be 0x00, 0x01, or 0x02.
      ERROR
      BOTCommonMSCRequest failed:  error=80004000
      
      Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4adcff0
  9. 23 5月, 2014 7 次提交
  10. 25 4月, 2014 17 次提交
  11. 13 3月, 2014 3 次提交