kernel.git/drivers/usb/core/hub.c, branch linux-5.14.y

usb: hub: Disable USB 3 device initiated lpm if exit latency is too high

2021-07-21T07:11:22Z

The device initiated link power management U1/U2 states should not be enabled in case the system exit latency plus one bus interval (125us) is greater than the shortest service interval of any periodic endpoint. This is the case for both U1 and U2 sytstem exit latencies and link states. See USB 3.2 section 9.4.9 "Set Feature" for more details Note, before this patch the host and device initiated U1/U2 lpm states were both enabled with lpm. After this patch it's possible to end up with only host inititated U1/U2 lpm in case the exit latencies won't allow device initiated lpm. If this case we still want to set the udev->usb3_lpm_ux_enabled flag so that sysfs users can see the link may go to U1/U2. Signed-off-by: Mathias Nyman Cc: stable Link: https://lore.kernel.org/r/20210715150122.1995966-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: hub: Fix link power management max exit latency (MEL) calculations

2021-07-21T07:11:19Z

Maximum Exit Latency (MEL) value is used by host to know how much in advance it needs to start waking up a U1/U2 suspended link in order to service a periodic transfer in time. Current MEL calculation only includes the time to wake up the path from U1/U2 to U0. This is called tMEL1 in USB 3.1 section C 1.5.2 Total MEL = tMEL1 + tMEL2 +tMEL3 + tMEL4 which should additinally include: - tMEL2 which is the time it takes for PING message to reach device - tMEL3 time for device to process the PING and submit a PING_RESPONSE - tMEL4 time for PING_RESPONSE to traverse back upstream to host. Add the missing tMEL2, tMEL3 and tMEL4 to MEL calculation. Cc: # v3.5 Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210715150122.1995966-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.13-rc7' into usb-next

2021-06-21T08:56:05Z

We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman

usb: core: hub: Disable autosuspend for Cypress CY7C65632

2021-06-17T13:34:21Z

The Cypress CY7C65632 appears to have an issue with auto suspend and detecting devices, not too dissimilar to the SMSC 5534B hub. It is easiest to reproduce by connecting multiple mass storage devices to the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts result in the devices not being detected. It is however possible to make them appear using lsusb -v. Disabling autosuspend for this hub resolves the issue. Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") Cc: stable@vger.kernel.org Signed-off-by: Andrew Lunn Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch Signed-off-by: Greg Kroah-Hartman

driver core: Move the "removable" attribute from USB to core

2021-05-27T07:36:31Z

Move the "removable" attribute from USB to core in order to allow it to be supported by other subsystem / buses. Individual buses that want to support this attribute can populate the removable property of the device while enumerating it with the 3 possible values - - "unknown" - "fixed" - "removable" Leaving the field unchanged (i.e. "not supported") would mean that the attribute would not show up in sysfs for that device. The UAPI (location, symantics etc) for the attribute remains unchanged. Move the "removable" attribute from USB to the device core so it can be used by other subsystems / buses. By default, devices do not have a "removable" attribute in sysfs. If a subsystem or bus driver wants to support a "removable" attribute, it should call device_set_removable() before calling device_register() or device_add(), e.g.: device_set_removable(dev, DEVICE_REMOVABLE); device_register(dev); The possible values and the resulting sysfs attribute contents are: DEVICE_REMOVABLE_UNKNOWN -> "unknown" DEVICE_REMOVABLE -> "removable" DEVICE_FIXED -> "fixed" Convert the USB "removable" attribute to use this new device core functionality. There should be no user-visible change in the location or semantics of attribute for USB devices. Reviewed-by: Bjorn Helgaas Signed-off-by: Rajat Jain Link: https://lore.kernel.org/r/20210524171812.18095-1-rajatja@google.com Signed-off-by: Greg Kroah-Hartman

USB: Verify the port status when timeout happens during port suspend

2021-05-21T12:06:29Z

On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by: Alan Stern Signed-off-by: Chris Chiu Link: https://lore.kernel.org/r/20210514045405.5261-2-chris.chiu@canonical.com Signed-off-by: Greg Kroah-Hartman

usb: core: hub: fix race condition about TRSMRCY of resume

2021-05-13T14:00:24Z

This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: Reported-by: Tianping Fang Acked-by: Alan Stern Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman

usb: core: hub: Fix PM reference leak in usb_port_resume()

2021-04-09T14:03:25Z

pm_runtime_get_sync will increment pm usage counter even it failed. thus a pairing decrement is needed. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Link: https://lore.kernel.org/r/20210408130831.56239-1-cuibixuan@huawei.com Signed-off-by: Greg Kroah-Hartman

usb: core: hub: Print speed name based on ssp rate

2021-03-23T12:12:43Z

Check for usb_device->ssp_rate to print the SuperSpeed Plus signaling rate generation and lane count. Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/df0986bbe92251c104dd92e3c796df7c4f2674ce.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman

usb: core: hub: Remove port_speed_is_ssp()

2021-03-23T12:12:41Z

The get_port_ssp_rate() can replace port_speed_is_ssp(). If the port speed is detected to be in gen2x1, gen1x2, or gen2x2, then the port is operating at SuperSpeed Plus. Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/dfd61ae637597bad502d2420b4dbd3774fc76aab.1615432770.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman