From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Nicolas Boichat <drinkcat@chromium.org> Cc: Alan Stern <stern@rowland.harvard.edu>, linux-usb@vger.kernel.org, Mathias Nyman <mathias.nyman@linux.intel.com>, Felipe Balbi <felipe.balbi@linux.intel.com>, Eugene Korenevsky <ekorenevsky@gmail.com>, Peter Chen <peter.chen@nxp.com>, Daniel Drake <drake@endlessm.com>, Joe Perches <joe@perches.com>, Johan Hovold <johan@kernel.org>, Richard Leitner <richard.leitner@skidata.com>, lkml <linux-kernel@vger.kernel.org>, Guenter Roeck <groeck@chromium.org> Subject: Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme Date: Thu, 24 May 2018 18:21:57 +0200 [thread overview] Message-ID: <20180524162157.GA26662@kroah.com> (raw) In-Reply-To: <CANMq1KD8SpPQ7UTy2wN0J84dsA86Skmbb5q0OjkG+-BZShiv-A@mail.gmail.com> On Thu, May 24, 2018 at 07:42:00AM +0800, Nicolas Boichat wrote: > On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> 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 <drinkcat@chromium.org> > >> > --- > >> > > >> > 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. How does this device get unplugged/replugged if it is connected directly to the device? > 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. Isn't there an "internal" ACPI flag for USB ports, or is that what connect_type is? Why wouldn't that work here instead? thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Nicolas Boichat <drinkcat@chromium.org> Cc: Alan Stern <stern@rowland.harvard.edu>, linux-usb@vger.kernel.org, Mathias Nyman <mathias.nyman@linux.intel.com>, Felipe Balbi <felipe.balbi@linux.intel.com>, Eugene Korenevsky <ekorenevsky@gmail.com>, Peter Chen <peter.chen@nxp.com>, Daniel Drake <drake@endlessm.com>, Joe Perches <joe@perches.com>, Johan Hovold <johan@kernel.org>, Richard Leitner <richard.leitner@skidata.com>, lkml <linux-kernel@vger.kernel.org>, Guenter Roeck <groeck@chromium.org> Subject: usb: hub: Per-port setting to use old enumeration scheme Date: Thu, 24 May 2018 18:21:57 +0200 [thread overview] Message-ID: <20180524162157.GA26662@kroah.com> (raw) On Thu, May 24, 2018 at 07:42:00AM +0800, Nicolas Boichat wrote: > On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> 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 <drinkcat@chromium.org> > >> > --- > >> > > >> > 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. How does this device get unplugged/replugged if it is connected directly to the device? > 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. Isn't there an "internal" ACPI flag for USB ports, or is that what connect_type is? Why wouldn't that work here instead? thanks, greg k-h --- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-24 16:22 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-23 2:16 [PATCH] usb: hub: Per-port setting to use old enumeration scheme Nicolas Boichat 2018-05-23 2:16 ` Nicolas Boichat 2018-05-23 14:03 ` [PATCH] " Alan Stern 2018-05-23 14:03 ` Alan Stern 2018-05-23 16:39 ` [PATCH] " Greg Kroah-Hartman 2018-05-23 16:39 ` Greg Kroah-Hartman 2018-05-23 23:42 ` [PATCH] " Nicolas Boichat 2018-05-23 23:42 ` Nicolas Boichat 2018-05-24 14:29 ` [PATCH] " Alan Stern 2018-05-24 14:29 ` Alan Stern 2018-05-24 16:21 ` Greg Kroah-Hartman [this message] 2018-05-24 16:21 ` Greg Kroah-Hartman 2018-05-24 22:05 ` [PATCH] " Nicolas Boichat 2018-05-24 22:05 ` Nicolas Boichat 2018-05-25 6:29 ` [PATCH] " Greg Kroah-Hartman 2018-05-25 6:29 ` Greg Kroah-Hartman 2018-05-25 6:30 ` [PATCH] " Greg Kroah-Hartman 2018-05-25 6:30 ` Greg Kroah-Hartman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180524162157.GA26662@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=drake@endlessm.com \ --cc=drinkcat@chromium.org \ --cc=ekorenevsky@gmail.com \ --cc=felipe.balbi@linux.intel.com \ --cc=groeck@chromium.org \ --cc=joe@perches.com \ --cc=johan@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mathias.nyman@linux.intel.com \ --cc=peter.chen@nxp.com \ --cc=richard.leitner@skidata.com \ --cc=stern@rowland.harvard.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.