public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Dellweg <2500@gmx.de>
To: Greg Kroah-Hartman <gregkh@suse.de>,
	Vasiliy Kulikov <segooon@gmail.com>,
	Michal Sojka <sojkam1@fel.cvut.cz>, Arnd Bergmann <arnd@arndb.de>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] enable usb control message with class specific request
Date: Thu, 22 Sep 2011 12:10:31 +0200	[thread overview]
Message-ID: <20110922121031.639006d0@horus> (raw)

Hi!
Usb devio assumes that the wIndex in every control message apart from
those flagged as USB_TYPE_VENDOR holds the number of the Interface
being addressed. This is for example not true for the class specific
request GET_DEVICE_ID in the printer class:

"The high-byte of the wIndex field is used to specify the zero-based
interface index. The low-byte of the wIndex field is used to specify
the zero-based alternate setting." [1]

In this special case it misinterpretes the alternate setting 1 for the
interface and tries to claim a nonexisting one. Therefor you won't get
the printers name.

The patch below is a minimal approach to fix this. Maybe it should be
extended to USB_TYPE_RESERVED. Maybe there should be an extended test
that knows something about specific classes.

What do you think?
regards Matthias

[1] http://www.usb.org/developers/devclass_docs/usbprint11.pdf



>From 724e3b5e8782a584a95d05bb2f44e59743ed3a72 Mon Sep 17 00:00:00 2001
From: Matthias Dellweg <2500@gmx.de>
Date: Wed, 21 Sep 2011 21:28:18 +0200
Subject: [PATCH] drivers/usb/core/devio.c: Relax test in check_ctrlrecip

The generic test for the interface is not valid when the request type is
class specific.

Signed-off-by: Matthias Dellweg <2500@gmx.de>
---
 drivers/usb/core/devio.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 37518df..4e78768 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -615,7 +615,8 @@ static int check_ctrlrecip(struct dev_state *ps, unsigned int requesttype,
         && ps->dev->state != USB_STATE_ADDRESS
         && ps->dev->state != USB_STATE_CONFIGURED)
                return -EHOSTUNREACH;
-       if (USB_TYPE_VENDOR == (USB_TYPE_MASK & requesttype))
+       if ((USB_TYPE_VENDOR == (USB_TYPE_MASK & requesttype))
+        || (USB_TYPE_CLASS == (USB_TYPE_MASK & requesttype)))
                return 0;
 
        index &= 0xff;
-- 
1.7.6.3


             reply	other threads:[~2011-09-22 10:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 10:10 Matthias Dellweg [this message]
2011-09-22 15:12 ` [PATCH] enable usb control message with class specific request Alan Stern
2011-09-22 21:56   ` Matthias Dellweg
2011-09-23  7:05     ` Matthias Dellweg
2011-09-23 16:16       ` Alan Stern
2011-09-23 17:57         ` Matthias Dellweg
2011-09-23 18:31           ` Alan Stern
2011-09-25 12:46             ` Matthias Dellweg
2011-09-26 22:34               ` [PATCH] usb/core/devio.c: Check for printer " Greg KH
2011-09-26 23:24                 ` Matthias Dellweg
2011-09-26 23:31                   ` Greg KH

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=20110922121031.639006d0@horus \
    --to=2500@gmx.de \
    --cc=arnd@arndb.de \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=segooon@gmail.com \
    --cc=sojkam1@fel.cvut.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox