linux-kernel - Re: [RFC PATCH] nForce4 ADMA with NCQ: It's aliiiive..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <452C7C1D.3040704@shaw.ca>
Date:	Tue, 10 Oct 2006 23:07:41 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Allen Martin <AMartin@...dia.com>
Cc:	Jeff Garzik <jeff@...zik.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, prakash@...noor.de
Subject: Re: [RFC PATCH] nForce4 ADMA with NCQ: It's aliiiive..

Allen Martin wrote:
>> But I really don't think that is necessary.  I will take a 
>> look at docs and see how things match up, when I am much more 
>> awake.  Most likely you need to be using another set of 
>> registers, and be all MMIO, all the time.
> 
> You shouldn't be touching BM registers when ADMA is enabled, it can
> cause bad things to happen.
> 
> You should be using BM registers when doing ATAPI protocol though, as it
> doesn't work through ADMA.  So I wouldn't say you should be using MMIO
> all the time.
> 
> -Allen

OK, I've updated the code to take this into account, an updated patch is 
attached. However, this does raise an issue. If we have to fall back to 
legacy mode to do ATAPI DMA, this means that we can't do 64-bit DMA for 
such transfers. Since by the time the driver gets a request the SGs have 
already been created based on the set DMA mask, the only way I can see 
to handle this is to either allow ATAPI DMA or 64-bit DMA, not both. 
I've chosen to default to 64-bit DMA in this version, but there is a 
module parameter which allows overriding this if you care more about 
using ATAPI devices than efficiency with over 4GB of RAM. I'm open to 
suggestions on a better way to handle this..

I also updated the comments to clarify which chipsets are supported by 
ADMA as per Allen's previous comment.

This patch is now against 2.6.19-rc1-mm1. If there are no more 
suggestions, are there any objections to merging this into libata-dev or 
the -mm tree? I think it is ready for some more exposure, and since ADMA 
is currently disabled by default there should be little risk of breakage 
for those who don't choose to enable it.

Signed-off-by: Robert Hancock <hancockr@...w.ca>

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

View attachment "sata_nv-adma-ncq-v3.patch" of type "text/plain" (31581 bytes)