Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2420698pxb; Fri, 8 Oct 2021 07:28:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2/OAlN0WYZ2wHwFvVGXeU44JoUosCy47AvlQ0UpmDVAmhb02ENTFQBpNEHW31Vjycs1/L X-Received: by 2002:a17:906:1359:: with SMTP id x25mr4745135ejb.145.1633703339658; Fri, 08 Oct 2021 07:28:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633703339; cv=none; d=google.com; s=arc-20160816; b=OQae5n2hZuIV9nDEGFQqjFgeYCEedF6qRzF1WQWPYICXX2gqE5lLRaJiofUBSgmDIB 8hLywCkxUhDa7GZGTCQogx0BR5ntaK67eAXyu75XdYZeXPQavsokn+0xCtZ5k1fXGK16 gohpHJOLNWvLigUFkC8v3RWzOUisAn/4ZFY+w6Zg1yj6678eMwewimOjYF2TmuKvDnN0 wXCJNEkB+8VFnPgXO647DN51Je8QQHENEvQ9RNT5D8rdiUjic+wMVd2pB94VbN3eMTsv OUsZyshsU8GQ8Y2GPWPX3YWiaZgtViq7Pzmb52r9Y/BpvVV3AGlLwoKHElDsTiyOhmFO sgQQ== 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=LMrw609vSy5pCMRwoYaK5qxaZ+4hGT72FgpxkKKnM/4=; b=p+yZUNnMMMIgT7uK3Fm1H5Zccdmd0AobmJZNK/kseLjgFcr5TGLuAmq87cvTluDFLb fmNm720qxz/YYldMVWou513ZgQ22/R5B3XR9Mb9D2+jVrT5ClTcBa7Fekkfx/LCvZXLr cJHgxrMOqII58zJH//XEO7Wf2hE5RZd5/3n6sQ9g8OfSomhOcpxB/wZC6m6TOcFeOlx1 aVwv2qh9YjGpp+QaFqIzVFtx5hH9TKiBnmVSsJx7NyFXs74QIhVW1JHaNGQYeyraLf55 jrbJog8EKROP7iNyG3+z0F1AmVBelRo5S/gD8AfBbhw8kfRU4rmdcPeMJpRbSqJV3DCv ooeQ== 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 s12si3337174ejc.488.2021.10.08.07.28.29; Fri, 08 Oct 2021 07:28:59 -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 S231231AbhJHO2k (ORCPT + 99 others); Fri, 8 Oct 2021 10:28:40 -0400 Received: from netrider.rowland.org ([192.131.102.5]:51023 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S230434AbhJHO2g (ORCPT ); Fri, 8 Oct 2021 10:28:36 -0400 Received: (qmail 721833 invoked by uid 1000); 8 Oct 2021 10:26:39 -0400 Date: Fri, 8 Oct 2021 10:26:39 -0400 From: Alan Stern To: Yinbo Zhu Cc: Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Patchwork Bot Subject: Re: [PATCH v3] usb: ohci: add check for host controller functional states Message-ID: <20211008142639.GA721194@rowland.harvard.edu> References: <1633677970-10619-1-git-send-email-zhuyinbo@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1633677970-10619-1-git-send-email-zhuyinbo@loongson.cn> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote: > The usb states of ohci controller include UsbOperational, UsbReset, > UsbSuspend and UsbResume. Among them, only the UsbOperational state > supports launching the start of frame for host controller according > the ohci protocol spec, but in S3/S4 press test procedure, it may Nobody reading this will know what "S3/S4 press test procedure" means. You have to explain it, or use a different name that people will understand. > happen that the start of frame was launched in other usb states and > cause ohci works abnormally then kernel will allways report rcu > call trace. This patch was to add check for host controller > functional states and if it is not UsbOperational state that need > set INTR_SF in intrdisable register to ensure SOF Token generation > was been disabled. This doesn't make sense. You already mentioned that only the UsbOperational state supports sending start-of-frame packets. So if the controller is in a different state then it won't send these packets, whether INTR_SF is enabled or not. What problem are you really trying to solve? > Signed-off-by: Yinbo Zhu > --- > Change in v3: > Rework the commit information. > Move the patch code change to lower down position in ohci_irq. > > > drivers/usb/host/ohci-hcd.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c > index 1f5e693..87aa9bb 100644 > --- a/drivers/usb/host/ohci-hcd.c > +++ b/drivers/usb/host/ohci-hcd.c > @@ -879,7 +879,8 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd) > { > struct ohci_hcd *ohci = hcd_to_ohci (hcd); > struct ohci_regs __iomem *regs = ohci->regs; > - int ints; > + int ints, ctl; > + Extra blank line not needed. > > /* Read interrupt status (and flush pending writes). We ignore the > * optimization of checking the LSB of hcca->done_head; it doesn't > @@ -969,9 +970,15 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd) > * when there's still unlinking to be done (next frame). > */ > ohci_work(ohci); > - if ((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list > - && ohci->rh_state == OHCI_RH_RUNNING) > + > + ctl = ohci_readl(ohci, ®s->control); > + Blank lines not needed. > + if (((ints & OHCI_INTR_SF) != 0 && !ohci->ed_rm_list > + && ohci->rh_state == OHCI_RH_RUNNING) || > + ((ctl & OHCI_CTRL_HCFS) != OHCI_USB_OPER)) { > ohci_writel (ohci, OHCI_INTR_SF, ®s->intrdisable); > + (void)ohci_readl(ohci, ®s->intrdisable); > + } This is definitely wrong. You must not turn off SF interrupts when ed_rm_list is non-NULL. If you do, the driver will not be able to finish unlinking URBs. Alan Stern