Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1449577imm; Wed, 23 May 2018 16:44:23 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrgaA97unBcty/FQ+0CcyEI34EBXzVEnbqiduA3nJtAjbmFwyh8Qvtc6kHPE8ZO+1154LUp X-Received: by 2002:a62:3a1c:: with SMTP id h28-v6mr4774600pfa.209.1527119063658; Wed, 23 May 2018 16:44:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527119063; cv=none; d=google.com; s=arc-20160816; b=kkGsf+8tL9pMEXGxwTQ1iktT2/mDsanQWd4JjhVV6vEQWgc0RoaaCDueBz2QoQeuYw KqzDJiOUrmu6sVR9AdkTwGocuwv9TQ8EdaJEInDc/rJQyyhsJsbDi3wsDAuhzfLkyVF0 vQ17TQNlz3GdzOPooqnXtgSIYkknTMDps1HSUwtPUNjCVO1nsOVlFAin1mTgMwSCl5E7 ZvRKOBdQy1xQxor34Zrjr5xouqOj4OaC2C5kLTSb3ZCRM0PqFkdP4lHdyvP9ax0R/CdD q0zO6KTARFJKM6i9Lw4rUsXUSN2pJPs8YLrsZEW4QNtMsEsH/2IR6Z/dISLB8J3aUsLN CGYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=6zDfWw+ta6/U7788yTS1A5d4uIoWYhJq4Ql5AtqQL+U=; b=Am2v+ZeBzJvYIiyPDx+QGuKMgBoEEZ+Tle564/y84Z+aasu9ItW0qiMhfXCw5x7qnT HcTuLe39kcbZoQLhBpb5w/+LWmJSg2hr+fmvsekr6qR8DDO/4kGyPtp7Oh2z860yf7KU 6RpvaC+S/CCsDipckg3uwL54WtcPjEw2Aisb9gFV2xslywmNZ8l10yZqW64xqDS7ijh7 snM4DtBHJTWNd+mLBZ8vEeDkUwvSsMdRFaoMl1j6mRNnum/vZNcjaUy0srwMCK1kSbXT 4n0GzWPrUTTWf9gqlEdJSRJAmounxBCViS6lxPeh4DZXtDav6JViZYzUC+qzZh3QhX52 6x6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=L0FMffgH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4-v6si19913049plb.313.2018.05.23.16.44.08; Wed, 23 May 2018 16:44:23 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=L0FMffgH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935207AbeEWXmG (ORCPT + 99 others); Wed, 23 May 2018 19:42:06 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:40710 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935015AbeEWXmB (ORCPT ); Wed, 23 May 2018 19:42:01 -0400 Received: by mail-pl0-f67.google.com with SMTP id t12-v6so13955362plo.7 for ; Wed, 23 May 2018 16:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6zDfWw+ta6/U7788yTS1A5d4uIoWYhJq4Ql5AtqQL+U=; b=L0FMffgHYQGbNP1BuBQNdiEg1P01fYt8pUJOhkU0HcxMXUjommsrA2VXLkz3G7a1c/ JDyS9BKxSkZ7L4ieoGfSdhxuKqWsER8ltBzwrUZ9M1EGap5ywsiRMloRRnPw8vYQ5saj cG//q7r+Mqfh5Z4u48natTi82/9mZfryUSJ44= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6zDfWw+ta6/U7788yTS1A5d4uIoWYhJq4Ql5AtqQL+U=; b=b3eNYf4RgJtzkvEtYitfPUAzb6M+ykyV2nc75bddoPdxvfFqt8BfBoP8FSF7KFzz2P RN8lIysucOFZxkR72Q2+YUXq12cMgMLE+36eQANZ5Vy2fEHQWHkU51YCIul25alr5jYV WU8VPexxZskBPjl6Q6LPeL8nUkPt0Q/wE/hAI2VLl65RhbCl/P3/SrODcx5d6C2Q3O2k a4iGK7CP0HwKZQZwhkb1dy+sxbHVsBF2D1TIJ9wM/16+ugRFWx1VMb3CRE6SjE4Uc6Yu cRdkFlxd0k1hgkAUGklJJ68ToxOERgQss+UTxdJ2iPu8djvwpzA8KSPgrKmuruS4ZxTp Gdmg== X-Gm-Message-State: ALKqPwfI/X+a5gtRC0MdDgNqEJjYLgehHr9SwCWhSBuf1BJATet0Cc+h yGfVcwxwevXjaZlzdKb5OglYJeUI2kPzFOLAWwuZDLbnFmc= X-Received: by 2002:a17:902:7e06:: with SMTP id b6-v6mr4857523plm.151.1527118921192; Wed, 23 May 2018 16:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:26c7:0:0:0:0 with HTTP; Wed, 23 May 2018 16:42:00 -0700 (PDT) In-Reply-To: <20180523163936.GE12456@kroah.com> References: <20180523021656.122455-1-drinkcat@chromium.org> <20180523163936.GE12456@kroah.com> From: Nicolas Boichat Date: Thu, 24 May 2018 07:42:00 +0800 Message-ID: Subject: Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme To: Greg Kroah-Hartman , Alan Stern Cc: linux-usb@vger.kernel.org, Mathias Nyman , Felipe Balbi , Eugene Korenevsky , Peter Chen , Daniel Drake , Joe Perches , Johan Hovold , Richard Leitner , lkml , Guenter Roeck Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman wrote: > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote: >> On Wed, 23 May 2018, Nicolas Boichat wrote: >> >> > The "old" enumeration scheme is considerably faster (it takes >> > ~294ms instead of ~439ms to get the descriptor). >> > >> > It is currently only possible to use the old scheme globally >> > (/sys/module/usbcore/parameters/old_scheme_first), which is not >> > desirable as the new scheme was introduced to increase compatibility >> > with more devices. >> > >> > However, in our case, we care about time-to-active for a specific >> > USB device (which we make the firmware for), on a specific port >> > (that is pogo-pin based: not a standard USB port). This new >> > sysfs option makes it possible to use the old scheme on a single >> > port only. >> > >> > Signed-off-by: Nicolas Boichat >> > --- >> > >> > There are other "quirks" that we could add to reduce further >> > enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY >> > to 10ms instead of 50ms as used currently), but the logic is quite >> > similar, so it'd be good to have this reviewed first. >> >> I'm not opposed to the idea in principle, although I don't like your >> implementation because it breaks the original old_scheme_first >> parameter. I don't think it breaks the original parameter? I mean, /sys/module/usbcore/parameters/old_scheme_first is still a global default, while bit 0 of /sys/bus/usb/devices/x/y/z/quirks becomes a port-specific override. >> Let's see what some other people think. >> >> Yours is a rather special case, because you know exactly what device >> will be attached to a specific port. Still, I can see that sort of >> thing happening in constrained and special-purpose settings. >> >> How do you arrange to set the new quirk before the device is >> discovered? > > Yeah, this last question is what I had when looking at this. Or does it > not matter at first boot and only matters for wake-up? It does not matter on boot, we have plenty of time to enumerate the device. We use USB (auto-)suspend and remote wake, so no re-enumeration there either. It only matters on unplug/replug where the device needs to be re-enumerated. Somewhere in an init script, we would do this (we know in advance that usb1 port2 is the bus/port where we have our pogo-pin USB interface, so we can hard-code the path): echo 1 > /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port2/quirks We could try to add ACPI support (just like connect_type), but we don't strictly need it for our application. Thanks,