All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.