1. 20 3月, 2015 6 次提交
    • P
      usb: common: otg-fsm: only signal connect after switching to peripheral · 990919ca
      Peter Chen 提交于
      We should signal connect (pull up dp) after we have already
      at peripheral mode, otherwise, the dp may be toggled due to
      we reset controller or do disconnect during the initialization
      for peripheral, then, the host may be confused during the
      enumeration, eg, it finds the reset can't succeed, but the
      device is still there, see below error message.
      
      hub 1-0:1.0: USB hub found
      hub 1-0:1.0: 1 port detected
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: cannot reset port 1 (err = -32)
      hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
      hub 1-0:1.0: unable to enumerate USB device on port 1
      
      Fixes: the issue existed when the otg fsm code was added.
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      990919ca
    • A
      usb: phy: Find the right match in devm_usb_phy_match · 869aee0f
      Axel Lin 提交于
      The res parameter passed to devm_usb_phy_match() is the location where the
      pointer to the usb_phy is stored, hence it needs to be dereferenced before
      comparing to the match data in order to find the correct match.
      
      Fixes: 410219dc ("usb: otg: utils: devres: Add API's to associate a device with the phy")
      Signed-off-by: NAxel Lin <axel.lin@ingics.com>
      Cc: <stable@vger.kernel.org> # v3.6+
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      869aee0f
    • P
      usb: chipidea: udc: apply new usb_udc_vbus_handler interface · 467a78c8
      Peter Chen 提交于
      It can move all pullup/pulldown operation control to udc-core
      through usb_gadget_connect/usb_gadget_disconnect according to
      vbus status.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      467a78c8
    • P
      usb: udc: add usb_udc_vbus_handler · 628ef0d2
      Peter Chen 提交于
      This commit updates udc core vbus status, and try to connect
      or disconnect gadget.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      628ef0d2
    • P
      usb: udc: store usb_udc pointer in struct usb_gadget · dfea9c94
      Peter Chen 提交于
      Instead of iterate to find usb_udc according to usb_gadget, this
      way is easier.
      
      Alan Stern suggests this way too:
      http://marc.info/?l=linux-usb&m=142168496528894&w=2Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      dfea9c94
    • V
      usb: dwc2: avoid leaking DMA channels on disconnection · 7252f1bf
      Vincent Palatin 提交于
      When the HCD is disconnected, the DMA transfers still in-flight were cleaned-up
      but the count of available DMA channels (e.g. available_host_channels) was not
      reset.
      The pool of DMA channels can be depleted when doing unclean
      disconnection of USB peripherals, and reaches the point where no
      transfer was possible until the next reboot/reload of the driver.
      
      Tested by putting a programmable USB mux on the port and randomly
      plugging/unpluging a USB HUB with USB mass-storage key, USB-audio and
      USB-ethernet dongle connected to its downstream ports, and also doing the
      disconnection early while the devices are still enumerating to get more URBs
      in-flight.
      After the patch, the devices are still enumerating after thousands of cycles,
      while the port was totally dead before.
      Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7252f1bf
  2. 14 3月, 2015 1 次提交
  3. 13 3月, 2015 9 次提交
  4. 12 3月, 2015 3 次提交
  5. 11 3月, 2015 21 次提交