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;
Date:   Thu, 17 Aug 2023 23:19:08 -0400
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc:     mathias.nyman@intel.com,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        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: <dc4f5de7-43f1-4dc2-9a2f-39846b4b7cc3@rowland.harvard.edu>
References: <20230817093305.212821-1-kai.heng.feng@canonical.com>
 <cab8a29b-816c-41c7-8d2a-418f787e406e@rowland.harvard.edu>
 <CAAd53p7HZk5tTvT=dhSk01KSW4W3vCi+hY8aFYRoFzxs8YiiYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAd53p7HZk5tTvT=dhSk01KSW4W3vCi+hY8aFYRoFzxs8YiiYA@mail.gmail.com>
Precedence: bulk

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 <stern@rowland.harvard.edu> 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.

> > > 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.

> 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.

It sounds like the xhci root-hub code isn't doing the right thing, at 
least, not on your systems.

Alan Stern