From: Tejun Heo <htejun@gmail.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
ide <linux-ide@vger.kernel.org>, Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2)
Date: Fri, 23 Nov 2007 10:17:25 +0900 [thread overview]
Message-ID: <47462A25.1060207@gmail.com> (raw)
In-Reply-To: <47462673.3080701@shaw.ca>
Robert Hancock wrote:
>>> + /* Ensure DMA mask is set to 32-bit before allocating legacy PRD
>>> and
>>> + pad buffers */
>>> + pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
>>> + pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
>> [--snip--]
>>> + pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
>>> + pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
>>
>> I'm probably being paranoid here but please add error checks. Just
>> checking return value and returning error suffices.
>
> In the 32-bit case, I'm pretty sure those are guaranteed not to fail
> because 32-bit is the default. For the 64-bit ones, we don't care if
> they fail, because then we'll just use whatever mask ends up being set
> (we store the actual set DMA mask in adma_dma_mask for use when we need
> to reconfigure the bounce limit). We definitely don't want to fail
> initialization if the 64-bit set doesn't succeed..
Then please add BUG or WARN_ON after 32bit switching (but then again if
you're gonna do that why not just add if (rc) return rc?) and add
comment stating setting 64 bit dma masks is allowed to fail.
Thanks.
--
tejun
prev parent reply other threads:[~2007-11-23 1:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-21 0:56 [PATCH] sata_nv: fix ADMA ATAPI issues with memory over 4GB (v2) Robert Hancock
2007-11-21 12:39 ` Vincent Fortier
2007-11-21 14:23 ` Robert Hancock
2007-11-22 6:35 ` Tejun Heo
2007-11-23 1:01 ` Robert Hancock
2007-11-23 1:17 ` Tejun Heo [this message]
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=47462A25.1060207@gmail.com \
--to=htejun@gmail.com \
--cc=hancockr@shaw.ca \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).