[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1424416602.27448.36.camel@kernel.crashing.org>
Date: Fri, 20 Feb 2015 18:16:42 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Sreekanth Reddy <Sreekanth.Reddy@...gotech.com>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
scsi <linux-scsi@...r.kernel.org>, Christoph Hellwig <hch@....de>
Subject: Re: Concerns about "mpt2sas: Added Reply Descriptor Post Queue
(RDPQ) Array support"
On Fri, 2015-02-20 at 16:22 +1100, Benjamin Herrenschmidt wrote:
> Looking a bit more closely, you basically do
>
> - set_dma_mask(64-bit)
> - set_consistent_dma_mask(32-bit)
>
> Now, I don't know how x86 will react to the conflicting masks, but on
> ppc64, I'm pretty sure the second one will barf. IE, the first one will
> establish a set of direct mapping ops which give you a bypass of the
> iommu to all of memory. The second one will then do a
> dma_supported(mask) call which will hit the direct ops, and they will
> fail since a 32-bit mask cannot address the bypass completely.
>
> Are architectures really required to support such mismatching dma_mask
> and consistent_dma_mask ? what a bloody trainwreck ... :-(
Oh well, looks like x86 supports it and it won't be too hard to support
it on ppc64 as well. We even had some code along those lines for FSL
platforms with an ifdef due to the amount of drivers that used to fail
setting the consistent mask properly but that seems to be mostly fixed
nowadays.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists