Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3109175pxb; Tue, 20 Apr 2021 00:18:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWo0AL00NH/YsQ29iolEBfs5nFPGY1dQQakbPfAKT05uZpT+0DKHUZTyrAsakR/Xhxkabm X-Received: by 2002:aa7:db95:: with SMTP id u21mr30501510edt.152.1618903108787; Tue, 20 Apr 2021 00:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618903108; cv=none; d=google.com; s=arc-20160816; b=BYkG+bFQB/LPHBFJUFTQ6ziY0x4TRCaKcfOw3F+QHZjdFbtx5Uvrf62iXwxX2MAuTJ jUh5CUzFbcfvrmXynCYXRmce0TzrJ3Jz+v0aK39+TY9xfYe7oiyT6qzpDz4uc3YfyHVs g+tzD7xcanpDfKTPHCmZcZnbf0Bk5xi8Xp3F9szfQ8JVBGfAGenjn3kc/VA5ZYgSWWhK qsqd59JsUHK3WGM057zaeTUNZLxpVm0SczNHU31iNogYJLktlM3+oAFq1dtR8MER39Va zyXyb4BhX7urAVRxUTXt8enh7XL4if9y1HiVoy5DLi+M+lt9aclI0JgnN+XkOxt54r8O wbmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=8Vm9HqK4VJCno1i00etpWVnJOPPZ+kUNXIeSp6fgK58=; b=fVUSWODjgLAXDV2KjBQiuMAqbKQIHLVworjxzn0eb0LetcBP8HbJD1Nhlh2OuHoynG Xlnf7rCb8iz1d2YSm/IRI5aP9zJNKNy8D73eERVLm2971TibXQPmUV3ADcW5tNoFqUyh 0uFsTdQx2f5IgsekQT7lqcY82rkn43DjGZDD4Dvu2BXxECBWaDlF7W9n5uF5bQkpo6/c 4RB89McqdCZ4XRPr9BPj9jcOnKiR/BymSBzDYaHGr7gHlDnNlEoWGoG1uEXhSGh3Bv+i TlhmtqwJR064Q5+6m+WM4dC9FakIIvXaYj+cuvZYLEfs3GGn5h2Pe50dW4f9NlNIlK2h diig== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m11si14885890edc.435.2021.04.20.00.18.05; Tue, 20 Apr 2021 00:18:28 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230229AbhDTHPl (ORCPT + 99 others); Tue, 20 Apr 2021 03:15:41 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:60112 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229793AbhDTHPk (ORCPT ); Tue, 20 Apr 2021 03:15:40 -0400 Received: from mail-oi1-f200.google.com ([209.85.167.200]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lYkbE-0006ZW-Nj for linux-kernel@vger.kernel.org; Tue, 20 Apr 2021 07:15:08 +0000 Received: by mail-oi1-f200.google.com with SMTP id r204-20020aca44d50000b029013da91480a0so12769446oia.17 for ; Tue, 20 Apr 2021 00:15:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Vm9HqK4VJCno1i00etpWVnJOPPZ+kUNXIeSp6fgK58=; b=IJG4GNgmRzH3GGX4cyBdnNU/cd548kMSThtZA0NGnAK8hlUb2brnehg958q3PJaZOJ q8G48l1ffqYbAp9ore268SvD3htQBZ6rat5YxA9D5qF/nttPFZiBWdaDfasN3rg7gTAj +evo38bZwNjBqxUXNLDdn1g0swopkK8F2b6pcrSUrMwZNSHzApvGBRAm7kvsosWx58j5 kzFlz9W7neKneFmpdFNx4dwLThCsnWxN1G5gOCbKsXvyYpWTKvMQrdvQ8W+gK5s49onX yFMhapLL4Ma7wmvsm5qJaIqcgD5dMKH4V+doEvj8aQBQ5heG0bgbFmMw26nY+zejAuDT 2SuQ== X-Gm-Message-State: AOAM531lWv0qCa3QYvm03z8PJIxRbuO/ce95FfAUNz+DpouIpD08hyz6 kGJUNj+35oo0mZ1agAGsygIqiUIIJDJEXAyMJhFUUxUpDfckOxG7qnRbpI+U1+9YM4Nz7w8GzXt G8b3BB/GzsrlSm4Izx4uhcrpm5gl2IoakU2oOhYPyvdP9I0XyUQwEZXzkCA== X-Received: by 2002:aca:4a97:: with SMTP id x145mr2019005oia.177.1618902907785; Tue, 20 Apr 2021 00:15:07 -0700 (PDT) X-Received: by 2002:aca:4a97:: with SMTP id x145mr2018989oia.177.1618902907623; Tue, 20 Apr 2021 00:15:07 -0700 (PDT) MIME-Version: 1.0 References: <20210415114856.4555-1-chris.chiu@canonical.com> <20210415184637.GA15445@rowland.harvard.edu> <20210416153932.GD42403@rowland.harvard.edu> <20210419141921.GA133494@rowland.harvard.edu> In-Reply-To: <20210419141921.GA133494@rowland.harvard.edu> From: Chris Chiu Date: Tue, 20 Apr 2021 15:14:56 +0800 Message-ID: Subject: Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub To: Alan Stern Cc: Greg KH , m.v.b@runbox.com, hadess@hadess.net, linux-usb@vger.kernel.org, Linux Kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 19, 2021 at 10:19 PM Alan Stern wrote: > > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote: > > Sorry that I didn't make myself clear. I found that if I applied RESET_RESUME > > quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error > > disappeared. SInce the timeout is not happening for each suspend by default, > > I suspect maybe reset-resume take everything back to clean state for the hub > > and the Set-Port-Feature(suspend) can be taken care of w/o problems. > > Okay, that's a good solution for system suspend. > > > I didn't like RESET_RESUME because runtime PM would not work on the quirked > > device. > > A more interesting question is whether it will work for devices plugged > into the hub. Even though the hub won't be runtime suspended, the > things attached to it might be. > > > But if the Set-Port-Feature(suspend) can't be handled and > > skipped, I can't > > expect the runtime PM to work for all devices connected to the hub either. > > Is that right? If what I proposed in the patch can not get better > > result than existing > > quirk, I think using the RESET_RESUME would be a better option. Any suggestions? > > Try the RESET_RESUME quirk and see how well it works with runtime > suspend. > > Alan Stern [ 453.064346] usb 3-4: finish reset-resume [ 453.192387] usb 3-4: reset high-speed USB device number 2 using xhci_hcd [ 453.339916] usb 3-4: USB quirks for this device: 2 Seems that even w/ the RESET_RESUME enabled, the connected device still can runtime suspend/resume. That's acceptable to me. I'll send the patch with the reset-resume quirk later. [ 626.081068] usb 3-4.3.1: usb auto-suspend, wakeup 0 [ 632.552071] usb 3-4.3.1: usb auto-resume [ 632.617467] usb 3-4.3.1: Waited 0ms for CONNECT [ 632.617471] usb 3-4.3.1: finish resume Chris