Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp13918lfv; Tue, 12 Apr 2022 15:18:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8GYZXLYAhCR/x1Nlgyz9dNh06MN558WNfTc0miEGSa+9yOJpwXLqz1586WvQpJBPokAg4 X-Received: by 2002:a17:902:7d93:b0:14d:d401:f59b with SMTP id a19-20020a1709027d9300b0014dd401f59bmr40449615plm.14.1649801886641; Tue, 12 Apr 2022 15:18:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649801886; cv=none; d=google.com; s=arc-20160816; b=NHzl7ww3ttI1PwiBIkbjmUDbowXRh/OX+EVWE75ZIpH3fWzJJqQI98YvhAPQ/jeGj+ EJicL2WBGSqWMC8bJes5CgCKG/yGn8DoJWmiRXNmHn1YSfamFWM3Xs11k+fCIGn/ka53 NvQla8/ED62L6onk5MPFTbL1dec4XnSHbUB2hl44ENAfc91SDN0Rm6Y7AP6mzLpFv8Qm x+Duj9I+zPhXPvdLpUzs/oXkeudfPMsZYi00xLp+/uP9sAjqzcx8SWfohLNHuKgXxUh2 cgDyc3Ni1tt+kF0/R0rCxuN/o2s9TSF5zfx6vOrPNdHy+tUMjqkhQD6F9+gdsJG+vmWD PqUA== 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=yxAhydEf+3Tclr6XjOEfHYRU9PBKY7UXytrNsJQjOrA=; b=fYvXQQ2epvwJqfSWTobHmSjP3W8Ob6MdzI9KUAfubMOihpBuv6TXAxrzdofO9k76H8 ZQFtCzcXdLThLIJvR+7n7+nAAM1R7QXVJL+9VII9bR7+CIRjBdTEm5i0s82hsdYXuOHU LU773Ib/Qx5r1oI9TXzsep8gRaEWpwJKTLYHTPoIxxM1uhYDbUH1ZXBw6DICtzny9oUT 4E5lSjoa17v8E4Ze/DTxgNiRm9d69oMu11cVrJOcFrAQblztzuuq9lGqQRtD2tv0AYwu jMUOHPMNUyZhBVlOSxj+7j7czbOQCPwTZTYxqGxwxKrReL75CR+h/e/16rn2XkILb+xR hy8w== 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 c31-20020a634e1f000000b0039d20aca3f3si3772285pgb.431.2022.04.12.15.18.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 15:18:06 -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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D1B18D0AA1; Tue, 12 Apr 2022 13:59:45 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357198AbiDLPnL (ORCPT + 99 others); Tue, 12 Apr 2022 11:43:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357332AbiDLPnF (ORCPT ); Tue, 12 Apr 2022 11:43:05 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 2137D5D661 for ; Tue, 12 Apr 2022 08:40:47 -0700 (PDT) Received: (qmail 377970 invoked by uid 1000); 12 Apr 2022 11:40:46 -0400 Date: Tue, 12 Apr 2022 11:40:45 -0400 From: Alan Stern To: Mathias Nyman Cc: Evan Green , Greg Kroah-Hartman , Mathias Nyman , Rajat Jain , Thomas Gleixner , Bjorn Helgaas , "Rafael J. Wysocki" , Youngjin Jang , LKML , linux-usb@vger.kernel.org Subject: Re: [PATCH] USB: hcd-pci: Fully suspend across freeze/thaw cycle Message-ID: References: <20220407115918.1.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid> <022a50ac-7866-2140-1b40-776255f3a036@linux.intel.com> <4353a956-9855-9c14-7dbf-bf16580abe32@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4353a956-9855-9c14-7dbf-bf16580abe32@linux.intel.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 Tue, Apr 12, 2022 at 05:56:42PM +0300, Mathias Nyman wrote: > On 11.4.2022 17.50, Alan Stern wrote: > > For example, what would happen if the user unplugs a device right in the > > middle of the freeze transition, after the root hub has been frozen but > > before the controller is frozen? We don't want such an unplug event to > > prevent the system from going into hibernation -- especially if the root > > hub was not enabled for wakeup. > > We should be able to let system go to hibernate even if we get a disconnect > interrupt between roothub and host controller freeze. > Host is not yet suspended so no PME# wake is generated, only an interrupt. > > From Linux PM point of view it should be ok as well as the actual xhci > device that is generating the interrupt is hasnt completer freeze() > > The xhci interrupt handler just needs to make sure that the disconnect > isn't propagated if roothub is suspended and wake on disconnect > is not set. And definitely make sure xhci doesn't start roothub polling. > > When freeze() is called for the host we should prevent the host from > generating interrupts. I guess that means adding a new callback. Or we could just suspend the controller, like Evan proposed originally. > > (If the root hub _is_ enabled for wakeup then it's questionable. > > Unplugging a device would be a wakeup event, so you could easily argue > > that it _should_ prevent the system from going into hibernation. After > > all, if the unplug happened a few milliseconds later, after the system > > had fully gone into hibernation, then it would cause the system to wake > > up.) > > > >> Would it make sense prevent xHCI interrupt generation in the host > >> freeze() stage, clearing the xHCI EINT bit in addition to calling > >> check_roothub_suspend()? > >> Then enable it back in thaw() > > > > That won't fully eliminate the problem mentioned in the preceding > > paragraphs, although I guess it would help somewhat. > > Would the following steps solve this? > > 1. Disable device initiated resume for connected usb devices in freeze() > > 2. Don't propagate connect or OC changes if roothub is suspended and port wake > flags are disabled. I.E don't kick roothub polling in xhci interrupt > handler here. I guess you can't just halt the entire host controller when only one of the root hubs is suspended with wakeup disabled. That does complicate things. But you could halt it as soon as both of the root hubs are frozen. Wouldn't that prevent interrupt generation? > 3 Disable host interrupt generation in host freeze(), and re-enable in thaw() And then this step wouldn't be necessary, right? Alan Stern