From: Matthew Wilcox <willy@debian.org>
To: Mark Haverkamp <markh@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
James Bottomley <James.Bottomley@steeleye.com>,
Mark Salyzyn <mark_salyzyn@adaptec.com>
Subject: Re: [PATCH 1/3] 2.6.0 aacraid driver update
Date: Tue, 7 Oct 2003 22:39:12 +0100 [thread overview]
Message-ID: <20031007213912.GD10906@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <1065561492.29117.46.camel@markh1.pdx.osdl.net>
On Tue, Oct 07, 2003 at 02:18:12PM -0700, Mark Haverkamp wrote:
> > > - pci_unmap_single(dev->pdev, (dma_addr_t)(ulong)scsicmd->SCp.ptr,
> > > + pci_unmap_single(dev->pdev, (dma_addr_t)(unsigned long)scsicmd->SCp.ptr,
> > > scsicmd->request_bufflen,
> > > scsi_to_pci_dma_dir(scsicmd->sc_data_direction));
> I checked out this casting today. The function takes a dma_addr_t as
> the argument. You can't just pass the pointer in as is because:
>
> drivers/scsi/aacraid/aachba.c:690: warning: passing arg 2 of `pci_unmap_single'
> makes integer from pointer without a cast
>
> If you just cast the pointer to dma_addr_t you get:
>
> drivers/scsi/aacraid/aachba.c:688: warning: cast from pointer to integer of different size
>
> If you just cast to unsigned long, as in the code below, there aren't any warnings, but
> the wrong type is being passed to the function. So, I think that both the casts are
> needed.
Oops, that's not true. Try it out yourself.
int foo(short bar);
int baz(void)
{
return foo(0x12345678);
}
will truncate the argument to foo to 0x5678 before calling it by
implicitly casting to a short. So we can do just fine with:
- pci_unmap_single(dev->pdev, (dma_addr_t)(ulong)scsicmd->SCp.ptr,
+ pci_unmap_single(dev->pdev, (unsigned long)scsicmd->SCp.ptr,
scsicmd->request_bufflen,
scsi_to_pci_dma_dir(scsicmd->sc_data_direction));
Now that all that casting is out of the way, we can see this driver isn't
highmem-safe as it's storing a dma_addr_t in a pointer ... yuck.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
next prev parent reply other threads:[~2003-10-07 21:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-06 21:21 [PATCH 1/3] 2.6.0 aacraid driver update Mark Haverkamp
2003-10-06 21:55 ` Jeff Garzik
2003-10-06 22:09 ` Mark Haverkamp
2003-10-06 22:24 ` Jeff Garzik
2003-10-07 21:18 ` Mark Haverkamp
2003-10-07 21:39 ` Matthew Wilcox [this message]
2003-10-07 21:50 ` Mark Haverkamp
2003-10-07 21:39 ` Jeff Garzik
2003-10-08 17:43 ` Mark Haverkamp
-- strict thread matches above, loose matches on Subject: below --
2003-10-08 13:11 Salyzyn, Mark
2003-10-08 13:55 ` Matthew Wilcox
2003-10-08 14:23 ` Mark Haverkamp
2003-10-08 14:26 Salyzyn, Mark
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=20031007213912.GD10906@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=James.Bottomley@steeleye.com \
--cc=jgarzik@pobox.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mark_salyzyn@adaptec.com \
--cc=markh@osdl.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