All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: gregkh@linuxfoundation.org, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <dave@mielke.cc>,
	<kevin.derome@epitech.eu>, <clause.andreabush@gmail.com>,
	<mengualjeanphi@free.fr>
Subject: Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk
Date: Sun, 12 Mar 2017 17:18:51 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1703121701080.22407-100000@netrider.rowland.org> (raw)
In-Reply-To: <20170312201046.4jax6q5quugvpquh@var.youpi.perso.aquilenet.fr>

On Sun, 12 Mar 2017, Samuel Thibault wrote:

> Some USB 2.0 devices erroneously report millisecond values in
> bInterval. The generic config code manages to catch most of them,
> but in some cases it's not completely enough.
> 
> The case at stake here is a USB 2.0 braille device, which wants to
> announce 10ms and thus sets bInterval to 10, but with the USB 2.0
> computation that yields to 64ms.  It happens that one can type fast
> enough to reach this interval and get the device buffers overflown,
> leading to problematic latencies.  The generic config code does not
> catch this case because the 64ms is considered a sane enough value.

Interesting.  This is a high-speed device that mistakenly uses the 
low/full-speed encoding for an interrupt bInterval value?

That's pretty unusual.  Most HID devices (which includes the Braille
devices I have heard of) run at low speed, and a few of them run at 
full speed.  I can't remember any running at high speed.

> This change thus adds a USB_QUIRK_MS_INTR_BINTERVAL quirk to mark
> devices which actually report milliseconds in bInterval, and marks
> Vario Ultra devices as needing it.
> 
> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> 
> --- a/include/linux/usb/quirks.h
> +++ b/include/linux/usb/quirks.h
> @@ -50,4 +50,10 @@
>  /* device can't handle Link Power Management */
>  #define USB_QUIRK_NO_LPM			BIT(10)
>  
> +/*
> + * Device reports its bInterval as milliseconds instead of the

This should be described as "linear frames", not "milliseconds", and 
its name should be USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL.

> + * USB 2.0 calculation.
> + */
> +#define USB_QUIRK_MS_INTR_BINTERVAL		BIT(11)
> +
>  #endif /* __LINUX_USB_QUIRKS_H */
> --- a/drivers/usb/core/config.c
> +++ b/drivers/usb/core/config.c
> @@ -280,6 +280,14 @@ static int usb_parse_endpoint(struct dev
>  
>  			/*
>  			 * Adjust bInterval for quirked devices.
> +			 */
> +			/*
> +			 * This quirk fixes bIntervals reported in ms.
> +			 */
> +			if (to_usb_device(ddev)->quirks &
> +				USB_QUIRK_MS_INTR_BINTERVAL)
> +				i = j = n;

You want to use the bInterval value the device intended to provide, not
a default value.  This should be like the microframe case, with the
value increased by 3:

				n = clamp(fls(d->bInterval) + 3, i, j);
				i = j = n;

> +			/*
>  			 * This quirk fixes bIntervals reported in
>  			 * linear microframes.
>  			 */
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -218,6 +218,14 @@ static const struct usb_device_id usb_qu
>  	/* INTEL VALUE SSD */
>  	{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
>  
> +	/* Baum Vario Ultra */
> +	{ USB_DEVICE(0x0904, 0x6101), .driver_info =
> +			USB_QUIRK_MS_INTR_BINTERVAL },
> +	{ USB_DEVICE(0x0904, 0x6102), .driver_info =
> +			USB_QUIRK_MS_INTR_BINTERVAL },
> +	{ USB_DEVICE(0x0904, 0x6103), .driver_info =
> +			USB_QUIRK_MS_INTR_BINTERVAL },

You didn't read the comment at the start of the file.  :-)  This list
is supposed to remain sorted by vendor and product ID.

Alan Stern

> +
>  	{ }  /* terminating entry must be last */
>  };
>  
> --
> 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
> 

  reply	other threads:[~2017-03-12 21:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12 20:10 [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Samuel Thibault
2017-03-12 21:18 ` Alan Stern [this message]
2017-03-12 21:42   ` Dave Mielke
2017-03-13  1:31     ` Alan Stern
2017-03-13  1:36       ` Dave Mielke
2017-03-13  1:40         ` Alan Stern
2017-03-13  1:46           ` Dave Mielke
2017-03-13 10:38             ` Dave Mielke
2017-03-14  1:43             ` Alan Stern
2017-03-14  2:20               ` Dave Mielke
2017-03-14  8:45                 ` Samuel Thibault
2017-03-13  7:05           ` Samuel Thibault
2017-03-14  1:44             ` Alan Stern
2017-03-12 21:47   ` Samuel Thibault

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=Pine.LNX.4.44L0.1703121701080.22407-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=clause.andreabush@gmail.com \
    --cc=dave@mielke.cc \
    --cc=gregkh@linuxfoundation.org \
    --cc=kevin.derome@epitech.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mengualjeanphi@free.fr \
    --cc=samuel.thibault@ens-lyon.org \
    /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.