Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1139671pxf; Fri, 2 Apr 2021 02:14:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBNTq+ZmBtPY/nmTfHT3XX2lH8/P/dIxqQ2+Lbif/ozsCLhwnw3bUJuE5dRArXDm+4Fha/ X-Received: by 2002:a17:906:f9d8:: with SMTP id lj24mr13276482ejb.200.1617354879381; Fri, 02 Apr 2021 02:14:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617354879; cv=none; d=google.com; s=arc-20160816; b=UPLXqT3tXJtWxHWI80Cm56A0B/R0lwtsOeKNTiPKlvMm7/lEqAe1Kl3k6AzdsTTp3O GziX4ehwotq2283XeW6GU1O8M1JpzHr9I/vdEnAmUeNmbfgJZntuZXtLkclI0On+J6t5 SnlJLy5Fz10dLSuzl00U96/fsbw1v9D1XdrolfV0Uhw7Vn7JSxXChEhqxWxBCcz8aEH+ lp7RJATdU+N1sUQiDg7KnTYrDMMvbyk1RE1be8FGQqPxnlhp/eMkgXbtLv9X4+CwWprK Sj6w/nu8U4TOD9jzzpmQTK/pQjoQB189dctPq//GHkItuDQgIO0fPaYhEg92XmI/VoUI L3vQ== 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=RE5fT59nw8fkdJCy8FBhLeFU7QqDIAsEXNOnPDM0A/U=; b=hmm0dOT/UnqEYg8j1++9u9UWa2+teyoJQttLtRaXR/6bOvZsvwpl6xJ8t/kFwq6vpe KaFaOd6n0UGBsHyuY86jP00ZlIDcdl97nTniAYirVPdgOZe9fWRqHr5gatWp/FK1wMS1 f6fLEcmsMeHESIpX1UHDtZ8+8MdBe93Ii4Uh80eSa14e035SlHXOX48Oq2yKVwiGp7S7 5U2RicfSf5pkFDoRrBJmy9JYdkHg7jZfg1cDZ8FWJ0GqhtE+blhOZvEzTwOS3SVJpoYW F7PcuRND9FTYNEEv4O7YfiHBdsMkHBg1EpkRCLD0rko54VDHDMUcJAUY8GKpNi+idVTm 2eNA== 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 h3si274217ejf.479.2021.04.02.02.14.15; Fri, 02 Apr 2021 02:14:39 -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 S234594AbhDBJNj (ORCPT + 99 others); Fri, 2 Apr 2021 05:13:39 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:15468 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234563AbhDBJNi (ORCPT ); Fri, 2 Apr 2021 05:13:38 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FBZ6n5wwXzyNNs; Fri, 2 Apr 2021 17:11:29 +0800 (CST) Received: from huawei.com (10.67.165.24) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Fri, 2 Apr 2021 17:13:30 +0800 From: Longfang Liu To: , , CC: , , , , Subject: [PATCH] USB:ohci:fix ohci interruption problem Date: Fri, 2 Apr 2021 17:11:00 +0800 Message-ID: <1617354660-43964-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 | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c index 1547aa6..78a56cd 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,8 +610,8 @@ 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_noirq = check_root_hub_suspended, + .freeze = hcd_pci_freeze, + .freeze_noirq = hcd_pci_freeze, .thaw_noirq = NULL, .thaw = NULL, .poweroff = hcd_pci_suspend, -- 2.8.1