Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3676406pxf; Mon, 29 Mar 2021 08:29:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOTQcq81pJ+OYLfF70D25+bdaqnhiEk57LLrcYQHhjmiZXtTs4WBcURxkNHphhKLELNnYO X-Received: by 2002:a05:6402:888:: with SMTP id e8mr28525741edy.51.1617031775035; Mon, 29 Mar 2021 08:29:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617031775; cv=none; d=google.com; s=arc-20160816; b=yv63T5ygnhkMaS/0a355wfe9zcjVc3dqrSOMxXvvejV/kbn6+U1Yl22Mr7WvSp35vu mCx4gRbkYYz1w/e2zEa3OtdRILgaorhkY89yjo+oKvcV6gOQOnpCQFIPkV2B0et1KQF3 oGqBFSNYyo5Qvk1wY6gI3CzVyrBnaf2wEJvxZv+IZC3fZzLgp5MiRXbl/PKb48GA3MCK 023Qq0aVo60EGQ1Av2F4jdezCK1XBa6Opn7wKi6E3jLpWqfBgw5N+2U+f4UTSA0TNa1+ VwPOvIQwDlLiuJOkGL2q5Ws8f5XX8X1iMfqH6EqCa4j11wvTqxSbTYSdrCEENGCci3kP wEng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=bYkxUsmu3B3y5/QARU2jOVH8cFZOQBr4/0pdu/fW8wY=; b=h1WsCKVuyRYmpBOi1VY9/PTHagIrDdisPpzX0a5fwKSIsR0c3qjlTvIAv+R2lk7Rz1 wDH1c1MdbUWbFu0AmfnhsSDyX9Nf2b5z1eibXBaO/RTrdHyEf/JPq6eVXz+AB8+GssBj TpJ+luAGoHnhFRSnJPH9BMa9fpaTeWXv2RFeM0yPrvsN2cdIjARP0IM3ykoYok3u8FUM 062JetI+nulXP1Bv8IpHxnAJhgxsG9jkK2/TWcDeByZphGWCd+XX4+6mQQFuyuFlD0s/ +/c/HYyOG89NCQ2PG+xcb5LvqtKlMj3ufgotbmtfczbATkRJrLGMJdxQqow/7pHHNKYP Zg6A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l12si13431936edi.290.2021.03.29.08.29.12; Mon, 29 Mar 2021 08:29:35 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231237AbhC2P0M (ORCPT + 99 others); Mon, 29 Mar 2021 11:26:12 -0400 Received: from netrider.rowland.org ([192.131.102.5]:52361 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S231320AbhC2PZp (ORCPT ); Mon, 29 Mar 2021 11:25:45 -0400 Received: (qmail 936534 invoked by uid 1000); 29 Mar 2021 11:25:44 -0400 Date: Mon, 29 Mar 2021 11:25:44 -0400 From: Alan Stern To: liulongfang Cc: gregkh@linuxfoundation.org, mathias.nyman@intel.com, linux-usb@vger.kernel.org, yisen.zhuang@huawei.com, tanxiaofei@huawei.com, liudongdong3@huawei.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] USB:ohci:fix ohci interruption problem Message-ID: <20210329152544.GB933773@rowland.harvard.edu> References: <1616748896-9415-1-git-send-email-liulongfang@huawei.com> <20210326152821.GA832251@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 29, 2021 at 04:38:10PM +0800, liulongfang wrote: > On 2021/3/26 23:28, Alan Stern wrote: > > On Fri, Mar 26, 2021 at 04:54:56PM +0800, Longfang Liu wrote: > >> 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. > > > > What on earth are you talking about? This isn't true at all. > > > > Can you provide more information about your system? Are you using a > > PCI-based OHCI controller or a platform device (and if so, which one)? > > Can you post system logs to back up your statements? > > The system is UOS, the kernel version is kernel4.19, and the driver > used is ohci-pci.c based on PCI. > > By adding the log in ohci_suspend, and then viewing the dmesg after sleep, > I can confirm that the system does not call ohci_suspend in S4 sleep mode. Then your job is to figure out why not. Doesn't entry into S4 sleep call hcd_pci_suspend() in core/hcd-pci.c, and doesn't that call suspend_common(), and doesn't that call hcd->driver->pci_suspend(), and isn't that routine ohci_suspend()? Alan Stern