From: James Bottomley <James.Bottomley@steeleye.com>
To: Christoph Hellwig <hch@lst.de>
Cc: dledford@redhat.com, SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] fixup some tagged queuing mess
Date: 25 Aug 2003 11:00:41 -0500 [thread overview]
Message-ID: <1061827243.2044.107.camel@mulgrave> (raw)
In-Reply-To: <20030825122751.GF15506@lst.de>
On Mon, 2003-08-25 at 07:27, Christoph Hellwig wrote:
> James, can you review the code in 53c700.c? Calling scsi_activate_tcq
> in ->queuecommand rather than ->slave_configure looks rather strange to
> me..
There is a reason why it works this way (apart from history): Just
because a device says it supports TCQ in its inquiry data doesn't mean
that it actually does, so 53c700 goes through a state machine
interaction where it first tries a single tagged command, and if that
succeeds it turns on TCQ permanently.
The problem with doing this from slave_configure is that the flags
represent a state machine of the commands, so they can't be set from
there (because we passively wait for commands to come down before
changing states).
The patch:
- if(SCp->device->tagged_supported && !SCp->device->tagged_queue
+ if(SCp->device->tagged_supported && !SCp->device->simple_tags &&
Looks wrong. Shouldn't it be
if(SCp->device->tagged_supported && !(SCp->device->simple_tags ||
SCp->device->ordered_tags) &&
to pick up the two types of tag we may turn on?
Since there's also a currently unused third type of tag (head of queue)
perhaps you would be better off introducing a scsi_tag_enabled() macro
that encapsulates the logic.
James
next prev parent reply other threads:[~2003-08-25 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-25 12:27 [PATCH] fixup some tagged queuing mess Christoph Hellwig
2003-08-25 16:00 ` James Bottomley [this message]
2003-08-25 16:09 ` Doug Ledford
2003-08-25 16:22 ` James Bottomley
2003-08-25 19:32 ` Doug Ledford
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=1061827243.2044.107.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=dledford@redhat.com \
--cc=hch@lst.de \
--cc=linux-scsi@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 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.