scsi: hisi_sas: Do not reset phy timer to wait for stray phy up
authorLuo Jiaxing <luojiaxing@huawei.com>
Fri, 15 May 2020 14:13:42 +0000 (22:13 +0800)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 20 May 2020 01:23:57 +0000 (21:23 -0400)
We found out that after phy up, the hardware reports another oob interrupt
but did not follow a phy up interrupt:

oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout

We run link reset when wait phy up timeout, and it send a normal disk into
reset processing. So we made some circumvention action in the code, so that
this abnormal oob interrupt will not start the timer to wait for phy up.

Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.com
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/hisi_sas/hisi_sas_main.c

index 9a6deb21fe4dfcf71688ccb72b118693bc387b76..11caa4b0d79773e80f17e38f4653aeeb03b3ac81 100644 (file)
@@ -898,8 +898,11 @@ void hisi_sas_phy_oob_ready(struct hisi_hba *hisi_hba, int phy_no)
        struct hisi_sas_phy *phy = &hisi_hba->phy[phy_no];
        struct device *dev = hisi_hba->dev;
 
+       dev_dbg(dev, "phy%d OOB ready\n", phy_no);
+       if (phy->phy_attached)
+               return;
+
        if (!timer_pending(&phy->timer)) {
-               dev_dbg(dev, "phy%d OOB ready\n", phy_no);
                phy->timer.expires = jiffies + HISI_SAS_WAIT_PHYUP_TIMEOUT * HZ;
                add_timer(&phy->timer);
        }