Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp946913pxp; Wed, 16 Mar 2022 22:15:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMBHRkMq0KRALCzFnDOUbc0a9RPA6lYL9TZB3NJf3W+xilw+i6SlPH+3f8DdCee5A2hOTw X-Received: by 2002:a17:903:110d:b0:14f:72a1:7b18 with SMTP id n13-20020a170903110d00b0014f72a17b18mr2974685plh.111.1647494140565; Wed, 16 Mar 2022 22:15:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647494140; cv=none; d=google.com; s=arc-20160816; b=DT8VTo4zFk0nAJN2WRdmgUiPfUDnQiUrNtJXd42QZu11j5P0AO8UEG864UHC2PQ8Yn 7XyVqWdkvoEFN4Ejtv1dVsdTV6MRNq4lzgva/N0OcoQSleC/cAZl5+iKMdXUC6Enp0fi r5lzwGUSkGiStQmOqZJ5UQZH8s6u4JTZZWPsVCYbcnuDPo72quZ5Rn6eURQIkPnSR9vJ WrmeTEcw1GebqJ0GHSKdI+l+isH60luxeWBP9UCgsVxC2MNGBt9jU1zVsdk0XKhfIpvx y1JPFWSxeUfqpVNsFVljc+k5NoVX7idzuVA+MkVFgx/DqAu91smSsZf9v8FhsMjlf2oF zBkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=7uWWz/exUTBSn7+vH1D6sVEtq5f5iiFrrt/Ab88aGEY=; b=P2lLa6lRbNN2+DzLQeMn3yJUlAfa7rfmlJSpLAenuNlCUfS1PofARqwMuSuZbuVbO0 dG1bqvx/Ohhc6C2M3BEr8scdYiAcFwPmb5fFkX+vxqBiHP0MZcXtJGMFUjPhHomclEj2 F8lXMrfP0b5yy+d6tLe2pT2zcs00CYlAMYxTB39SJ1wNHBM8g6aEoOHtE+fP2Hz56Zb5 gY9lpDJASuMdMD+fvo+JRgtzX7go4RyE5CVp8MHypCtR/zyfikA3MEA4jo3s79mb9/oo CGpl4RKa6+esPenpfEVcDpuoLX7MVmnzCb+t17roSaNrUbZ6BFzFHyxU+AFeS1JwblSU xL5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h68-20020a636c47000000b003816043eff6si1024132pgc.491.2022.03.16.22.15.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 22:15:40 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7D4F71E5A70; Wed, 16 Mar 2022 21:23:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239790AbiCNOZs (ORCPT + 99 others); Mon, 14 Mar 2022 10:25:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232574AbiCNOZr (ORCPT ); Mon, 14 Mar 2022 10:25:47 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 3131527FC5 for ; Mon, 14 Mar 2022 07:24:35 -0700 (PDT) Received: (qmail 1680880 invoked by uid 1000); 14 Mar 2022 10:24:34 -0400 Date: Mon, 14 Mar 2022 10:24:34 -0400 From: Alan Stern To: "WeitaoWang-oc@zhaoxin.com" Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, CobeChen@zhaoxin.com, TimGuo@zhaoxin.com, tonywwang@zhaoxin.com, weitaowang@zhaoxin.com Subject: Re: [PATCH] USB:Fix ehci infinite suspend-resume loop issue in zhaoxin Message-ID: References: <3d0ae3ca-9dad-bb8f-5c41-45bdcb07b9cd@zhaoxin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d0ae3ca-9dad-bb8f-5c41-45bdcb07b9cd@zhaoxin.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 14, 2022 at 03:35:37PM +0800, WeitaoWang-oc@zhaoxin.com wrote: > In zhaoxin platform, some ehci projects will latch a wakeup signal > internal when plug in a device on port during system S0. This wakeup > signal will turn on when ehci runtime suspend, which will trigger a > system control interrupt that will resume ehci back to D0. As no > device connect, ehci will be set to runtime suspend and turn on the > internal latched wakeup signal again. It will cause a suspend-resume > loop and generate system control interrupt continuously. > > Fixed this issue by clear wakeup signal latched in ehci internal when > ehci resume callback is called. > > Signed-off-by: Weitao Wang > --- > drivers/usb/host/ehci-hcd.c | 26 ++++++++++++++++++++++++++ > drivers/usb/host/ehci-pci.c | 4 ++++ > drivers/usb/host/ehci.h | 1 + > 3 files changed, 31 insertions(+) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 3d82e0b..e4840ef 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -1103,6 +1103,30 @@ static void ehci_remove_device(struct usb_hcd *hcd, > struct usb_device *udev) > > #ifdef CONFIG_PM > > +/* Clear wakeup signal locked in zhaoxin platform when device plug in. */ > +static void ehci_zx_wakeup_clear(struct ehci_hcd *ehci) > +{ > + u32 __iomem *reg = &ehci->regs->port_status[4]; > + u32 t1 = ehci_readl(ehci, reg); The "t1" in this line should start in the same column as the "*reg" in the line above, to match the style of other variable declarations in this file (see ehci_init() as an example). > + > + t1 &= (u32)~0xf0000; > + t1 |= PORT_TEST_FORCE; > + ehci_writel(ehci, t1, reg); > + t1 = ehci_readl(ehci, reg); > + msleep(1); > + t1 &= (u32)~0xf0000; > + ehci_writel(ehci, t1, reg); > + ehci_readl(ehci, reg); > + msleep(1); > + t1 = ehci_readl(ehci, reg); > + ehci_writel(ehci, t1 | PORT_CSC, reg); > + ehci_readl(ehci, reg); > + udelay(500); > + t1 = ehci_readl(ehci, &ehci->regs->status); > + ehci_writel(ehci, t1 & STS_PCD, &ehci->regs->status); > + ehci_readl(ehci, &ehci->regs->status); You should not clear the STS_PCD bit. What if some other port had a status change at the same time? Then because you cleared the port-change-detect bit, the system would not realize that the other port needed to be handled. Leaving the STS_PCD bit turned on will cause the driver to do a little extra work, but it shouldn't cause any harm. > +} > + > /* suspend/resume, section 4.3 */ > > /* These routines handle the generic parts of controller suspend/resume */ > @@ -1154,6 +1178,8 @@ int ehci_resume(struct usb_hcd *hcd, bool force_reset) > if (ehci->shutdown) > return 0; /* Controller is dead */ > > + if (ehci->zx_wakeup_clear == 1) You don't need to check that the value is equal to 1. Treat this more like a Boolean flag and just write: if (ehci->zx_wakeup_clear) Also, to make the flag's meaning more obvious, you might want to name it "zx_wakeup_clear_needed" or "zx_clear_latched_wakeup". Otherwise this patch looks okay. Please submit a revised version, without the whitespace damage. Alan Stern > + ehci_zx_wakeup_clear(ehci); > /* > * If CF is still set and reset isn't forced > * then we maintained suspend power. > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c > index e87cf3a..a5e27de 100644 > --- a/drivers/usb/host/ehci-pci.c > +++ b/drivers/usb/host/ehci-pci.c > @@ -222,6 +222,10 @@ static int ehci_pci_setup(struct usb_hcd *hcd) > ehci->has_synopsys_hc_bug = 1; > } > break; > + case PCI_VENDOR_ID_ZHAOXIN: > + if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == > 0x90) > + ehci->zx_wakeup_clear = 1; > + break; > } > > /* optional debug port, normally in the first BAR */ > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h > index fdd073c..712fdd0 100644 > --- a/drivers/usb/host/ehci.h > +++ b/drivers/usb/host/ehci.h > @@ -220,6 +220,7 @@ struct ehci_hcd { /* one per > controller */ > unsigned imx28_write_fix:1; /* For Freescale i.MX28 > */ > unsigned spurious_oc:1; > unsigned is_aspeed:1; > + unsigned zx_wakeup_clear:1; > > /* required for usb32 quirk */ > #define OHCI_CTRL_HCFS (3 << 6) > -- > 2.7.4