[Bug 198839] Backport of the Linux MegaRAID driver for SAS based RAID controllers

2018-02-19 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=198839

--- Comment #2 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Hi,
The problem is in kernel 4.9.82
#define MEGASAS_VERSION "06.811.02.00-rc1"
For kernel 4.14.20 is OK
#define MEGASAS_VERSION "07.702.06.00-rc1"

5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
SAS3508 (rev 01)
Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated
RAID Module RMSP3CD080F)
Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0
Memory at 38f0 (64-bit, prefetchable) [size=1M]
Memory at 38e0 (64-bit, prefetchable) [size=1M]
Memory at b880 (32-bit, non-prefetchable) [size=1M]
I/O ports at 8000 [size=256]
Expansion ROM at  [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable+ Count=128 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Power Budgeting Regards,
Capabilities: [158] Alternative Routing-ID Interpretation (ARI)
Capabilities: [168] #19
Capabilities: [254] #16
Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1
Len=100 
Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1
Len=038 
Capabilities: [3bc] #15
Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas

Regards,
Doru Iorgulescu





On Tue, Feb 20, 2018 at 9:07 AM, 
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=198839
>
> Sumit Saxena (sumit.sax...@broadcom.com) changed:
>
>What|Removed |Added
> 
> 
>  CC||sumit.sax...@broadcom.com
>
> --- Comment #1 from Sumit Saxena (sumit.sax...@broadcom.com) ---
> (In reply to doru iorgulescu from comment #0)
> > Created attachment 274257 [details]
> > Backport of the Linux MegaRAID driver for SAS based RAID controllers
> >
> > Backport of the Linux MegaRAID driver for SAS based RAID controllers
> >
> > backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82
> >
> > Hi,
> >
> > Hardware:
> > DMI: Intel Corporation S2600WFT/S2600WFT, BIOS
> > SE5C620.86B.00.01.0009.101920170742 10/19/2017
> >
> > I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid  to
> > /usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel
> 4.9.82
> > and is OK !
> > I send dmesg atached.
> >
> >
> > The problem for original linux kernel 4.9.82 is :
> >
> > 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
> > SAS3508 (rev 01)
> > Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508
> (Integrated
> > RAID Module RMSP3CD080F)
> > Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0
> > Memory at 38f0 (64-bit, prefetchable) [size=1M]
> > Memory at 38e0 (64-bit, prefetchable) [size=1M]
> > Memory at b880 (32-bit, non-prefetchable) [size=1M]
> > I/O ports at 8000 [size=256]
> > Expansion ROM at  [disabled]
> > Capabilities: [40] Power Management version 3
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Capabilities: [70] Express Endpoint, MSI 00
> > Capabilities: [b0] MSI-X: Enable+ Count=128 Masked-
> > Capabilities: [d0] Vital Product Data
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [148] Power Budgeting Regards,
> > Capabilities: [158] Alternative Routing-ID Interpretation (ARI)
> > Capabilities: [168] #19
> > Capabilities: [254] #16
> > Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1
> > Len=100 
> > Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1
> > Len=038 
> > Capabilities: [3bc] #15
> > Kernel driver in use: megaraid_sas
> > Kernel modules: megaraid_sas
> >
> > Regards,
> > Doru Iorgulescu
>
> Hi Doru,
>
> I have gone through the attached logs and observed some prints about
> hibernation failure.
> --
> [3.788370] PM: Starting manual resume from disk
> [3.788375] PM: Hibernation image partition 8:9 present
> [3.788377] PM: Looking for hibernation image.
> [3.788638] PM: Image not found (code -22)
> [3.788640] PM: Hibernation image not present or could not be loaded.
> --
>
> Is it the problem you are trying to point ? Please clarify.
> Is it regression from 4.14.20 to 4.9.82 due to megaraid_sas driver
> backporting
> ?
>
>
> Thanks,
> Sumit
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail

[Bug 198839] Backport of the Linux MegaRAID driver for SAS based RAID controllers

2018-02-19 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=198839

Sumit Saxena (sumit.sax...@broadcom.com) changed:

   What|Removed |Added

 CC||sumit.sax...@broadcom.com

--- Comment #1 from Sumit Saxena (sumit.sax...@broadcom.com) ---
(In reply to doru iorgulescu from comment #0)
> Created attachment 274257 [details]
> Backport of the Linux MegaRAID driver for SAS based RAID controllers
> 
> Backport of the Linux MegaRAID driver for SAS based RAID controllers
> 
> backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82
> 
> Hi,
> 
> Hardware:
> DMI: Intel Corporation S2600WFT/S2600WFT, BIOS
> SE5C620.86B.00.01.0009.101920170742 10/19/2017
> 
> I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid  to
> /usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel 4.9.82
> and is OK !
> I send dmesg atached.
> 
> 
> The problem for original linux kernel 4.9.82 is :
> 
> 5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
> SAS3508 (rev 01)
> Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated
> RAID Module RMSP3CD080F)
> Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0
> Memory at 38f0 (64-bit, prefetchable) [size=1M]
> Memory at 38e0 (64-bit, prefetchable) [size=1M]
> Memory at b880 (32-bit, non-prefetchable) [size=1M]
> I/O ports at 8000 [size=256]
> Expansion ROM at  [disabled]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [b0] MSI-X: Enable+ Count=128 Masked-
> Capabilities: [d0] Vital Product Data
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [148] Power Budgeting Regards,
> Capabilities: [158] Alternative Routing-ID Interpretation (ARI)
> Capabilities: [168] #19
> Capabilities: [254] #16
> Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1
> Len=100 
> Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1
> Len=038 
> Capabilities: [3bc] #15
> Kernel driver in use: megaraid_sas
> Kernel modules: megaraid_sas
> 
> Regards,
> Doru Iorgulescu

Hi Doru,

I have gone through the attached logs and observed some prints about
hibernation failure.
--
[3.788370] PM: Starting manual resume from disk
[3.788375] PM: Hibernation image partition 8:9 present
[3.788377] PM: Looking for hibernation image.
[3.788638] PM: Image not found (code -22)
[3.788640] PM: Hibernation image not present or could not be loaded.
--

Is it the problem you are trying to point ? Please clarify.
Is it regression from 4.14.20 to 4.9.82 due to megaraid_sas driver backporting
? 


Thanks,
Sumit

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 198839] New: Backport of the Linux MegaRAID driver for SAS based RAID controllers

2018-02-19 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=198839

Bug ID: 198839
   Summary: Backport of the Linux MegaRAID driver for SAS based
RAID controllers
   Product: SCSI Drivers
   Version: 2.5
Kernel Version: 4.9.82 4.14.20
  Hardware: Intel
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Other
  Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
  Reporter: doru.iorgules...@gmail.com
Regression: No

Created attachment 274257
  --> https://bugzilla.kernel.org/attachment.cgi?id=274257=edit
Backport of the Linux MegaRAID driver for SAS based RAID controllers

Backport of the Linux MegaRAID driver for SAS based RAID controllers

backport of the megaraid_sas driver from kernel 4.14.20 to kernel 4.9.82

Hi,

Hardware:
DMI: Intel Corporation S2600WFT/S2600WFT, BIOS
SE5C620.86B.00.01.0009.101920170742 10/19/2017

I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid  to
/usr/src/linux-4.9.82/drivers/scsi/megaraid . I compile the kernel 4.9.82 and
is OK !
I send dmesg atached.


The problem for original linux kernel 4.9.82 is :

5e:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
SAS3508 (rev 01)
Subsystem: Intel Corporation MegaRAID Tri-Mode SAS3508 (Integrated RAID
Module RMSP3CD080F)
Flags: bus master, fast devsel, latency 0, IRQ 36, NUMA node 0
Memory at 38f0 (64-bit, prefetchable) [size=1M]
Memory at 38e0 (64-bit, prefetchable) [size=1M]
Memory at b880 (32-bit, non-prefetchable) [size=1M]
I/O ports at 8000 [size=256]
Expansion ROM at  [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable+ Count=128 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Power Budgeting Regards,
Capabilities: [158] Alternative Routing-ID Interpretation (ARI)
Capabilities: [168] #19
Capabilities: [254] #16
Capabilities: [284] Vendor Specific Information: ID=0002 Rev=1 Len=100

Capabilities: [384] Vendor Specific Information: ID=0001 Rev=1 Len=038

Capabilities: [3bc] #15
Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas

Regards,
Doru Iorgulescu

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

2018-02-19 Thread Max Ivanov 
> As already explained in the previous mail, there is a fixup for this in
> commit 81b6c9998979 ('scsi: core: check for device state in
> __scsi_remove_target()').
> Please check if this is applied, too.

I tested commit 81b6c9998979 cherry-picked on top of 4.14.20 and it
indeed solves the problem.

Can it be backported to 4.14 LTS, please?

[PATCH] mvsas: fix wrong endianess of sgpio api

2018-02-19 Thread Wilfried . Weissmann 
From: Wilfried Weissmann 

---
 drivers/scsi/mvsas/mv_94xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_94xx.c b/drivers/scsi/mvsas/mv_94xx.c
index 7de5d8d75..926086f39 100644
--- a/drivers/scsi/mvsas/mv_94xx.c
+++ b/drivers/scsi/mvsas/mv_94xx.c
@@ -1088,7 +1088,7 @@ static int mvs_94xx_gpio_write(struct mvs_prv_info 
*mvs_prv,
* if bit is set then create a mask with the first
* bit of the drive set in the mask ...
*/
-   u32 bit = (write_data[i/8] & (1 << (i&(8-1 ?
+   u32 bit = (write_data[3-(i/8)] & (1 << (i&(8-1 ?
1<<(24-drive*8) : 0;
 
/*
@@ -1132,7 +1132,7 @@ static int mvs_94xx_gpio_write(struct mvs_prv_info 
*mvs_prv,
void __iomem *regs = mvi->regs_ex - 0x10200;
 
mw32(MVS_SGPIO_DCTRL + MVS_SGPIO_HOST_OFFSET * mvi->id,
-   be32_to_cpu(((u32 *) write_data)[i]));
+   le32_to_cpu(((u32 *) write_data)[i]));
}
return reg_count;
}

[PATCH] mvsas: fix wrong endianess of sgpio api

2018-02-19 Thread Wilfried . Weissmann 
The SGPIO api is little endian. This patch fixes the byte order
and brings it back to sync with ledmon v0.80 and above.

[PATCH 4/8] scsi: hisi_sas: fix the issue of setting linkrate register

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

It is not right to set the register PROG_PHY_LINK_RATE while PHY
is still enabled. So if we want to change PHY linkrate, we need to
disable PHY before setting the register PROG_PHY_LINK_RATE, and then
start-up PHY. This patch is to fix this issue.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 5 +++--
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 5 +++--
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 38bbda9..2eb8980 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -881,10 +881,11 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v1_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v1_hw(hisi_hba, phy_no);
+   start_phy_v1_hw(hisi_hba, phy_no);
 }
 
 static int get_wideport_bitmap_v1_hw(struct hisi_hba *hisi_hba, int port_id)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 662d259..357138f 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1611,10 +1611,11 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v2_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v2_hw(hisi_hba, phy_no);
+   start_phy_v2_hw(hisi_hba, phy_no);
 }
 
 static int get_wideport_bitmap_v2_hw(struct hisi_hba *hisi_hba, int port_id)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 1ee95ab..8da9de7 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -1862,10 +1862,11 @@ static void phy_set_linkrate_v3_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v3_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v3_hw(hisi_hba, phy_no);
+   start_phy_v3_hw(hisi_hba, phy_no);
 }
 
 static void interrupt_disable_v3_hw(struct hisi_hba *hisi_hba)
-- 
1.9.1

[PATCH 6/8] scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req

2018-02-19 Thread John Garry 
From: Xiang Chen 

The structure element hisi_sas_devices.running_req to count how
many commands are active is in effect only ever written in the
code, so remove it.

Signed-off-by: Xiang Chen 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas.h   | 1 -
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 9 -
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 3 ---
 3 files changed, 13 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index e7fd287..d1153e8 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -175,7 +175,6 @@ struct hisi_sas_device {
struct hisi_sas_dq  *dq;
struct list_headlist;
u64 attached_phy;
-   atomic64_t running_req;
enum sas_device_typedev_type;
int device_id;
int sata_idx;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 9ff8790..88ad8d4 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -200,8 +200,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, 
struct sas_task *task,
 
if (task) {
struct device *dev = hisi_hba->dev;
-   struct domain_device *device = task->dev;
-   struct hisi_sas_device *sas_dev = device->lldd_dev;
 
if (!task->lldd_task)
return;
@@ -213,9 +211,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, 
struct sas_task *task,
dma_unmap_sg(dev, task->scatter,
 task->num_scatter,
 task->data_dir);
-
-   if (sas_dev)
-   atomic64_dec(_dev->running_req);
}
 
if (slot->buf)
@@ -431,8 +426,6 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
spin_unlock_irqrestore(>task_state_lock, flags);
 
dq->slot_prep = slot;
-
-   atomic64_inc(_dev->running_req);
++(*pass);
 
return 0;
@@ -1517,8 +1510,6 @@ static int hisi_sas_query_task(struct sas_task *task)
 
dq->slot_prep = slot;
 
-   atomic64_inc(_dev->running_req);
-
/* send abort command to the chip */
hisi_hba->hw->start_delivery(dq);
spin_unlock_irqrestore(>lock, flags_dq);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 2eb8980..8dd0e6a6 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1407,9 +1407,6 @@ static int slot_complete_v1_hw(struct hisi_hba *hisi_hba,
}
 
 out:
-   if (sas_dev)
-   atomic64_dec(_dev->running_req);
-
hisi_sas_slot_task_free(hisi_hba, task, slot);
sts = ts->stat;
 
-- 
1.9.1

[PATCH 8/8] scsi: hisi_sas: Code cleanup and minor bug fixes

2018-02-19 Thread John Garry 
From: Xiang Chen 

The patch does some code cleanup and fixes some small bugs:
- Correct return status of phy_up_v3_hw()
- Add static for function phy_get_max_linkrate_v3_hw()
- Change exception return status when no reset method
- Change magic value to ts->stat in slot_complete_vx_hw()
- Remove unnecessary check for dev_is_sata()
- Fix some issues of alignment and indents (Authored by
  Xiaofei Tan in another patch, but added here to be
  practical)

Signed-off-by: Xiaofei Tan 
Signed-off-by: Xiang Chen 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 14 +++---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  4 +++-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 10 ++
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 16 +---
 4 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index dff9723..49c1fa6 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -33,7 +33,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_FPDMA_RECV:
case ATA_CMD_FPDMA_SEND:
case ATA_CMD_NCQ_NON_DATA:
-   return HISI_SAS_SATA_PROTOCOL_FPDMA;
+   return HISI_SAS_SATA_PROTOCOL_FPDMA;
 
case ATA_CMD_DOWNLOAD_MICRO:
case ATA_CMD_ID_ATA:
@@ -45,7 +45,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_WRITE_LOG_EXT:
case ATA_CMD_PIO_WRITE:
case ATA_CMD_PIO_WRITE_EXT:
-   return HISI_SAS_SATA_PROTOCOL_PIO;
+   return HISI_SAS_SATA_PROTOCOL_PIO;
 
case ATA_CMD_DSM:
case ATA_CMD_DOWNLOAD_MICRO_DMA:
@@ -64,7 +64,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_WRITE_LOG_DMA_EXT:
case ATA_CMD_WRITE_STREAM_DMA_EXT:
case ATA_CMD_ZAC_MGMT_IN:
-   return HISI_SAS_SATA_PROTOCOL_DMA;
+   return HISI_SAS_SATA_PROTOCOL_DMA;
 
case ATA_CMD_CHK_POWER:
case ATA_CMD_DEV_RESET:
@@ -77,21 +77,21 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, 
int direction)
case ATA_CMD_STANDBY:
case ATA_CMD_STANDBYNOW1:
case ATA_CMD_ZAC_MGMT_OUT:
-   return HISI_SAS_SATA_PROTOCOL_NONDATA;
+   return HISI_SAS_SATA_PROTOCOL_NONDATA;
default:
{
if (fis->command == ATA_CMD_SET_MAX) {
switch (fis->features) {
case ATA_SET_MAX_PASSWD:
case ATA_SET_MAX_LOCK:
-   return HISI_SAS_SATA_PROTOCOL_PIO;
+   return HISI_SAS_SATA_PROTOCOL_PIO;
 
case ATA_SET_MAX_PASSWD_DMA:
case ATA_SET_MAX_UNLOCK_DMA:
-   return HISI_SAS_SATA_PROTOCOL_DMA;
+   return HISI_SAS_SATA_PROTOCOL_DMA;
 
default:
-   return HISI_SAS_SATA_PROTOCOL_NONDATA;
+   return HISI_SAS_SATA_PROTOCOL_NONDATA;
}
}
if (direction == DMA_NONE)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 8dd0e6a6..520ba69 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -651,8 +651,10 @@ static int reset_hw_v1_hw(struct hisi_hba *hisi_hba)
dev_err(dev, "De-reset failed\n");
return -EIO;
}
-   } else
+   } else {
dev_warn(dev, "no reset method\n");
+   return -EIO;
+   }
 
return 0;
 }
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 357138f..f2cddff 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1095,8 +1095,10 @@ static int reset_hw_v2_hw(struct hisi_hba *hisi_hba)
dev_err(dev, "SAS de-reset fail.\n");
return -EIO;
}
-   } else
-   dev_warn(dev, "no reset method\n");
+   } else {
+   dev_err(dev, "no reset method\n");
+   return -EIO;
+   }
 
return 0;
 }
@@ -2408,7 +2410,7 @@ static void slot_err_v2_hw(struct hisi_hba *hisi_hba,
spin_lock_irqsave(_hba->lock, flags);
hisi_sas_slot_task_free(hisi_hba, task, slot);
spin_unlock_irqrestore(_hba->lock, flags);
-   return -1;
+   return ts->stat;
}
 
if (unlikely(!sas_dev)) {
@@ -2667,7 +2669,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba,
/* dw0 */
hdr->dw0 = cpu_to_le32((5

[PATCH 5/8] scsi: hisi_sas: increase timer expire of internal abort task

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

The current 110ms expiry time is not long enough for the internal
abort task.

The reason is that the internal abort task could be blocked in HW
if the HW is retrying to set up link. The internal abort task will
be executed only when the retry process finished.

The maximum time is 5s for the retry of setting up link. So, the timer
expire should be more than 5s. This patch increases it from 110ms to 6s.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 9d16372..9ff8790 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -871,6 +871,7 @@ static void hisi_sas_tmf_timedout(struct timer_list *t)
 
 #define TASK_TIMEOUT 20
 #define TASK_RETRY 3
+#define INTERNAL_ABORT_TIMEOUT 6
 static int hisi_sas_exec_internal_tmf_task(struct domain_device *device,
   void *parameter, u32 para_len,
   struct hisi_sas_tmf_task *tmf)
@@ -1574,7 +1575,7 @@ static int hisi_sas_query_task(struct sas_task *task)
task->task_proto = device->tproto;
task->task_done = hisi_sas_task_done;
task->slow_task->timer.function = hisi_sas_tmf_timedout;
-   task->slow_task->timer.expires = jiffies + msecs_to_jiffies(110);
+   task->slow_task->timer.expires = jiffies + INTERNAL_ABORT_TIMEOUT*HZ;
add_timer(>slow_task->timer);
 
res = hisi_sas_internal_abort_task_exec(hisi_hba, sas_dev->device_id,
-- 
1.9.1

[PATCH 3/8] scsi: hisi_sas: fix the issue of link rate inconsistency

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

In sysfs, there are two files about minimum linkrate, and also
two files for maximum linkrate. Take maximum linkrate example,
maximum_linkrate_hw is read-only and indicated by the register
HARD_PHY_LINKRATE, and maximum_linkrate is read-write and
corresponding to the register PROG_PHY_LINK_RATE.

But in the function phy_up_v*_hw(), we get *_linkrate value from
HARD_PHY_LINKRATE. It is not right. This patch is to fix this issue.

Unreferenced PHY-interrupt enum is also removed for v3 hw.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c  |  2 ++
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  1 -
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c |  8 +---
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 13 +
 4 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 2d4dbed..9d16372 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -683,6 +683,8 @@ static void hisi_sas_phy_init(struct hisi_hba *hisi_hba, 
int phy_no)
 
phy->hisi_hba = hisi_hba;
phy->port = NULL;
+   phy->minimum_linkrate = SAS_LINK_RATE_1_5_GBPS;
+   phy->maximum_linkrate = hisi_hba->hw->phy_get_max_linkrate();
sas_phy->enabled = (phy_no < hisi_hba->n_phy) ? 1 : 0;
sas_phy->class = SAS;
sas_phy->iproto = SAS_PROTOCOL_ALL;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 679e76f..38bbda9 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -873,7 +873,6 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba 
*hisi_hba, int phy_no,
sas_phy->phy->maximum_linkrate = max;
sas_phy->phy->minimum_linkrate = min;
 
-   min -= SAS_LINK_RATE_1_5_GBPS;
max -= SAS_LINK_RATE_1_5_GBPS;
 
for (i = 0; i <= max; i++)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index ab6db50..662d259 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1603,7 +1603,6 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba 
*hisi_hba, int phy_no,
sas_phy->phy->maximum_linkrate = max;
sas_phy->phy->minimum_linkrate = min;
 
-   min -= SAS_LINK_RATE_1_5_GBPS;
max -= SAS_LINK_RATE_1_5_GBPS;
 
for (i = 0; i <= max; i++)
@@ -2684,7 +2683,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba,
 static int phy_up_v2_hw(int phy_no, struct hisi_hba *hisi_hba)
 {
int i, res = IRQ_HANDLED;
-   u32 port_id, link_rate, hard_phy_linkrate;
+   u32 port_id, link_rate;
struct hisi_sas_phy *phy = _hba->phy[phy_no];
struct asd_sas_phy *sas_phy = >sas_phy;
struct device *dev = hisi_hba->dev;
@@ -2723,11 +2722,6 @@ static int phy_up_v2_hw(int phy_no, struct hisi_hba 
*hisi_hba)
}
 
sas_phy->linkrate = link_rate;
-   hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
-   HARD_PHY_LINKRATE);
-   phy->maximum_linkrate = hard_phy_linkrate & 0xf;
-   phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
-
sas_phy->oob_mode = SAS_OOB_MODE;
memcpy(sas_phy->attached_sas_addr, >sas_addr, SAS_ADDR_SIZE);
dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index a1f1868..1ee95ab 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -340,12 +340,6 @@ struct hisi_sas_err_record_v3 {
 #define HISI_SAS_COMMAND_ENTRIES_V3_HW 4096
 #define HISI_SAS_MSI_COUNT_V3_HW 32
 
-enum {
-   HISI_SAS_PHY_PHY_UPDOWN,
-   HISI_SAS_PHY_CHNL_INT,
-   HISI_SAS_PHY_INT_NR
-};
-
 #define DIR_NO_DATA 0
 #define DIR_TO_INI 1
 #define DIR_TO_DEVICE 2
@@ -1121,7 +1115,7 @@ static int prep_abort_v3_hw(struct hisi_hba *hisi_hba,
 static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba)
 {
int i, res = 0;
-   u32 context, port_id, link_rate, hard_phy_linkrate;
+   u32 context, port_id, link_rate;
struct hisi_sas_phy *phy = _hba->phy[phy_no];
struct asd_sas_phy *sas_phy = >sas_phy;
struct device *dev = hisi_hba->dev;
@@ -1139,10 +1133,6 @@ static int phy_up_v3_hw(int phy_no, struct hisi_hba 
*hisi_hba)
goto end;
}
sas_phy->linkrate = link_rate;
-   hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
-   HARD_PHY_LINKRATE);
-   phy->maximum_linkrate = hard_phy_linkrate & 0xf;
-   phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);
 
/* Check for SATA

[PATCH 0/8] hisi_sas: support x6000 board and some misc changes

2018-02-19 Thread John Garry 
This patchset primarily adds support for the Huawei x6000 board,
which includes hip07 chipset. Unfortunately, due to some board
layout differences with our development board, we need to set
a PHY-related register differently for optimal signal quality. As
such, a signal attenuation property is added to describe the
differences in the boards and allow the PHY register to be set
appropriately.

In addition to this above feature, some misc changes are added for:
- PHY linkrate sysfs interface
- linkrate set function
- internal abort timer timeout increase

Xiang Chen (2):
  scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req
  scsi: hisi_sas: Code cleanup and minor bug fixes

Xiaofei Tan (6):
  dt-bindings: scsi: hisi_sas: add an property of signal attenuation
  scsi: hisi_sas: support the property of signal attenuation for v2 hw
  scsi: hisi_sas: fix the issue of link rate inconsistency
  scsi: hisi_sas: fix the issue of setting linkrate register
  scsi: hisi_sas: increase timer expire of internal abort task
  scsi: hisi_sas: fix return value of hisi_sas_task_prep()

 .../devicetree/bindings/scsi/hisilicon-sas.txt |  7 +++
 drivers/scsi/hisi_sas/hisi_sas.h   |  1 -
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 34 +---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 13 +++--
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 62 +-
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 34 +---
 6 files changed, 88 insertions(+), 63 deletions(-)

-- 
1.9.1

[PATCH 7/8] scsi: hisi_sas: fix return value of hisi_sas_task_prep()

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

It is an implicit regulation that error code that function returned
should be negative. But hisi_sas_task_prep() doesn't follow this.
This may cause problems in the upper layer code.

For example, in sas_expander.c of libsas, smp_execute_task_sg() may
return the number of bytes of underrun. It will be conflicted with
the scenaio lldd_execute_task() return an positive error code.

This patch change the return value from SAS_PHY_DOWN to -ECOMM in
hisi_sas_task_prep().

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 88ad8d4..dff9723 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -316,7 +316,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
 */
if (device->dev_type != SAS_SATA_DEV)
task->task_done(task);
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
if (DEV_IS_GONE(sas_dev)) {
@@ -327,7 +327,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
dev_info(dev, "task prep: device %016llx not ready\n",
 SAS_ADDR(device->sas_addr));
 
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
port = to_hisi_sas_port(sas_port);
@@ -337,7 +337,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
 "SATA/STP" : "SAS",
 device->port->id);
 
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
if (!sas_protocol_ata(task->task_proto)) {
-- 
1.9.1

[PATCH 2/8] scsi: hisi_sas: support the property of signal attenuation for v2 hw

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

The register SAS_PHY_CTRL is configured according to signal quality.
The signal quality is calculated by signal attenuation of hardware
physical link. It may be different for different PCB layout.

So, in order to give better support to new board, this patch add
support to reading the devicetree property, signal-attenuation.
Of course, we still keep an default value in driver to adapt old
board.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 4ccb61e..ab6db50 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -406,6 +406,17 @@ struct hisi_sas_err_record_v2 {
__le32 dma_rx_err_type;
 };
 
+struct signal_attenuation_s {
+   u32 de_emphasis;
+   u32 preshoot;
+   u32 boost;
+};
+
+struct sig_atten_lu_s {
+   const struct signal_attenuation_s *att;
+   u32 sas_phy_ctrl;
+};
+
 static const struct hisi_sas_hw_error one_bit_ecc_errors[] = {
{
.irq_msk = BIT(SAS_ECC_INTR_DQE_ECC_1B_OFF),
@@ -1130,9 +1141,16 @@ static void phys_try_accept_stp_links_v2_hw(struct 
hisi_hba *hisi_hba)
}
 }
 
+static const struct signal_attenuation_s x6000 = {9200, 0, 10476};
+static const struct sig_atten_lu_s sig_atten_lu[] = {
+   { , 0x3016a68 },
+};
+
 static void init_reg_v2_hw(struct hisi_hba *hisi_hba)
 {
struct device *dev = hisi_hba->dev;
+   u32 sas_phy_ctrl = 0x30b9908;
+   u32 signal[3];
int i;
 
/* Global registers init */
@@ -1176,9 +1194,28 @@ static void init_reg_v2_hw(struct hisi_hba *hisi_hba)
hisi_sas_write32(hisi_hba, AXI_AHB_CLK_CFG, 1);
hisi_sas_write32(hisi_hba, HYPER_STREAM_ID_EN_CFG, 1);
 
+   /* Get sas_phy_ctrl value to deal with TX FFE issue. */
+   if (!device_property_read_u32_array(dev, "signal-attenuation",
+   signal, ARRAY_SIZE(signal))) {
+   for (i = 0; i < ARRAY_SIZE(sig_atten_lu); i++) {
+   const struct sig_atten_lu_s *lookup = _atten_lu[i];
+   const struct signal_attenuation_s *att = lookup->att;
+
+   if ((signal[0] == att->de_emphasis) &&
+   (signal[1] == att->preshoot) &&
+   (signal[2] == att->boost)) {
+   sas_phy_ctrl = lookup->sas_phy_ctrl;
+   break;
+   }
+   }
+
+   if (i == ARRAY_SIZE(sig_atten_lu))
+   dev_warn(dev, "unknown signal attenuation values, using 
default PHY ctrl config\n");
+   }
+
for (i = 0; i < hisi_hba->n_phy; i++) {
hisi_sas_phy_write32(hisi_hba, i, PROG_PHY_LINK_RATE, 0x855);
-   hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, 0x30b9908);
+   hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, sas_phy_ctrl);
hisi_sas_phy_write32(hisi_hba, i, SL_TOUT_CFG, 0x7d7d7d7d);
hisi_sas_phy_write32(hisi_hba, i, SL_CONTROL, 0x0);
hisi_sas_phy_write32(hisi_hba, i, TXID_AUTO, 0x2);
-- 
1.9.1

[PATCH 1/8] dt-bindings: scsi: hisi_sas: add an property of signal attenuation

2018-02-19 Thread John Garry 
From: Xiaofei Tan 

For some new boards with hip07 chipset we are required to
set PHY config registers differently. The hw property which
determines how to set these registers is in the PHY signal
attenuation readings.

This patch add an devicetree property, signal-attenuation, which
is used to describe the signal attenuation of an board.

Cc: Rob Herring 
Cc: Mark Rutland 
Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
index df3bef7..bd32ecd 100644
--- a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
@@ -53,6 +53,13 @@ Main node required properties:
 Optional main node properties:
  - hip06-sas-v2-quirk-amt : when set, indicates that the v2 controller has the
"am-max-transmissions" limitation.
+ - signal-attenuation : array of 3 32-bit values, containing de-emphasis,
+   preshoot, and boost attenuation readings for the board. They
+   are used to describe the signal attenuation of the board. These
+   values' range is 7600 to 12400, and used to represent -24dB to
+   24dB.
+   The formula is "y = (x-1)/1". For example, 10478
+   means 4.78dB.
 
 Example:
sas0: sas@c100 {
-- 
1.9.1

Re: [PATCH] libiscsi: ensure session spin lock usage consistent

2018-02-19 Thread Lee Duncan 
On 02/07/2018 09:17 PM, Chris Leech wrote:
> I overlooked it by mentally swapping out the session->lock in the patch
> for session->frwd_lock from the warning when looking at this, but what
> kernel was this patch built against?  It doesn't have the
> frwd_lock/back_lock split stuff.
> 
> - Chris
> 

Please disregard this patch set.

It was based on the wrong branch of linux-scsi.

I will resubmit V2 soon.

Thank you for your reviews.
-- 
Lee Duncan

Re: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

2018-02-19 Thread Arnd Bergmann 
On Tue, Feb 13, 2018 at 11:14 AM, Li Wei  wrote:
> add ufs node document for Hisilicon.
>
> Signed-off-by: Li Wei 
> ---
>  Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt


I'm pretty sure we've discussed it before, but can you make this so that
the generic properties are part of the ufshcd binding, and you refer to it
from here, only describing in what ways the hisi ufs binding differs from
the standard?

> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt 
> b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> new file mode 100644
> index ..0d21b57496cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> @@ -0,0 +1,37 @@
> +* Hisilicon Universal Flash Storage (UFS) Host Controller
> +
> +UFS nodes are defined to describe on-chip UFS hardware macro.
> +Each UFS Host Controller should have its own node.
> +
> +Required properties:
> +- compatible: compatible list, contains one of the following -
> +   "hisilicon,hi3660-ufs", 
> "jedec,ufs-1.1" for hisi ufs
> +   host controller present on Hi36xx 
> chipset.
> +- reg   : should contain UFS register address space & UFS SYS 
> CTRL register address,
> +- interrupt-parent  : interrupt device
> +- interrupts: interrupt number
> +- clocks   : List of phandle and clock specifier pairs
> +- clock-names   : List of clock input name strings sorted in the same
> +   order as the clocks property. 
> "ref_clk", "phy_clk" is optional

The clock names sound generic enough, should we have both in the
generic binding?

> +- resets: reset node register, one reset the clk and the other 
> reset the controller
> +- reset-names   : describe reset node register

This looks incomplete. What is the name of the reset line supposed to be?
I'd also suggest you document it in the ufshcd binding instead.

  Arnd

RE: [PATCH v2 1/2] scsi: mpt3sas: fix oops in error handlers after shutdown/unload

2018-02-19 Thread Sreekanth Reddy 
-Original Message-
From: Mauricio Faria de Oliveira [mailto:mauri...@linux.vnet.ibm.com]
Sent: Saturday, February 17, 2018 4:10 AM
To: linux-scsi@vger.kernel.org; bart.vanass...@wdc.com;
sreekanth.re...@broadcom.com
Cc: sathya.prak...@broadcom.com; chaitra.basa...@broadcom.com;
suganath-prabu.subram...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com; dougm...@linux.vnet.ibm.com
Subject: [PATCH v2 1/2] scsi: mpt3sas: fix oops in error handlers after
shutdown/unload

This patch adds checks for 'ioc->remove_host' in the SCSI error handlers,
so not to access pointers/resources potentially freed in the PCI
shutdown/module unload path.  The error handlers may be invoked after
shutdown/unload, depending on other components.

This problem was observed with kexec on a system with a mpt3sas based
adapter and an infiniband adapter which takes long enough to shutdown:

The mpt3sas driver finished shutting down / disabled interrupt handling,
thus some commands have not finished and timed out.

Since the system was still running (waiting for the infiniband adapter to
shutdown), the scsi error handler for task abort of mpt3sas was invoked,
and hit an oops -- either in scsih_abort() because 'ioc->scsi_lookup' was
NULL (without commit dbec4c90
"scsi: mpt3sas: lockless command submission"), or later up in
scsih_host_reset() (with or without that commit), because it eventually
called mpt3sas_base_get_iocstate().

After commit dbec4c90, the oops in scsih_abort() does not occur anymore
(_scsih_scsi_lookup_find_by_scmd() is no longer called), but that commit
is too big and out of the scope of linux-stable, where this patch might
help, so still go for the changes.

Also, this might help to prevent similar errors in the future, in case
code changes and possibly tries to access freed stuff.

Note the fix in scsih_host_reset() is still important anyway.

Signed-off-by: Mauricio Faria de Oliveira 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 74fca18..5ab3caf 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2835,7 +2835,8 @@ int mpt3sas_scsih_issue_locked_tm(struct
MPT3SAS_ADAPTER *ioc, u16 handle,
_scsih_tm_display_info(ioc, scmd);

sas_device_priv_data = scmd->device->hostdata;
-   if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
+   if (!sas_device_priv_data || !sas_device_priv_data->sas_target ||
+   ioc->remove_host) {
sdev_printk(KERN_INFO, scmd->device,
"device been deleted! scmd(%p)\n", scmd);
scmd->result = DID_NO_CONNECT << 16;
@@ -2898,7 +2899,8 @@ int mpt3sas_scsih_issue_locked_tm(struct
MPT3SAS_ADAPTER *ioc, u16 handle,
_scsih_tm_display_info(ioc, scmd);

sas_device_priv_data = scmd->device->hostdata;
-   if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
+   if (!sas_device_priv_data || !sas_device_priv_data->sas_target ||
+   ioc->remove_host) {
sdev_printk(KERN_INFO, scmd->device,
"device been deleted! scmd(%p)\n", scmd);
scmd->result = DID_NO_CONNECT << 16;
@@ -2961,7 +2963,8 @@ int mpt3sas_scsih_issue_locked_tm(struct
MPT3SAS_ADAPTER *ioc, u16 handle,
_scsih_tm_display_info(ioc, scmd);

sas_device_priv_data = scmd->device->hostdata;
-   if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
+   if (!sas_device_priv_data || !sas_device_priv_data->sas_target ||
+   ioc->remove_host) {
starget_printk(KERN_INFO, starget, "target been deleted!
scmd(%p)\n",
scmd);
scmd->result = DID_NO_CONNECT << 16;
@@ -3019,7 +3022,7 @@ int mpt3sas_scsih_issue_locked_tm(struct
MPT3SAS_ADAPTER *ioc, u16 handle,
ioc->name, scmd);
scsi_print_command(scmd);

-   if (ioc->is_driver_loading) {
+   if (ioc->is_driver_loading || ioc->remove_host) {
pr_info(MPT3SAS_FMT "Blocking the host reset\n",
ioc->name);
r = FAILED;
--
1.8.3.1


Acked-by: Sreekanth Reddy 

Thanks,
Sreekanth

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

2018-02-19 Thread Max Ivanov 
Neither it was backported:

$ git log --grep 'commit 81b6c99' v4.14..v4.14.20

I'll try to apply it and see if it fixes my problem. If it does, what
would be the proccess of backporting this patch to 4.14?

On 19 February 2018 at 08:08, Max Ivanov  wrote:
> It seems that commit 81b6c9998979 ('scsi: core: check for device state
> in __scsi_remove_target()') didn't make it to 4.14 branch
>
> $ git tag --contains 81b6c9998979
> v4.15
> v4.15-rc6
> v4.15-rc7
> v4.15-rc8
> v4.15-rc9
> v4.15.1
> v4.15.2
> v4.15.3
> v4.15.4
> v4.16-rc1
> v4.16-rc2
>
> On 19 February 2018 at 06:56, Hannes Reinecke  wrote:
>> On 02/18/2018 07:33 PM, Max Ivanov wrote:
>>> Hi,
>>>
>>> on my system I can't logout from iSCSI session when on 4.4.18, but
>>> 4.3.19 works just fine. git bisect points to  fbce4d97fd ("scsi: fixup
>>> kernel warning during rmmod()")
>>>
>>> Bug manifests itself like following:
>>>   - iSCSI session logout hangs and never completes
>>>   - 1 kworker per iSCSI session start consuming 100% CPU
>>>   - very shortly one of 2 errors show up in dmesg (full listings are below):
>>>   * kernel: list_del corruption, 88c1cd6bb810->next is LIST_POISON1
>>>   * kernel BUG at mm/slub.c:295!
>>>
>>> Ways to trigger bug:
>>>   1. initiate iSCSI sessions to multiple portals
>>>   2. let multipathd to create multipath devices
>>>   3. run 'iscsiadm -m node --logoutall=all'
>>>
>>> Bugs is NOT triggered and iSCSI logout succeeds when either:
>>>   - multipathd is masked and never started
>>>   - I manually delete all scsi devices via /sys/block/$d/device/delete
>>> before attempting
>>> to do iSCSI logout
>>>
>>> list_del_corrpution:
>>>
>>> Feb 16 10:37:11 localhost.localdomain kernel: alua: device handler 
>>> registered
>>> Feb 16 10:37:11 localhost.localdomain kernel: emc: device handler registered
>>> Feb 16 10:37:11 localhost.localdomain kernel: rdac: device handler 
>>> registered
>>> Feb 16 10:37:11 localhost.localdomain kernel: device-mapper: multipath
>>> service-time: version 0.3.0 loaded
>>> Feb 16 10:38:38 localhost.localdomain kernel: list_del corruption,
>>> 88c1cd6bb810->next is LIST_POISON1 (dead0100)
>>> Feb 16 10:38:38 localhost.localdomain kernel: [ cut here
>>> ]
>>> Feb 16 10:38:38 localhost.localdomain kernel: kernel BUG at 
>>> lib/list_debug.c:47!
>>> Feb 16 10:38:38 localhost.localdomain kernel: invalid opcode:  [#1] SMP 
>>> PTI
>>> Feb 16 10:38:38 localhost.localdomain kernel: Modules linked in:
>>> dm_service_time dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua
>>> binfmt_misc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
>>> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink
>>> ebtable_nat ebtable_broute bridge stp llc ip6tabl
>>> Feb 16 10:38:38 localhost.localdomain kernel:  pata_acpi
>>> Feb 16 10:38:38 localhost.localdomain kernel: CPU: 2 PID: 5 Comm:
>>> kworker/u24:0 Not tainted 4.14.18-300.fc27.x86_64 #1
>>> Feb 16 10:38:38 localhost.localdomain kernel: Hardware name: VMware,
>>> Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS
>>> 6.00 09/21/2015
>>> Feb 16 10:38:38 localhost.localdomain kernel: Workqueue: scsi_wq_5
>>> __iscsi_unbind_session [scsi_transport_iscsi]
>>> Feb 16 10:38:38 localhost.localdomain kernel: task: 88bdede83e80
>>> task.stack: b15043158000
>>> Feb 16 10:38:38 localhost.localdomain kernel: RIP:
>>> 0010:__list_del_entry_valid+0x4e/0x90
>>> Feb 16 10:38:38 localhost.localdomain kernel: RSP:
>>> 0018:b1504315bd88 EFLAGS: 00010082
>>> Feb 16 10:38:38 localhost.localdomain kernel: RAX: 004e
>>> RBX: 88c1cd6bbf38 RCX: 
>>> Feb 16 10:38:38 localhost.localdomain kernel: RDX: 
>>> RSI: 88bdefc96a38 RDI: 88bdefc96a38
>>> Feb 16 10:38:38 localhost.localdomain kernel: RBP: 0246
>>> R08: 07be R09: 00aa
>>> Feb 16 10:38:38 localhost.localdomain kernel: R10: b1504315bd58
>>> R11:  R12: 88c1ebb659c0
>>> Feb 16 10:38:38 localhost.localdomain kernel: R13: 88bdec827010
>>> R14: 88c1cd6bb800 R15: 88c1cd6bb800
>>> Feb 16 10:38:38 localhost.localdomain kernel: FS:
>>> () GS:88bdefc8()
>>> knlGS:
>>> Feb 16 10:38:38 localhost.localdomain kernel: CS:  0010 DS:  ES:
>>>  CR0: 80050033
>>> Feb 16 10:38:38 localhost.localdomain kernel: CR2: 563d0c1ed280
>>> CR3: 00057120a001 CR4: 001606e0
>>> Feb 16 10:38:38 localhost.localdomain kernel: Call Trace:
>>> Feb 16 10:38:38 localhost.localdomain kernel:
>>> scsi_device_dev_release_usercontext+0x52/0x250
>>> Feb 16 10:38:38 localhost.localdomain kernel:  ? __schedule+0x10f/0x880
>>> Feb 16 10:38:38 localhost.localdomain kernel:
>>> execute_in_process_context+0x21/0x60
>>> Feb 16 10:38:38 localhost.localdomain kernel:  device_release+0x30/0x80
>>> Feb 16 10:38:38 localhost.localdomain kernel:

Re: [PATCH v3 04/13] lpfc: Add push-to-adapter support to sli4

2018-02-19 Thread Johannes Thumshirn 
On Fri, Feb 16, 2018 at 08:53:44AM -0800, James Smart wrote:
> > Any reason you can't use writeq() on 32 Bit as well? There's a compat 
> > version
> > in linux/io-64-nonatomic-hi-lo.h.
> 
> We actually ran into issues on the existence of writeq() on a 32bit
> platform. Thus this code block.
 
Oh can you elaborate more on the issue? I bet if we merge it that way, someone
comes around with a patch chaning it to writeq() on 32Bit as well.

Wouldn't it be better to improve the 32Bit writeq() code?

Generally speaking (same for the WC issue), ifdefs (especially architecture
specific ones) in driver code should be avoided.

Thanks,
Johannes
-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: iSCSI session logout regression after fbce4d97fd ("scsi: fixup kernel warning during rmmod()")

2018-02-19 Thread Max Ivanov 
It seems that commit 81b6c9998979 ('scsi: core: check for device state
in __scsi_remove_target()') didn't make it to 4.14 branch

$ git tag --contains 81b6c9998979
v4.15
v4.15-rc6
v4.15-rc7
v4.15-rc8
v4.15-rc9
v4.15.1
v4.15.2
v4.15.3
v4.15.4
v4.16-rc1
v4.16-rc2

On 19 February 2018 at 06:56, Hannes Reinecke  wrote:
> On 02/18/2018 07:33 PM, Max Ivanov wrote:
>> Hi,
>>
>> on my system I can't logout from iSCSI session when on 4.4.18, but
>> 4.3.19 works just fine. git bisect points to  fbce4d97fd ("scsi: fixup
>> kernel warning during rmmod()")
>>
>> Bug manifests itself like following:
>>   - iSCSI session logout hangs and never completes
>>   - 1 kworker per iSCSI session start consuming 100% CPU
>>   - very shortly one of 2 errors show up in dmesg (full listings are below):
>>   * kernel: list_del corruption, 88c1cd6bb810->next is LIST_POISON1
>>   * kernel BUG at mm/slub.c:295!
>>
>> Ways to trigger bug:
>>   1. initiate iSCSI sessions to multiple portals
>>   2. let multipathd to create multipath devices
>>   3. run 'iscsiadm -m node --logoutall=all'
>>
>> Bugs is NOT triggered and iSCSI logout succeeds when either:
>>   - multipathd is masked and never started
>>   - I manually delete all scsi devices via /sys/block/$d/device/delete
>> before attempting
>> to do iSCSI logout
>>
>> list_del_corrpution:
>>
>> Feb 16 10:37:11 localhost.localdomain kernel: alua: device handler registered
>> Feb 16 10:37:11 localhost.localdomain kernel: emc: device handler registered
>> Feb 16 10:37:11 localhost.localdomain kernel: rdac: device handler registered
>> Feb 16 10:37:11 localhost.localdomain kernel: device-mapper: multipath
>> service-time: version 0.3.0 loaded
>> Feb 16 10:38:38 localhost.localdomain kernel: list_del corruption,
>> 88c1cd6bb810->next is LIST_POISON1 (dead0100)
>> Feb 16 10:38:38 localhost.localdomain kernel: [ cut here
>> ]
>> Feb 16 10:38:38 localhost.localdomain kernel: kernel BUG at 
>> lib/list_debug.c:47!
>> Feb 16 10:38:38 localhost.localdomain kernel: invalid opcode:  [#1] SMP 
>> PTI
>> Feb 16 10:38:38 localhost.localdomain kernel: Modules linked in:
>> dm_service_time dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua
>> binfmt_misc iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
>> ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink
>> ebtable_nat ebtable_broute bridge stp llc ip6tabl
>> Feb 16 10:38:38 localhost.localdomain kernel:  pata_acpi
>> Feb 16 10:38:38 localhost.localdomain kernel: CPU: 2 PID: 5 Comm:
>> kworker/u24:0 Not tainted 4.14.18-300.fc27.x86_64 #1
>> Feb 16 10:38:38 localhost.localdomain kernel: Hardware name: VMware,
>> Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS
>> 6.00 09/21/2015
>> Feb 16 10:38:38 localhost.localdomain kernel: Workqueue: scsi_wq_5
>> __iscsi_unbind_session [scsi_transport_iscsi]
>> Feb 16 10:38:38 localhost.localdomain kernel: task: 88bdede83e80
>> task.stack: b15043158000
>> Feb 16 10:38:38 localhost.localdomain kernel: RIP:
>> 0010:__list_del_entry_valid+0x4e/0x90
>> Feb 16 10:38:38 localhost.localdomain kernel: RSP:
>> 0018:b1504315bd88 EFLAGS: 00010082
>> Feb 16 10:38:38 localhost.localdomain kernel: RAX: 004e
>> RBX: 88c1cd6bbf38 RCX: 
>> Feb 16 10:38:38 localhost.localdomain kernel: RDX: 
>> RSI: 88bdefc96a38 RDI: 88bdefc96a38
>> Feb 16 10:38:38 localhost.localdomain kernel: RBP: 0246
>> R08: 07be R09: 00aa
>> Feb 16 10:38:38 localhost.localdomain kernel: R10: b1504315bd58
>> R11:  R12: 88c1ebb659c0
>> Feb 16 10:38:38 localhost.localdomain kernel: R13: 88bdec827010
>> R14: 88c1cd6bb800 R15: 88c1cd6bb800
>> Feb 16 10:38:38 localhost.localdomain kernel: FS:
>> () GS:88bdefc8()
>> knlGS:
>> Feb 16 10:38:38 localhost.localdomain kernel: CS:  0010 DS:  ES:
>>  CR0: 80050033
>> Feb 16 10:38:38 localhost.localdomain kernel: CR2: 563d0c1ed280
>> CR3: 00057120a001 CR4: 001606e0
>> Feb 16 10:38:38 localhost.localdomain kernel: Call Trace:
>> Feb 16 10:38:38 localhost.localdomain kernel:
>> scsi_device_dev_release_usercontext+0x52/0x250
>> Feb 16 10:38:38 localhost.localdomain kernel:  ? __schedule+0x10f/0x880
>> Feb 16 10:38:38 localhost.localdomain kernel:
>> execute_in_process_context+0x21/0x60
>> Feb 16 10:38:38 localhost.localdomain kernel:  device_release+0x30/0x80
>> Feb 16 10:38:38 localhost.localdomain kernel:  kobject_put+0x80/0x1a0
>> Feb 16 10:38:38 localhost.localdomain kernel:  scsi_remove_target+0x16d/0x1b0
>> Feb 16 10:38:38 localhost.localdomain kernel:
>> __iscsi_unbind_session+0xad/0x150 [scsi_transport_iscsi]
>> Feb 16 10:38:38 localhost.localdomain kernel:  process_one_work+0x184/0x3a0
>> Feb 16 10:38:38 localhost.localdomain kernel:  worker_thread+0x2e/0x380
>> Feb 16 10:38:38