Received: by 2002:a05:7412:bc1a:b0:d7:7d3a:4fe2 with SMTP id ki26csp449016rdb; Sat, 19 Aug 2023 08:07:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF6gmM1mzJuZQrLHo6TpvLLn4JWKceW6t/lYswnY/qVeMg0YJp7N/AJhXq7TSbygPdkr17V X-Received: by 2002:a05:6808:21a0:b0:3a1:d457:83b5 with SMTP id be32-20020a05680821a000b003a1d45783b5mr2971185oib.3.1692457671432; Sat, 19 Aug 2023 08:07:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692457671; cv=none; d=google.com; s=arc-20160816; b=yrQ8VlGCdZAaxgz2EEbo2FyW3KuWtQ7iPeuJv7Z2Niz4dLdqU5esFf7cbBjEu35Mzb DYNRb086xVFiOr0SzPWNCkc6ptPPUu8+ruOAMJgfuiX6i2RH/UrZg0n3WfJqPFWj4ooM fV59EMeUlNY8sVZ4NMZrNugsgDASCEe2VrBFWaqNmchIdWq17axg9FwhbA1rdP4Jwutm bD/S2we798sV+xdvMr/pV4YLJEfGhwmjj/oUbFs8wa7dR6N8teHUOuCZTupUoUwIu8Bb 6chTzm5r5B7TMWpAwqt4WOLwslHQoRGOSOyZPEyHEm10pQZR9SqxCi1e+LsK3r3YHK6L C2Og== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=W9SWCkThhf6G7iSpGPM6rr5LMZvJ9rJZVFf8Kdcipy8=; fh=reEYjyP1Mm+PIwHKg06jJJPkJcyvRW+EUfFQCyJnnJw=; b=xRX3F230NeyTg1xAM0zSgwaXFiIr84KZb+gZyxc0x6Xmc9Oi+Gbk+jvoq+TS2Wc7Qa +w02ZWwP6nAS1E54Im9/ewkRnowS/fMhmf7gwKyeb5T21gESEVQRpr6azcp5ihWVjst1 93ENfuXwnU0dtu8PZYGqtV0N3ghEBdCl3KAZ2Qevuy1Q86I6yQDoCmL3MKS6mO15fCS3 OD/bjEK0i6pRPJh1P3D8ATu7RH7Choh6XJanewcR+vCH3TqjYAKcFsBSJeH+LL+7gjBS tRJBUBjQlx3hTVftcNnKQxWAlgzJYnGwvyO9dL6REG7c1KkP6jEBIip7dtf6/McLvSWW yx8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id a193-20020a6390ca000000b00553ebb05d14si3357657pge.111.2023.08.19.08.07.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Aug 2023 08:07:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B1085DBA9A; Sat, 19 Aug 2023 01:46:04 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378097AbjHRPUm (ORCPT + 99 others); Fri, 18 Aug 2023 11:20:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378133AbjHRPU1 (ORCPT ); Fri, 18 Aug 2023 11:20:27 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id EC1F83C31 for ; Fri, 18 Aug 2023 08:20:23 -0700 (PDT) Received: (qmail 32953 invoked by uid 1000); 18 Aug 2023 11:20:22 -0400 Date: Fri, 18 Aug 2023 11:20:22 -0400 From: Alan Stern To: Kai-Heng Feng Cc: mathias.nyman@intel.com, Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xhci: Disable connect, disconnect and over-current wakeup on system suspend Message-ID: <812a6f54-ef51-4759-8b45-09eb52acad2f@rowland.harvard.edu> References: <20230817093305.212821-1-kai.heng.feng@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_PASS, SPF_PASS 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 Fri, Aug 18, 2023 at 10:19:27PM +0800, Kai-Heng Feng wrote: > On Fri, Aug 18, 2023 at 11:19 AM Alan Stern wrote: > > > > On Fri, Aug 18, 2023 at 08:00:39AM +0800, Kai-Heng Feng wrote: > > > On Thu, Aug 17, 2023 at 10:07 PM Alan Stern wrote: > > > > > > > > On Thu, Aug 17, 2023 at 05:33:05PM +0800, Kai-Heng Feng wrote: > > > > > The system is designed to let display and touchpanel share the same > > > > > power source, so when the display becomes off, the USB touchpanel also > > > > > lost its power and disconnect itself from USB bus. That doesn't play > > > > > well when most Desktop Environment lock and turnoff the display right > > > > > before entering system suspend. > > > > > > > > I don't see why that should cause any trouble. The display gets locked > > > > and turned off, the touchpanel disconnects from the USB bus, and then > > > > the system goes into suspend. Why would there be a wakeup signal at > > > > this point? > > > > > > The disconnecting can happens during the system suspend process, so > > > the suspend process is aborted. > > > > Maybe these systems need to add a little delay when the display is > > turned off, in order to give the touchpanel time to disconnect before > > the system suspend begins. > > Unfortunately the hardware can't be changed. No, but the software can. Change the kernel routine that controls the display's power, so that when it's turning the power off it delays a little before returning. > > > > > So for system-wide suspend, also disable connect, disconnect and > > > > > over-current wakeup to prevent spurious wakeup. > > > > > > > > Whether to disable these things is part of the userspace policy. The > > > > kernel should not make the decision; the user does by enabling or > > > > disabling wakeups. > > > > > > The power/wakeup is already disabled. > > > > In that case the root hub should not generate a wakeup request in > > response to the touchpanel disconnecting. > > Here's the wakeup setting when the issue happens: > controller - wakeup enabled > root hub: wakeup disabled > touchpanel: wakeup disabled Your patch turns off the PORT_WAKE_BITS in xhci_disable_hub_port_wake(), right? (Incidentally, the patch changes the code but doesn't change the immediately preceding comment, which will cause the comment to be wrong.) But if the root hub was suspended with wakeup disabled then those bits should already be off. So I don't see why your patch causes any change in behavior. > > > The disconnecting event is from roothub and if roothub wakeup is > > > disabled, other USB devices lose the ability to wake the system up > > > from system suspend. > > > > That shouldn't happen either. Disabling wakeup on the root hub should > > not prevent the root hub from relaying wakeup requests it receives from > > downstream devices. It should merely prevent the root hub from > > generating its own wakeup requests for connects, disconnects, and > > over-current events. > > Sorry, it was meant to be the xHCI controller. The didn't make the > difference clear. > > > > > It sounds like the xhci root-hub code isn't doing the right thing, at > > least, not on your systems. > > I still don't fully understand why removing PORT_WAKE_BITS is not > right in this case. The decision about whether to turn those bits on or off should depend on the wakeup settings. They should be on if wakeup is enabled and off if wakeup is disabled. Your patch doesn't work that way; it turns the bits off even when wakeup is enabled. Alan Stern