Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3715060pxv; Mon, 26 Jul 2021 10:04:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqmi5JvMs6vnq0f50JDL8PuPcGMsqBXtvPc4ajft3wwlEIIeHlPKkv+Pdkb5gbqWVi1MwO X-Received: by 2002:a17:907:704d:: with SMTP id ws13mr17884756ejb.147.1627319088003; Mon, 26 Jul 2021 10:04:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627319087; cv=none; d=google.com; s=arc-20160816; b=r2icKq5L8OYfJ5Rp43aH7CvRqgSwB/o+n4V7gQJD7WIjO1pGIhOEEbyO3GKCSnyaT2 sSmQVIt8giKrZFbkO7QqcsKdIGvSGHAJ6K4s5cDVUEk7ECMGEYDqIYMpqE/Br0izHl0I GCGTuV8p32zL3oIqBHgZ/lP/d6j6c3mUjbofifP8lnES4hSRfRFIGSZCDuxlSK66rnJZ qI3tq70Sq595YfGpfG6x8HA4IlOKoZBXav95hiOSs+WLXGiZqspsjxuOPoW22Cpihbf8 exrUXEAhzBkrLYIqZJx+CKzEl/0WLMg+KM2+UbVfF70cNFnaAVWXHamFQE3hVGCnLDzj Z9aA== 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=uJFSBL2+94AOQr8QLIcWwqvGTA/J/FkuX4I98EM2W6U=; b=Sw3VDXMp9WMCzQVnu0iR+6rHGH+cvlM1JAh1uvulpELzgGYSTa7YXfEjArsNqOFnj3 CHjdlWXENc7L+ZtF3EpVjeYZrmvBHHFCc60nBH+fW9YzO/Ix+0HJPrCr+1L4FVDeNr5F B45ioeeJ8Dc9H89EbHRCZSkRwwsOjini6Q897Yb0KQU3qGI7N5VgwvH1ddypI8/BCpOt KPi4UGPtlvbX+zW5OtakfZCPO09vjr9Pa6YyOIfI3ltzG4nIrpwdeKK9sYq9YwbDXxtH aFi06h+WA4fQdAeFel6sdfr0JNw64v85GPq4sc3px9TXJ3/uYB4DLl+lqPjw1zcNJ5/X jtNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=hWx1uwSH; 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 w20si415446edr.65.2021.07.26.10.04.23; Mon, 26 Jul 2021 10:04:47 -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=hWx1uwSH; 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 S238538AbhGZPn3 (ORCPT + 99 others); Mon, 26 Jul 2021 11:43:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:39866 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238010AbhGZPYd (ORCPT ); Mon, 26 Jul 2021 11:24:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 33A7160240; Mon, 26 Jul 2021 16:05:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627315500; bh=Ef6XzsFTN0SzRw145vvrDY/2yj7hcP2A+L0i0a34XMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hWx1uwSHfoBwp+QDb7/WUjmqEvqpLV1Xkguh9DG6IGQu+k9UZagWDdOtlCN+54kHG S7AsAezxO/OWzeYMTKgdk/spL9nk9Il00hDU64NZmZ5ckVuW4bE7CRV5ZPcyM+/qOB Kv8rhBR0SWjJWNWtgitcF5kA3Q8SvOLGuJ/97kd4= 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.10 122/167] usb: hub: Fix link power management max exit latency (MEL) calculations Date: Mon, 26 Jul 2021 17:39:15 +0200 Message-Id: <20210726153843.499835843@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153839.371771838@linuxfoundation.org> References: <20210726153839.371771838@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 @@ -47,6 +47,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 @@ -181,8 +182,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, @@ -192,35 +194,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; }