public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Josua Dietze <digidietze@draisberghof.de>,
	Ben Efros <ben@pc-doctor.com>, fangxiaozhi <huananhu@huawei.com>,
	Greg KH <greg@kroah.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	Hugh Blemings <hugh@blemings.org>
Subject: Re: USB serial regression 2.6.31.1 -> 2.6.31.2
Date: Sun, 11 Oct 2009 08:18:58 +1100	[thread overview]
Message-ID: <1255209538.3387.8.camel@pasglop> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0910101220540.3859-100000@netrider.rowland.org>


> The device presented two LUNs on the mass-storage interface.  LUN 0 was 
> the emulated CDROM (named "Mass Storage") and LUN 1 was direct-access 
> (named "SD Storage").  LUN 0 appeared to work normally, although it 
> reported Not Ready, No Medium Present errors.  LUN 1 did the same 
> thing, but in its response to the REQUEST SENSE command it set the 
> additional-sense-length byte to 0x12 instead of 0x0a, for no apparent 
> reason.  This caused usb-storage to assume the device supported SANE 
> SENSE, which presumably it doesn't.

Interesting. Under the windows, the device exposes a CD-ROM (which
contains windows SW for it). It also has an micro-SD connector as some
kind of "bonus" though I've never used it.

> Further REQUEST SENSE commands therefore requested 96 bytes of data
> instead of the standard 18 bytes.  With LUN 0 this worked okay.  But 
> with LUN 1 it didn't; the device reported a failure of the REQUEST 
> SENSE.  This is what caused usb-storage to issue the device reset.

Might be interesting to see what happens with a micro-SD actually in the
slot. Also, doing a device-reset on a multi-function device because one
of the functions isn't too happy may be a tad harsh no ?

> After the reset usb-storage continued to ask for 96 bytes of sense
> data, and LUN 1 continued to fail the commands.  Hence the repeated
> resets.

Ok.

> Thus the two bugs in the Huawei device are: Incorrect 
> additional-sense-length byte for LUN 1, and incorrect CSW for a 96-byte 
> REQUEST SENSE on LUN 1.
> 
> I can see two approaches for working around this.  The first is to make
> the SENSE SENSE test more discriminating.  For example, test for
> additional-sense-length values larger than 0x12 instead of larger than
> 0x0a.  Ben Efros, would this be acceptable?
> 
> The second approach is to add a SINGLE_LUN flag to all the Huawei 
> entries in unusual_devs.h.  It's not clear that this is a good idea; if 
> one of those devices really does have an SD card then people might want 
> to be able to use it.

They do have an SD slot indeed.

Any pointer to the piece of code I can tweak to change 0xa to 0x12
(SENSE stuff) to see if that helps ?

Cheers,
Ben.

> Alan Stern
> 
> --
> 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:[~2009-10-10 21:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-10  0:25 USB serial regression 2.6.31.1 -> 2.6.31.2 Benjamin Herrenschmidt
2009-10-10  0:31 ` USB serial regression 2.6.31.1 -> 2.6.31.2 (and 2.6.32-rc3) Benjamin Herrenschmidt
2009-10-10  0:32   ` Benjamin Herrenschmidt
2009-10-10  1:56     ` Alan Stern
2009-10-10  2:03       ` Alan Stern
2009-10-10  2:48         ` Benjamin Herrenschmidt
2009-10-10  3:11         ` Benjamin Herrenschmidt
2009-10-10 16:20           ` Alan Stern
2009-10-10  2:45       ` Benjamin Herrenschmidt
2009-10-10  7:38 ` USB serial regression 2.6.31.1 -> 2.6.31.2 Josua Dietze
2009-10-10  7:41   ` Benjamin Herrenschmidt
2009-10-10  9:55     ` Oliver Neukum
2009-10-10 15:05       ` Greg KH
2009-10-10 17:05   ` Alan Stern
2009-10-10 17:43     ` Ondrej Zary
2009-10-10 20:41     ` Alan Stern
2009-10-10 21:20       ` Benjamin Herrenschmidt
2009-10-10 22:17         ` Benjamin Herrenschmidt
2009-10-11 14:45           ` Alan Stern
2009-10-10 21:18     ` Benjamin Herrenschmidt [this message]
2009-10-10 21:56     ` Benjamin Herrenschmidt
2009-10-10 22:52       ` Alan Stern
2009-10-10 23:26         ` Benjamin Herrenschmidt
2009-10-10 23:47           ` Benjamin Herrenschmidt
     [not found] <11818577.563251255220394815.JavaMail.root@mail.pc-doctor.com>
2009-10-11  0:21 ` Ben Efros
2009-10-11  5:24   ` Benjamin Herrenschmidt

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=1255209538.3387.8.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=ben@pc-doctor.com \
    --cc=digidietze@draisberghof.de \
    --cc=greg@kroah.com \
    --cc=huananhu@huawei.com \
    --cc=hugh@blemings.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox