1. 25 3月, 2015 12 次提交
  2. 21 3月, 2015 1 次提交
  3. 20 3月, 2015 11 次提交
  4. 19 3月, 2015 12 次提交
  5. 18 3月, 2015 4 次提交
    • P
      usb: common: otg-fsm: only signal connect after switching to peripheral · a886bd92
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a886bd92
    • H
      uas: Add US_FL_NO_ATA_1X for Initio Corporation controllers / devices · bda13e35
      Hans de Goede 提交于
      A new uas compatible controller has shown up in some people's devices from
      the manufacturer Initio Corporation, this controller needs the US_FL_NO_ATA_1X
      quirk to work properly with uas, so add it to the uas quirks table.
      Reported-and-tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: stable@vger.kernel.org # 3.16
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bda13e35
    • A
      drm/radeon: drop ttm two ended allocation · a239118a
      Alex Deucher 提交于
      radeon_bo_create() calls radeon_ttm_placement_from_domain()
      before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
      uses the ttm bo size to determine when to select top down
      allocation but since the ttm bo is not initialized yet the
      check is always false.  It only took effect when buffers
      were validated later.  It also seemed to regress suspend
      and resume on some systems possibly due to it not
      taking effect in radeon_bo_create().
      
      radeon_bo_create() and radeon_ttm_placement_from_domain()
      need to be reworked substantially for this to be optimally
      effective.  Re-enable it at that point.
      Noticed-by: NOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      a239118a
    • B
      USB: ehci-atmel: rework clk handling · e32643a7
      Boris Brezillon 提交于
      The EHCI IP only needs the UTMI/UPLL (uclk) and the peripheral (iclk)
      clocks to work properly. Remove the useless system clock (fclk).
      
      Avoid calling set_rate on the fixed rate UTMI/IPLL clock and remove
      useless IS_ENABLED(CONFIG_COMMON_CLK) tests (all at91 platforms have been
      moved to the CCF).
      
      This patch also fixes a bug introduced by 3440ef16 (ARM: at91/dt: fix USB
      high-speed clock to select UTMI), which was leaving the usb clock
      uninitialized and preventing the OHCI driver from setting the usb clock
      rate to 48MHz.
      This bug was caused by several things:
      1/ usb clock drivers set the CLK_SET_RATE_GATE flag, which means the rate
         cannot be changed once the clock is prepared
      2/ The EHCI driver was retrieving and preparing/enabling the uhpck
         clock which was in turn preparing its parent clock (the usb clock),
         thus preventing any rate change because of 1/
      
      Fixes: 3440ef16 ("ARM: at91/dt: fix USB high-speed clock to select UTMI")
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e32643a7