Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3699566pxv; Mon, 26 Jul 2021 09:41:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlB/Vp1XPgWngP07vmtsoji95cFVT5P9BxiAaoX2DmBJPtdAGX9LqP+iiR3RBXZe9yOkNR X-Received: by 2002:a17:906:4e09:: with SMTP id z9mr17852177eju.226.1627317693610; Mon, 26 Jul 2021 09:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627317693; cv=none; d=google.com; s=arc-20160816; b=aaaWjQtBgCuGudKQHefYd6JRPR7r3UX1I/L6VmAfLTBuND1Q431e1BzaNVLcBPH+9K BFOn/uV2b7FxAL4s7dVN9CWbjT/Dp1OOs8G/5lMsJ1T7BSFxeNY+NTPUEOxqz1kBybbY yM9PaUweRTAd0M+FqMjcFxz5Ziy8PkfgX2/g1IWyByU6gMPB0DyskiMOd/cCxxG1TinW kySluYkG+1NNUbyVWxPce5K67UvfnvS7Wpo+4P9NfnFn3H4v4SaASI5yslIFh+pGuvPS gwZdgYPsnvBP8vRxBparq+iiTGojwvfus7/N3moIwkj+Qz1ufvxl1yyYIQzvJ8gtiaNO Q16Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=fYtST7xuqY08TdRcI9dOOsAre9g+cfM5YbX+twATrEs=; b=l/X+RFlAsYsaUKdYj9Hf9g0O6wZte6MI9KQV7UfglGt6lur5/TRmn9ZYfjaZZcaHVY M3TdCghbTpbDxe52iL4A4OUXFGKD5X6x3L84tGR2g70A97zD6jXiMMZvDAMt9ssGfwb/ hRu7Ow3rSxK5Ukd+Ex+6+ngpkQp8VigFTtRlgvfIIJUTCXFmJdFzOqfYgRpdFvn4mULx /3niuSiHYQNuqPOcDjM8rl9dlpIlWbsZundYCCAnFCDhF+pFH881R4ixyV1Ny0c+nOjU cWsOfut/y4ENfsze0XdC8HZ/AtchIEv1YePqLydQbVXdL0rjW2xPj7n7Bgg2+es4YuvH kLxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="uA/tg6n4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b23si426987edy.354.2021.07.26.09.40.59; Mon, 26 Jul 2021 09:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="uA/tg6n4"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239887AbhGZPyd (ORCPT + 99 others); Mon, 26 Jul 2021 11:54:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:50386 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233970AbhGZPdX (ORCPT ); Mon, 26 Jul 2021 11:33:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5704660240; Mon, 26 Jul 2021 16:13:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627316031; bh=RFeSe3TzQO9QGAIhLo9zT4xH116YiWF1JG4CxgRb2ok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uA/tg6n4Vza/g1weE7so3uJTRL1CdNTepbgSnrqQfyaq14VTKbD4vpblhy/9XNYm0 Ldd7konoMnMnyBxBZp3y0fQvYbF48NhskpvZBdPz4K2gO7a8AgTRAL4eZpoPYaP7n0 5WROkivgo8rpM9jCtVrW2C9iLYDSPrCcspXZouUc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mathias Nyman , stable@kernel.org Subject: [PATCH 5.13 162/223] usb: hub: Fix link power management max exit latency (MEL) calculations Date: Mon, 26 Jul 2021 17:39:14 +0200 Message-Id: <20210726153851.512031055@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153846.245305071@linuxfoundation.org> References: <20210726153846.245305071@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mathias Nyman commit 1bf2761c837571a66ec290fb66c90413821ffda2 upstream. 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 --- drivers/usb/core/hub.c | 52 ++++++++++++++++++++++++++----------------------- 1 file changed, 28 insertions(+), 24 deletions(-) --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -48,6 +48,7 @@ #define USB_TP_TRANSMISSION_DELAY 40 /* ns */ #define USB_TP_TRANSMISSION_DELAY_MAX 65535 /* ns */ +#define USB_PING_RESPONSE_TIME 400 /* ns */ /* Protect struct usb_device->state and ->children members * Note: Both are also protected by ->dev.sem, except that ->state can @@ -182,8 +183,9 @@ int usb_device_supports_lpm(struct usb_d } /* - * Set the Maximum Exit Latency (MEL) for the host to initiate a transition from - * either U1 or U2. + * Set the Maximum Exit Latency (MEL) for the host to wakup up the path from + * U1/U2, send a PING to the device and receive a PING_RESPONSE. + * See USB 3.1 section C.1.5.2 */ static void usb_set_lpm_mel(struct usb_device *udev, struct usb3_lpm_parameters *udev_lpm_params, @@ -193,35 +195,37 @@ static void usb_set_lpm_mel(struct usb_d unsigned int hub_exit_latency) { unsigned int total_mel; - unsigned int device_mel; - unsigned int hub_mel; /* - * Calculate the time it takes to transition all links from the roothub - * to the parent hub into U0. The parent hub must then decode the - * packet (hub header decode latency) to figure out which port it was - * bound for. - * - * The Hub Header decode latency is expressed in 0.1us intervals (0x1 - * means 0.1us). Multiply that by 100 to get nanoseconds. + * tMEL1. time to transition path from host to device into U0. + * MEL for parent already contains the delay up to parent, so only add + * the exit latency for the last link (pick the slower exit latency), + * and the hub header decode latency. See USB 3.1 section C 2.2.1 + * Store MEL in nanoseconds */ total_mel = hub_lpm_params->mel + - (hub->descriptor->u.ss.bHubHdrDecLat * 100); + max(udev_exit_latency, hub_exit_latency) * 1000 + + hub->descriptor->u.ss.bHubHdrDecLat * 100; /* - * How long will it take to transition the downstream hub's port into - * U0? The greater of either the hub exit latency or the device exit - * latency. - * - * The BOS U1/U2 exit latencies are expressed in 1us intervals. - * Multiply that by 1000 to get nanoseconds. + * tMEL2. Time to submit PING packet. Sum of tTPTransmissionDelay for + * each link + wHubDelay for each hub. Add only for last link. + * tMEL4, the time for PING_RESPONSE to traverse upstream is similar. + * Multiply by 2 to include it as well. */ - device_mel = udev_exit_latency * 1000; - hub_mel = hub_exit_latency * 1000; - if (device_mel > hub_mel) - total_mel += device_mel; - else - total_mel += hub_mel; + total_mel += (__le16_to_cpu(hub->descriptor->u.ss.wHubDelay) + + USB_TP_TRANSMISSION_DELAY) * 2; + + /* + * tMEL3, tPingResponse. Time taken by device to generate PING_RESPONSE + * after receiving PING. Also add 2100ns as stated in USB 3.1 C 1.5.2.4 + * to cover the delay if the PING_RESPONSE is queued behind a Max Packet + * Size DP. + * Note these delays should be added only once for the entire path, so + * add them to the MEL of the device connected to the roothub. + */ + if (!hub->hdev->parent) + total_mel += USB_PING_RESPONSE_TIME + 2100; udev_lpm_params->mel = total_mel; }