From: Piotr Muszynski <piotr@itg.hitachi.co.jp>
To: linux-kernel@vger.kernel.org
Subject: REQUEST_SENSE and ide-cd.c
Date: Wed, 11 Jul 2007 17:30:57 +0900 [thread overview]
Message-ID: <46949541.4040206@itg.hitachi.co.jp> (raw)
I am adding transparent ATAPI capability to USB gadget Mass Storage
driver. The idea is to pass USB traffic to block device queue as packet
requests. At the end of the queue, the requests are handled by ide-cd.c
driver.
It breaks when the ide-cd.c driver unconditionally generates
REQUEST_SENSE for requests that ended in unit attention condition.
By clearing the drive's unit attention condition, this additional
REQUEST_SENSE confuses the host, which fires it's own REQUEST_SENSE
packet, to which the drive replies with NO SENSE.
I can see three solutions:
1. Intercept the sense data returned by ide-cd.c and emulate unit
attention condition in file_storage.c driver;
2. Introduce a new request flag causing ide-cd.c to skip calling
cdrom_queue_request_sense() for flagged requests, like below:
cdrom_decode_status() 2.6.12:
- if (stat & ERR_STAT) {
+ if (stat & ERR_STAT && !(rq->flags & REQ_NO_AUTOSENSE)) {
spin_lock_irqsave(&ide_lock, flags);
blkdev_dequeue_request(rq);
HWGROUP(drive)->rq = NULL;
spin_unlock_irqrestore(&ide_lock, flags);
cdrom_queue_request_sense(drive, rq->sense, rq);
} else
cdrom_end_request(drive, 0);
3. Acknowledge that ide-cd.c was not meant to work as in (2) and search
for another mechanism. Where?
(1) would unnecessarily duplicate the drive's state. I'd rather do (3).
So far, the (2) works well, but how bad is it?
I'd greatly appreciate any critical feedback.
TIA,
Piotr Muszynski
next reply other threads:[~2007-07-11 8:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-11 8:30 Piotr Muszynski [this message]
2007-07-11 22:09 ` REQUEST_SENSE and ide-cd.c Chuck Ebbert
2007-07-12 14:36 ` [linux-usb-devel] " Alan Stern
2007-07-13 15:12 ` Alan Cox
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=46949541.4040206@itg.hitachi.co.jp \
--to=piotr@itg.hitachi.co.jp \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox