[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yl72GjATzVoJpSlA@rowland.harvard.edu>
Date: Tue, 19 Apr 2022 13:49:14 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: Evan Green <evgreen@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Mathias Nyman <mathias.nyman@...el.com>,
Rajat Jain <rajatja@...omium.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Razvan Heghedus <heghedus.razvan@...il.com>,
Wei Ming Chen <jj251510319013@...il.com>,
Youngjin Jang <yj84.jang@...sung.com>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 0/2] USB: Quiesce interrupts across pm freeze
On Tue, Apr 19, 2022 at 05:51:38PM +0200, Oliver Neukum wrote:
>
>
> On 19.04.22 16:35, Alan Stern wrote:
> > On Tue, Apr 19, 2022 at 09:05:53AM +0200, Oliver Neukum wrote:
> >
> >
> > We have a set of quirky devices that need HID_QUIRK_ALWAYS_POLL.
> > They have the nasty firmware bug that, if you suspend them without
> > remote wakeup, they will crash or reset themselves.
> > I am afraid that has an obvious relevance to your cool patches.
> > I am not completely sure how to deal with this. It seems to me that the
> > quirk will need to be shifted from HID to core USB and thaw() needs to
> > be translated into usb_device_reset() + reset_resume() for them,
> > but I am not really sure about the optimal mechanism.
> > We may not need to do anything. This patch specifically addresses
> > hibernation, not system suspend or runtime suspend. A device crashing
> > or resetting during hibernation is not at all unusual; we should be able
> > to handle such cases properly.
> >
> > The THAW part of suspend-to-hibernation is used only for writing the
> > memory image to permanent storage. I doubt that a malfunctioning HID
> > device would interfere with this process.
> >
> True, if and only if all goes well. At the time thaw() has run writing
> the image to disk can still fail. In that case the devices will still
> be needed.
Consider adding a mechanism to usbcore which would allow an interface
driver to request that the next time its device is resumed, the core
should perform a reset-resume. Would that help?
Alan Stern
Powered by blists - more mailing lists