Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1148600pxf; Fri, 2 Apr 2021 02:34:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwecf8GFa4PunPqiPbXVepYFLx3i+0xitVarjjceNtD783AiMhxXBjP6URQ7QP7vGYG4Wdq X-Received: by 2002:a05:6402:5252:: with SMTP id t18mr14878118edd.258.1617356040128; Fri, 02 Apr 2021 02:34:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617356040; cv=none; d=google.com; s=arc-20160816; b=J7zTR7VL4vqPDGHJCiYuawS5Sj1kSwVCHCa10IYPng8RJ/w7mSbTf9VL53ZjQ8aQLL oZm94ABOiSk+/BkVcpfgSOsu0tJKT1+Ysf2s1TfsdiQUlRJG/+1r95LYYxl4J8HPIipU jq7HeFo2eLJUNDR0bK8FxD7n5taNXHr8FO0xocX4a6alr30y+GfZGMAXY8PdSzPPUI/o qLnZKRVCcqwD5AMsowQuJj421Mcr6dQfzk2QiT9JR9U6xuxk7+pcpwmpFMPsTqDrA4cN 4JdMxn9ZOPjB5WWXZWHTpsXC11YxNKK9ewOHrJ0GB1F2FtecXWRpn2GUaEBJRMANF2se oZUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=9EHSk74tyFhJFGD1Mfv9VYcbtsxfr8LlMdawloJhkUU=; b=nZjbDIIUcYQX923LQcd4LJisjtfVW/waARM2/oE+zzLO6nf6yicCawRNPmJcKomIc/ dChQcYxiiAOf79z2UFwPoA/B3575cAg9jmKgyMx0RxCGu/ZqdOKXhJzXptLwuvTj9KDb b4MyDxgCBqW05tnXMDrlcXesmNVd0swedNrIn3z9dC7hq9cARwCbdJ7wjVzdL9voj0Rw qwgF/UBaT9Mt2Ud+vmpnT8zp/h+6NYSy3AgLWSNsfdzI1S86Dh7WRQhF1hdexec+7QZ9 ECWTYYOiz26LpfOGWENof+o3G/QTCiq9JkDScG9zojfaFZZw4uxCcY1SQFl7AJxGS0Oq N4mA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si6200468edt.518.2021.04.02.02.33.36; Fri, 02 Apr 2021 02:34:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234856AbhDBJam (ORCPT + 99 others); Fri, 2 Apr 2021 05:30:42 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:14685 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229553AbhDBJal (ORCPT ); Fri, 2 Apr 2021 05:30:41 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FBZTp35DwznY7H; Fri, 2 Apr 2021 17:27:58 +0800 (CST) Received: from huawei.com (10.67.165.24) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Fri, 2 Apr 2021 17:30:29 +0800 From: Longfang Liu To: , , CC: , , , , Subject: [PATCH] USB:ohci:fix ohci interruption problem Date: Fri, 2 Apr 2021 17:27:59 +0800 Message-ID: <1617355679-9417-1-git-send-email-liulongfang@huawei.com> X-Mailer: git-send-email 2.8.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.165.24] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The operating method of the system entering S4 sleep mode: echo disk > /sys/power/state When OHCI enters the S4 sleep state, the USB sleep process will call check_root_hub_suspend() and ohci_bus_suspend() instead of ohci_suspend() and ohci_bus_suspend(), this causes the OHCI interrupt to not be closed. At this time, if just one device interrupt is reported. Since rh_state has been changed to OHCI_RH_SUSPENDED after ohci_bus_suspend(), the driver will not process and close this device interrupt. It will cause the entire system to be stuck during sleep, causing the device to fail to respond. When the abnormal interruption reaches 100,000 times, the system will forcibly close the interruption and make the device unusable. Because the root cause of the problem is that ohci_suspend is not called to perform normal interrupt shutdown operations when the system enters S4 sleep mode. Therefore, our solution is to specify freeze interface in this mode to perform normal suspend_common() operations, and call ohci_suspend() after check_root_hub_suspend() is executed through the suspend_common() operation. After using this solution, it is verified by the stress test of sleep wake up in S4 mode for a long time that this problem no longer occurs. Signed-off-by: Longfang Liu --- drivers/usb/core/hcd-pci.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c index 1547aa6..c5844a3 100644 --- a/drivers/usb/core/hcd-pci.c +++ b/drivers/usb/core/hcd-pci.c @@ -509,6 +509,11 @@ static int resume_common(struct device *dev, int event) #ifdef CONFIG_PM_SLEEP +static int hcd_pci_freeze(struct device *dev) +{ + return suspend_common(dev, device_may_wakeup(dev)); +} + static int hcd_pci_suspend(struct device *dev) { return suspend_common(dev, device_may_wakeup(dev)); @@ -605,7 +610,7 @@ const struct dev_pm_ops usb_hcd_pci_pm_ops = { .suspend_noirq = hcd_pci_suspend_noirq, .resume_noirq = hcd_pci_resume_noirq, .resume = hcd_pci_resume, - .freeze = check_root_hub_suspended, + .freeze = hcd_pci_freeze, .freeze_noirq = check_root_hub_suspended, .thaw_noirq = NULL, .thaw = NULL, -- 2.8.1