Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 17 Nov 2019 10:46:19 -0500 (EST)
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Ikjoon Jang <ikjn@chromium.org>
cc:     linux-usb@vger.kernel.org, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Suwan Kim <suwan.kim027@gmail.com>,
        "Gustavo A . R . Silva" <gustavo@embeddedor.com>,
        Johan Hovold <johan@kernel.org>,
        Nicolas Boitchat <drinkcat@chromium.org>
Subject: Re: [PATCH 0/2] usb: override hub device bInterval with device node
In-Reply-To: <20191117033149.259303-1-ikjn@chromium.org>
Message-ID: <Pine.LNX.4.44L0.1911171043060.7716-100000@netrider.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, 17 Nov 2019, Ikjoon Jang wrote:

> This patchset enables hard wired hub device to use different bInterval
> from its descriptor when the hub has a combined device node.
> 
> When we know the specific hard wired hub supports changing its polling
> interval, we can adjust hub's interval to reduce the time of waking up
> from autosuspend or connect detection of HIDs.

In fact, _all_ hubs support changing the polling interval.  The value 
given in the USB spec is just an upper limit; any smaller value is 
equally acceptable.

So why are you doing this only for hard-wired hubs?  Why not for all 
hubs?

And is 250 ms really too long to wait for remote wakeup or connect 
detection?  What's the real motivation behind this change?

Alan Stern