Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > No, as Timur found, the driver is correct and it intentionally sets the 32-bit mask, and that is guaranteed to work on all sane hardware. Don't change the driver but find a better platform for your workload, or talk to the people that are

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > > No, as Timur found, the driver is correct and it intentionally > > sets the 32-bit mask, and that is guaranteed to work on all sane > > hardware. Don't change the driver but find a better

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 10:47 AM, Arnd Bergmann wrote: What BenH was worried about here is that the driver sets different masks for streaming and coherent mappings, which is indeed a worry that could hit us on ARM as well, but I suppose we'll have to deal with that in platform code. Setting both masks to

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 1:27 PM, James Bottomley wrote: On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote: On 11/10/2015 11:47 AM, Arnd Bergmann wrote: On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: On 11/10/2015 3:38 AM, Arnd Bergmann wrote: From the email thread, it looks like this was

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 11:00:59 Timur Tabi wrote: > On 11/10/2015 10:47 AM, Arnd Bergmann wrote: > > What BenH was worried about here is that the driver sets different masks > > for streaming and coherent mappings, which is indeed a worry that > > could hit us on ARM as well, but I suppose

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote: > On 11/10/2015 11:47 AM, Arnd Bergmann wrote: > > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > >> From the email thread, it looks like this was introduced to support > >> some

Re: [PATCH 4.1] target-core: fix return without a value

On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote: > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return' > with no value, in function returning non-void [-Wreturn-type] > > The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11 > adds a check if

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 11:47 AM, Arnd Bergmann wrote: On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > No, as Timur found, the driver is correct and it intentionally sets the 32-bit mask, and that is guaranteed to work on all sane hardware. Don't

[PATCH 4.1] target-core: fix return without a value

Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type] The patch 35afa65642a9a88c81913377b93a3a66220f8b9d committed to 4.1.11 adds a check if device_list is NULL. The patch adds a return statement without a value to

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tue, 2015-11-10 at 14:56 -0500, Sinan Kaya wrote: > > On 11/10/2015 2:43 PM, James Bottomley wrote: > > The Issue, as stated by LSI is > > > > Initially set the consistent DMA mask to 32 bit and then change > > it > > to 64 bit mask after allocating RDPQ pools by

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 3:05 PM, James Bottomley wrote: OK, you don't seem to be understanding the problem: the Altix isn't a LSI card, it was a SGI platform. Got it. It was the platform where we first discovered the issue that a lot of storage cards didn't work because it by default had no memory

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 12:19:33 Sinan Kaya wrote: > On 11/10/2015 11:47 AM, Arnd Bergmann wrote: > > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > >> > No, as Timur found, the driver is correct and it intentionally > >>> sets the

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 15:03:59 Timur Tabi wrote: > On 11/10/2015 01:13 PM, Arnd Bergmann wrote: > > If the mask is 64-bit by default on ARM64, that is a bug that we need > > to fix urgently. Can you verify this? > > I think the mask is 0 by default, because there's no code in ARM64 that >

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 2:43 PM, James Bottomley wrote: The Issue, as stated by LSI is Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tue, 2015-11-10 at 14:14 -0500, Sinan Kaya wrote: > > On 11/10/2015 1:27 PM, James Bottomley wrote: > > On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote: > >> On 11/10/2015 11:47 AM, Arnd Bergmann wrote: > >>> On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > On 11/10/2015 3:38

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tue, 2015-11-10 at 15:26 -0500, Sinan Kaya wrote: > > On 11/10/2015 3:05 PM, James Bottomley wrote: > > OK, you don't seem to be understanding the problem: the Altix isn't a > > LSI card, it was a SGI platform. > > Got it. > > > It was the platform where we first > > discovered the issue

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 01:13 PM, Arnd Bergmann wrote: If the mask is 64-bit by default on ARM64, that is a bug that we need to fix urgently. Can you verify this? I think the mask is 0 by default, because there's no code in ARM64 that actually sets the mask. Take a look at arch_setup_pdev_archdata()

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 2:56 PM, Arnd Bergmann wrote: The ACPI IORT table declares whether you enable IOMMU for a particular >device or not. The placement of IOMMU HW is system specific. The IORT >table gives the IOMMU HW topology to the operating system. This sounds odd. Clearly you need to specify

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On 11/10/2015 03:54 PM, Arnd Bergmann wrote: In our drivers for 32-bit devices, we have to explicitly set the DMA mask to 32-bits in order to get any DMA working. Do you mean PCI devices or platform devices? Platform. Maybe the parent bus is lacking a dma-ranges property? All of this

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 15:58:19 Sinan Kaya wrote: > > On 11/10/2015 2:56 PM, Arnd Bergmann wrote: > >> The ACPI IORT table declares whether you enable IOMMU for a particular > >> >device or not. The placement of IOMMU HW is system specific. The IORT > >> >table gives the IOMMU HW topology to

Re: [PATCH 4.1] target-core: fix return without a value

On Tue, Nov 10, 2015 at 06:31:47PM -0500, Mikulas Patocka wrote: > > > On Tue, 10 Nov 2015, Greg Kroah-Hartman wrote: > > > On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote: > > > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return' > > > with no value, in

[PATCH RESEND] scsi: Set sg_tablesize to 1, for LLDDs that set SG_NONE

