linux-stable.git/drivers/usb/core, branch linux-4.17.y

usb: hub: Don't wait for connect state at resume for powered-off ports

2018-08-03T05:48:00+00:00

[ Upstream commit 5d111f5190848d6fb1c414dc57797efea3526a2f ]

wait_for_connected() wait till a port change status to
USB_PORT_STAT_CONNECTION, but this is not possible if
the port is unpowered. The loop will only exit at timeout.

Such case take place if an over-current incident happen
while system is in S3. Then during resume wait_for_connected()
will wait 2s, which may be noticeable by the user.

Signed-off-by: Dominik Bozek 
Signed-off-by: Kuppuswamy Sathyanarayanan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

usb: core: handle hub C_PORT_OVER_CURRENT condition

2018-07-28T05:57:17+00:00

commit 249a32b7eeb3edb6897dd38f89651a62163ac4ed upstream.

Based on USB2.0 Spec Section 11.12.5,

  "If a hub has per-port power switching and per-port current limiting,
  an over-current on one port may still cause the power on another port
  to fall below specific minimums. In this case, the affected port is
  placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the
  port, but PORT_OVER_CURRENT is not set."

so let's check C_PORT_OVER_CURRENT too for over current condition.

Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens")
Cc: 
Tested-by: Alessandro Antenucci 
Signed-off-by: Bin Liu 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: quirks: add delay quirks for Corsair Strafe

2018-07-17T09:48:28+00:00

commit bba57eddadda936c94b5dccf73787cb9e159d0a5 upstream.

Corsair Strafe appears to suffer from the same issues
as the Corsair Strafe RGB.
Apply the same quirks (control message delay and init delay)
that the RGB version has to 1b1c:1b15.

With these quirks in place the keyboard works correctly upon
booting the system, and no longer requires reattaching the device.

Signed-off-by: Nico Sneck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

usb: do not reset if a low-speed or full-speed device timed out

2018-07-03T09:26:47+00:00

commit 6e01827ed93947895680fbdad68c072a0f4e2450 upstream.

Some low-speed and full-speed devices (for example, bluetooth)
do not have time to initialize. For them, ETIMEDOUT is a valid error.
We need to give them another try. Otherwise, they will
never be initialized correctly and in dmesg will be messages
"Bluetooth: hci0 command 0x1002 tx timeout" or similars.

Fixes: 264904ccc33c ("usb: retry reset if a device times out")
Cc: stable 
Signed-off-by: Maxim Moseychuk 
Signed-off-by: Greg Kroah-Hartman

usb: core: message: remove extra endianness conversion in usb_set_isoch_delay

2018-06-16T07:18:21+00:00

commit 48b73d0fa11aa8613d51f7be61d2fa7f0ab05fd3 upstream.

No need to do extra endianness conversion in
usb_set_isoch_delay because it is already done
in usb_control_msg()

Fixes: 886ee36e7205 ("usb: core: add support for USB_REQ_SET_ISOCH_DELAY")
Cc: Dmytro Panchenko 
Cc: Felipe Balbi 
Cc: stable  # v4.16+
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Greg Kroah-Hartman

USB: Accept bulk endpoints with 1024-byte maxpacket

2018-05-03T17:16:38+00:00

Some non-compliant high-speed USB devices have bulk endpoints with a
1024-byte maxpacket size.  Although such endpoints don't work with
xHCI host controllers, they do work with EHCI controllers.  We used to
accept these invalid sizes (with a warning), but we no longer do
because of an unintentional change introduced by commit aed9d65ac327
("USB: validate wMaxPacketValue entries in endpoint descriptors").

This patch restores the old behavior, so that people with these
peculiar devices can use them without patching their kernels by hand.

Signed-off-by: Alan Stern 
Suggested-by: Elvinas 
Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
CC: 
Signed-off-by: Greg Kroah-Hartman

usb: core: phy: add the SPDX-License-Identifier and include guard

2018-04-23T07:41:32+00:00

This clarifies the license of the code. While here also add an include
guard to the header file.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Suggested-by: Masahiro Yamada 
Signed-off-by: Martin Blumenstingl 
Signed-off-by: Greg Kroah-Hartman

usb: core: phy: add missing forward declaration for "struct device"

2018-04-22T13:01:30+00:00

Currently hcd.c is the only consumer of the usb_phy_roothub logic. This
already includes the required header files so struct device is known.
However, future consumers might not know about struct device.
Add a forward declaration for struct device to fix potential future
consumers which don't include any of the struct device API headers.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Suggested-by: Masahiro Yamada 
Signed-off-by: Martin Blumenstingl 
Signed-off-by: Greg Kroah-Hartman

usb: core: phy: make it a no-op if CONFIG_GENERIC_PHY is disabled

2018-04-22T13:01:30+00:00

If the generic PHY support is disabled the stub of devm_of_phy_get_by_index
returns ENOSYS. This corner case isn't handled properly by
usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi
(bcm2835_defconfig):

    dwc2 20980000.usb: dwc2_hcd_init() FAILED, returning -38
    dwc2: probe of 20980000.usb failed with error -38

Let usb_phy_roothub_alloc() return in case CONFIG_GENERIC_PHY is
disabled to fix this issue (compilers might even be smart enough to
optimize away most of the code within usb_phy_roothub_alloc and
usb_phy_roothub_add_phy if CONFIG_GENERIC_PHY is disabled). All
existing usb_phy_roothub_* functions are already NULL-safe, so no
special handling is required there.

Fixes: 07dbff0ddbd8 ("usb: core: add a wrapper for the USB PHYs on the HCD")
Reported-by: Stefan Wahren 
Signed-off-by: Martin Blumenstingl 
Signed-off-by: Greg Kroah-Hartman

usb: core: use phy_exit during suspend if wake up is not supported

2018-04-22T13:01:30+00:00

If the USB controller can wake up the system (which is the case for
example with the Mediatek USB3 IP) then we must not call phy_exit during
suspend to ensure that the USB controller doesn't have to re-enumerate
the devices during resume.
However, if the USB controller cannot wake up the system (which is the
case for example on various TI platforms using a dwc3 controller) then
we must call phy_exit during suspend. Otherwise the PHY driver keeps the
clocks enabled, which prevents the system from reaching the lowest power
levels in the suspend state.

Solve this by introducing two new functions in the PHY wrapper which are
dedicated to the suspend and resume handling.
If the controller can wake up the system the new usb_phy_roothub_suspend
function will simply call usb_phy_roothub_power_off. However, if wake up
is not supported by the controller it will also call
usb_phy_roothub_exit.
The also new usb_phy_roothub_resume function takes care of calling
usb_phy_roothub_init (if the controller can't wake up the system) in
addition to usb_phy_roothub_power_on.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Fixes: 178a0bce05cbc1 ("usb: core: hcd: integrate the PHY wrapper into the HCD core")
Reported-by: Roger Quadros 
Suggested-by: Roger Quadros 
Suggested-by: Chunfeng Yun 
Signed-off-by: Martin Blumenstingl 
Tested-by: Chunfeng Yun 
Reviewed-by: Roger Quadros 
Tested-by: Keerthy 
Signed-off-by: Greg Kroah-Hartman