Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752190AbbKIJAE (ORCPT ); Mon, 9 Nov 2015 04:00:04 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:50287 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751446AbbKIJAA (ORCPT ); Mon, 9 Nov 2015 04:00:00 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Hannes Reinecke , Sinan Kaya , linux-scsi@vger.kernel.org, timur@codeaurora.org, cov@codeaurora.org, jcm@redhat.com, Abhijit Mahajan , Nagalakshmi Nandigama , linux-arm-msm@vger.kernel.org, "James E.J. Bottomley" , linux-kernel@vger.kernel.org, Sreekanth Reddy , Praveen Krishnamoorthy , agross@codeaurora.org, MPT-FusionLinux.pdl@avagotech.com Subject: Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Date: Mon, 09 Nov 2015 09:59:04 +0100 Message-ID: <4041362.9GKaSPm9gs@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <564046B3.8090505@suse.de> References: <1447034266-28003-1-git-send-email-okaya@codeaurora.org> <1447034266-28003-2-git-send-email-okaya@codeaurora.org> <564046B3.8090505@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:i7sRfYDRQzSMQIcv0IQMCXInCDHkLvHBtfRTcnnJt6IvA7RVRAr Wm4Vak1O4G9U9371KJaiLoHV7Kx+TBY0kR+MaSQSqwDGCfshQ24O/OLRe4riEXjQ+H+QV8L xPg5ripsJs8+kynR2Uv0zhmt9oR/PH3N6AwfUo22bOprIdDRIW9TLfDPBZt5mjYoIeP66Up 8eTBNoMf6EBJ2VTeDdLmA== X-UI-Out-Filterresults: notjunk:1;V01:K0:AOoqsy9Z1L8=:W7JpdR4k7PINHI3g9t/kG5 4j9mEXf3w8n+pHjbrcnI7GuxTrsAF7S1VSS34WOReMTOxQ20BXY4uL89wKevlM6/4oxUVJr22 Sp3ddgdeFUIX9m72OVDssReIOvWAaz+1EFT2tuYxcym5bHaSKleIlMRPQt8dJ2Eu1MyTYP7fF c1vSHu+9Eh8XYnymyRXxUPEejaGHslYqtzsYVpFTdWWEMR5vefv1XD4cwQApMIRMttn66oWLO KAhXCDBKh5aFpYDurmQSlqHx9u6L83YuDLTVFA4z0zdJCf+6KXP7a9ylIdnY3tSldI824k7Rk j3FQB8HpZplXdnrlkW5Zk2SeInasyao33Ox6JvoEQytflJyQXy1a5ie+Lxd4EtDABnqnlKTnV la2VK17B4jSziQzu1eKvSDSt/8gWxp63Q5YQgV2Pqyv73RrO//xClSlumF6joISNUts6Z78mf wBOKoCmt9Mai9B3I6olHgOI+a6MGaasYwWEntZmT6icztbhTIRxcXsAhXTTs1oENXUqccaO6d 7jW/twzj903YFaoxWAYXDCAJFue/DL1NuDfqj45LHO4igDSzy903P6NwT5YuuiquIqycHDb3U 7qtKG/Hhzh6NjQ3b0YiP/+5kDaktva5D4QNSo1tBtYjRDUgY7PuFM2Ckndh8MuLRPx0YTXRMb J7STEZtg8chw5/CQH1ZQO2/YQTqyYH5CL2zA6cZWeX64YSeZOHZMtYl57glQKgKTcaMepHB+4 3KzhqL3EKjeRGfIu Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1380 Lines: 36 On Monday 09 November 2015 08:09:39 Hannes Reinecke wrote: > On 11/09/2015 02:57 AM, Sinan Kaya wrote: > > Current code gives up when 32 bit DMA is not supported. > > This problem has been observed on systems without any > > memory below 4 gig. > > > > This patch tests 64 bit support before bailing out to find > > a working combination. > > > That feels decidedly odd. > > Why do you probe for 64bit if 32bit fails? 32-bit DMA mask on PCI cannot fail, we rely on that in all sorts of places. If the machine has all of its RAM visible above 4GB PCI bus addresses, it must use an IOMMU. > Typically it's the other way round, on the grounds that 64bit DMA > should be preferred over 32bit. > Can you explain why it needs to be done the other way round here? Something else is odd here, the driver already checks for dma_get_required_mask(), which will return the smallest mask that fits all of RAM. If the machine has any memory above 4GB, it already uses the 64-bit mask, and only falls back to the 32-bit mask if that fails or if all memory fits within the first 4GB. So both the description and the patch are wrong. :( Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/