Oops while testing blk_mq over the new cxlflash driver. [ 2960.817172] Oops: Kernel access of bad area, sig: 11 [#5] [ 2960.817309] NIP __blk_mq_run_hw_queue+0x278/0x4c0 [ 2960.817313] LR __blk_mq_run_hw_queue+0x2bc/0x4c0 [ 2960.817314] Call Trace: [ 2960.817320]

[patch] mptfusion: don't allow negative bytes in kbuf_alloc_2_sgl()

There is a static checker warning here because "bytes" is controlled by the user and we cap the upper bound with min() but allow negatives. Negative bytes will result in some nasty warning messages but are not super harmful. Anyway, no one needs negative bytes so let's just check for it and

Re: [PATCH 4.1] target-core: fix return without a value

On Tue, 10 Nov 2015, Greg Kroah-Hartman wrote: > On Tue, Nov 10, 2015 at 01:32:10PM -0500, Mikulas Patocka wrote: > > Fix the warning drivers/target/target_core_pr.c:332:3: warning: 'return' > > with no value, in function returning non-void [-Wreturn-type] > > > > The patch

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Tuesday 10 November 2015 15:59:18 Timur Tabi wrote: > On 11/10/2015 03:54 PM, Arnd Bergmann wrote: > > >> In our drivers for 32-bit devices, we have to explicitly set the DMA > >> mask to 32-bits in order to get any DMA working. > > > > Do you mean PCI devices or platform devices? > >

Re: [PATCH v5 10/11] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller

Hi Rob, On 11/09/2015 09:53 PM, Rob Herring wrote: On Mon, Nov 09, 2015 at 10:56:26AM +0530, Alim Akhtar wrote: From: Seungwon Jeon This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings. Signed-off-by: Seungwon Jeon Signed-off-by:

RE: [patch 2/2] megaraid_sas: missing curly braces in megasas_detach_one()

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Saturday, November 07, 2015 9:47 PM > To: Kashyap Desai; Sumit Saxena > Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com; > linux-scsi@vger.kernel.org;

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

On Tue, Nov 10, 2015 at 6:53 AM, Timur Tabi wrote: > Sinan Kaya wrote: >> >> >> The code says it is using these macros for small integers only which >> can't overflow. I was trying to get rid of compiler warning and it seems >> to have disappeared. > > > I would double-check

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

On Monday 09 November 2015 22:53:17 Timur Tabi wrote: > Sinan Kaya wrote: > > > > The code says it is using these macros for small integers only which > > can't overflow. I was trying to get rid of compiler warning and it seems > > to have disappeared. > > I would double-check the assembly code,

RE: [patch 1/2] megaraid_sas: remove a stray tab

> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Saturday, November 07, 2015 9:46 PM > To: Kashyap Desai; Sumit Saxena > Cc: Uday Lingala; James E.J. Bottomley; megaraidlinux@avagotech.com; > linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org;

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

On Monday 09 November 2015 18:22:22 Sinan Kaya wrote: > On 11/9/2015 9:33 AM, Arnd Bergmann wrote: > > On Monday 09 November 2015 09:07:36 Sinan Kaya wrote: > >> On 11/9/2015 3:59 AM, Arnd Bergmann wrote: > > ioc->dma_mask is 0 and the driver is trying to use 32 bit even though 64 > bit

Re: [PATCH v3 02/32] devicetree: bindings: scsi: HiSi SAS

On 09/11/2015 18:01, Rob Herring wrote: On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote: Add devicetree bindings for HiSilicon SAS driver. Signed-off-by: John Garry Signed-off-by: Zhangfei Gao ---

Re: [PATCH v3 08/32] scsi: hisi_sas: add hisi_sas_remove

+int hisi_sas_remove(struct platform_device *pdev) +{ + struct sas_ha_struct *sha = platform_get_drvdata(pdev); + struct hisi_hba *hisi_hba = sha->lldd_ha; + + sas_unregister_ha(sha); + sas_remove_host(sha->core.shost); + scsi_remove_host(sha->core.shost); scsi

Re: [PATCH RESEND] scsi: Set sg_tablesize to 1, for LLDDs that set SG_NONE

On 11/10/2015 11:45 PM, Manoj Kumar wrote: > Oops while testing blk_mq over the new cxlflash driver. > > [ 2960.817172] Oops: Kernel access of bad area, sig: 11 [#5] > [ 2960.817309] NIP __blk_mq_run_hw_queue+0x278/0x4c0 > [ 2960.817313] LR __blk_mq_run_hw_queue+0x2bc/0x4c0 > [ 2960.817314] Call

Re: [PATCH v3 02/32] devicetree: bindings: scsi: HiSi SAS

On Tue, Nov 10, 2015 at 5:09 AM, John Garry wrote: > On 09/11/2015 18:01, Rob Herring wrote: >> >> On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote: >>> >>> Add devicetree bindings for HiSilicon SAS driver. >>> >>> Signed-off-by: John Garry

Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs

On 11/07/2015 04:23 AM, Christoph Hellwig wrote: > On Wed, Nov 04, 2015 at 10:53:39AM -0600, Mike Christie wrote: >>> If you have to touch submit_bio() and submit_bio_wait(), how about >>> requiring the callers of these functions to set the cmd and flags >>> arguments in the bio structure and to