Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3681626pxv; Mon, 26 Jul 2021 09:16:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbK7zDMnN9ayhCCChXsofFOLE/a6F1OGmSoGv7L/0vL/WFLiKpwu7I69tE4JFULItba5Yb X-Received: by 2002:a50:ae02:: with SMTP id c2mr17063497edd.307.1627316211034; Mon, 26 Jul 2021 09:16:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627316211; cv=none; d=google.com; s=arc-20160816; b=EAYz8gRqjmzLdkPi30f6veDMYdFcDOLRN4Laao7vpGQGvWopVoPB8rqwF9ouqa/u6J 73aCAe8L3DzRaWISKiIu9m1xByooolpoyFHsF352n2O23+2AWRc3G7qAEwHT0Bzp8jMN NtlEFnDWDa3QMkbSo62+9jrUlWPxim0BbcotFJp3KhF+nX204g20+wyUFIOehzQDv79p GYZaGeh3AjUXww62WwwQlVf9D516nPpRalclMeDrfpmUaaGC1Fj0+WvV9MJnR7SdKF6t pvwcZGAcZVEM9gusgV2Dr0X1dCNJ/m9PbnICzGQUgrn9M8oPt3wb1QDmTyKJ74yIluWR ZdAA== 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=xjumH2SZpYFgrU2oSxemR/zWUoo0fz0SoOsTBHKQanM=; b=adoLdNB1IM32eBFgRzhJkByaFjvCJehlkp9huG67IH+R1uDPhQhGENFj3/f8/YZv2p kAEahbRiwmQm+pzEPN5Ql9fPmNUruez2iPfw/9MZSadDgBgNV70dEZOLP5W9J5wpQmPO Y0QdIb3bEVARtltH3PzvQoB8QC2fvViIub4qKF1MLm/FCTXUOcz6APnQgC31jEGexIhl 7cjnaxNfTU6Ms8HcRvTRgfxMggnDZKDE7HkOfYd13titHRn++ThUVTsjQZfe9188UNUK Aa1wRAqBo/DJ9MvERMf3xBa7aRgpHVEWZknCC/ehgLaQ1ExhHhS0t1n32NJ/3LnLRfI9 f0UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=W3AujEcj; 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 nc38si348508ejc.168.2021.07.26.09.16.27; Mon, 26 Jul 2021 09:16:51 -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=W3AujEcj; 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 S231612AbhGZPcK (ORCPT + 99 others); Mon, 26 Jul 2021 11:32:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:58348 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236953AbhGZPR5 (ORCPT ); Mon, 26 Jul 2021 11:17:57 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6E01460F38; Mon, 26 Jul 2021 15:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627315105; bh=+O4iqsSLGA+iuluJoq5VViUhM7JdFBT2Zsj69zf2bKs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W3AujEcjWkYQ9PP7LNXOvyz2x0/lN+VMOUOMCgff9ImYlIQhKQH5rwD7PGCjBIreh +xDSbKf1LY06DAPVNT7Zk/mNZMaAwc0I9lLlJcu2fueKPF+Pnn+7RbwJj9creVEReR yRfMOwdvuAqZnOrX0I+bgrtcaK44WZTWwOq12JI0= 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.4 080/108] usb: hub: Fix link power management max exit latency (MEL) calculations Date: Mon, 26 Jul 2021 17:39:21 +0200 Message-Id: <20210726153834.241087667@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153831.696295003@linuxfoundation.org> References: <20210726153831.696295003@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 @@ -46,6 +46,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 @@ -180,8 +181,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, @@ -191,35 +193,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; }