netdev - Re: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Mar 2013 21:08:09 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	Bjørn Mork <bjorn@...k.no>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Alan Stern <stern@...land.harvard.edu>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep

On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum <oneukum@...e.de> wrote:
>>
>> IMO, for autosuspend, that is right, but it is not for system suspend,
>> and the driver's suspend callback can't return in resumed state
>> because the USB core will ignore the failure return value and force
>> to suspend the device.
>
> It seems to me that in this case you just need to make sure that
> suspend() not fail for system suspend. Or revisit the decision to
> ignore failures.

IMO, the current policy is correct.

> In other words, if we don't handle errors, there must be no errors,
> otherwise it doesn't matter what we do in the error case. We'd leave
> the problem to generic layers.

Generic layers can't handle the driver's specific failure.

If driver records its suspend failure state in suspend(), resume()
should and can deal with it without much difficulty.

>
> Furthermore there is a small chance that although the device tree
> is walked, teh system suspend fails for another later reason that
> is not ignored. In that case the drivers need to do error recovery,
> albeit in resume().

Yes,  resume() need to handle the USB system suspend failure
either in normal resume or error recovery, both are basically same.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html