LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pekka Sarnila <sarnila@adit.fi>
To: Jiri Kosina <jkosina@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] hid: quirk to fixup fullspeed interval on highspeed devices
Date: Mon, 03 Mar 2008 16:38:22 +0200	[thread overview]
Message-ID: <47CC0D5E.6040405@adit.fi> (raw)
In-Reply-To: <Pine.LNX.4.64.0803031333080.15209@jikos.suse.cz>

Hi,

thanks for the answer.

Jiri Kosina wrote:
> On Sat, 1 Mar 2008, Pekka Sarnila wrote:
> 
>> Many vendors highspeed devices give erroneously fullspeed interval value 
>> in endpoint descriptor for interrupt endpoints. This quirk fixes up that 
>> by recalculating the right value for highspeed device.
> 
> Hi Pekka,
> 
> thanks for the patch. I however think that HID code is really a wrong 
> place to to this, we really want to do this in USB core instead, as that 
> it where it belongs.

Yes, I kind of agree, but ...

> Why do you think that adding a new quirk for this device to 
> usb/core/quirks.c and then checking for it in usb_parse_endpoint() is not 
> feasible?

The quirks for usb/core (only two so far) are listed in
include/linux/usb/quirks.h. As it is states there:

/*
 * This file holds the definitions of quirks found in USB devices.
 * Only quirks that affect the whole device, not an interface,
 * belong here.
 */

There are two interfaces on this particular device. Only one interface is
HID, and the problem pertains only to that interface. Thus a class specific
quirk (HID) to eliminate the kernel tinkering with the endpoints of the
other interface (not having this problem).

This rises the question of the generality of this quirk. In this particular
case there are no interrupt endpoints on the other device. So based on this
one case it is impossible say anything on whether on devices having several
interrupt endpoints, maybe on several interfaces, the problem is device,
interface or endpoint specific. I suspect all combinations exist.
One might speculate that manufacturers are combining in to one usb.2 device
old usb.1 and new usb.2 components forgetting to update the interval value
in the firmware for the old component (I suspects this has happened in this
case: new being dvb, old ifr kbd).

If so it implies the need, not only for device or class specific, but also
interface and endpoint specific quirks. No such quirk-mechanism (to my
knowledge) exist.

Anyway, in the case of this particular device it was justified to limit
the quirk to HID-class. What to do in general is the question: My guess is
(without interface or endpoint specific quirks) class specific quirks hit
the target more precisely. But it is really only a guess.

Pekka

 
> Thanks,
> 

  reply	other threads:[~2008-03-03 14:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01 14:53 Pekka Sarnila
2008-03-03 12:50 ` Jiri Kosina
2008-03-03 14:38   ` Pekka Sarnila [this message]
2008-03-06 12:08     ` Jiri Kosina

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=47CC0D5E.6040405@adit.fi \
    --to=sarnila@adit.fi \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [patch] hid: quirk to fixup fullspeed interval on highspeed devices' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).