From: James Bottomley <James.Bottomley@SteelEye.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: linux-scsi@vger.kernel.org, promise_linux@promise.com, akpm@osdl.org
Subject: Re: [PATCH] Add Promise SuperTrak EX 'stex' driver
Date: Tue, 08 Aug 2006 18:26:16 -0500 [thread overview]
Message-ID: <1155079576.26517.91.camel@mulgrave.il.steeleye.com> (raw)
In-Reply-To: <44D91667.8030000@garzik.org>
On Tue, 2006-08-08 at 18:55 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > On Tue, 2006-08-08 at 08:05 -0400, Jeff Garzik wrote:
> >> Adds the 'stex' driver for Promise SuperTrak EX storage controllers.
> >> These controllers present themselves as SCSI, though like 3ware,
> >> megaraid and others, the underlying storage may or may not be SCSI.
> >>
> >> As discussed, the block tagging stuff is a post-merge todo item.
> >
> > That's not exactly my recollection of the discussion: I thought we were
> > still discussing the chicken and egg issue (which is we have APIs to do
> > this per host tagging which stex duplicates on the grounds no-one's
> > using the current APIs). Jens and I seem to be in agreement that stex
> > should try the API's and well make any changes that become necessary to
> > block or SCSI happen.
>
> Please re-read the end of the thread. The last word was "ok, let's go
> ahead and get this merged."
Those weren't my last words ...
However, I'll take on some of this ... I'll convert the aic7xxx driver
which is our current shared host tag driver ... then you only need copy
it to do stex.
> > The error return here looks like it shouldn't be DID_ERROR either. I
> > assume the error is a format one and uncorrectable by a retry?
>
> There is only one 'case INQUIRY' in the entire driver, so I assume you
> accidentally responded to the same code segment twice.
No, sorry, misquoted ... the above comment applies to the case
PASSTHRU_CMD, which has the same problem (it would repeat a malformed
command).
> > This should be dma_alloc_coherent, not pci_alloc_consistent.
>
> This is perfectly normal and proper in a PCI-only driver. pci_xxx is
> not a deprecated API, it is a convenience API.
>
> Using dma_xxx only causes needless work.
What work? it's an exact drop in replacement. However, the only usage
of pci_xxx I'm requiring to be fixed is the pci_alloc_consistent,
primarily because pci_alloc_consistent *is* deprecated: it forces a
GFP_ATOMIC allocation of a potentially large amount of data.
dma_alloc_coherent allows you to specify gfp flags, which, in this case,
should be GFP_KERNEL.
James
next prev parent reply other threads:[~2006-08-08 23:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 12:05 [PATCH] Add Promise SuperTrak EX 'stex' driver Jeff Garzik
2006-08-08 16:11 ` James Bottomley
2006-08-08 18:09 ` James Bottomley
2006-08-08 22:55 ` Jeff Garzik
2006-08-08 23:26 ` James Bottomley [this message]
2006-08-09 1:37 ` Jeff Garzik
[not found] <NONAMEBxe2jl8n4bRNe0000069a@nonameb.ptu.promise.com>
2006-08-09 14:18 ` James Bottomley
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=1155079576.26517.91.camel@mulgrave.il.steeleye.com \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=jeff@garzik.org \
--cc=linux-scsi@vger.kernel.org \
--cc=promise_linux@promise.com \
/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