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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 12 Jan 2008 21:08:01 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	Andrew Morton <akpm@...l.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Pierre Ossman <drzeus@...eus.cx>, Pavel Machek <pavel@...e.cz>,
	Ondrej Zary <linux@...nbow-software.org>,
	Jaroslav Kysela <perex@...ex.cz>,
	ALSA development <alsa-devel@...a-project.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Takashi Iwai <tiwai@...e.de>,
	linux-pm@...ts.linux-foundation.org
Subject: -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks
 resuming isapnp cards

Hi Andrew.

pnp-do-not-stop-start-devices-in-suspend-resume-path.patch in current -mm 
breaks resuming isapnp cards from hibernation. They need the pnp_start_dev 
to enable the device again after hibernation.

They don't really need the pnp_stop_dev() which the above mentioned patch 
also removes but with the pnp_start_dev() restored it seems pnp_stop_dev() 
should also stay. Bjorn Helgaas should decide  -- currently the patch as you 
have it breaks drivers though. Could you drop it?

Then, if so and after you do that, could you apply the attached? That's also 
needed to resume (ALSA) ISA-PnP cards from hibernation due to the 
RES_DO_NOT_CHANGE test triggering for ALSA drivers and the pnp_start_dev() 
still not happening. More in the changelog...

On 12-01-08 20:08, Rafael J. Wysocki wrote:

> On Saturday, 12 of January 2008, Rene Herman wrote:

>> It seems all PnP drivers would need to stick a pnp_start_dev in their resume 
>> method
> 
> Yes.
> 
>> then which means it really belongs in core.
> 
> Yes, if practical.
> 
>> One important point where PnP and PCI differ is that PnP allows to change the
>> resources on a protocol level and I don't see how it could ever not be
>> necessary to restore the state a user may have set if power has been
>> removed. Hibernate is just that, isn't it?
> 
> Basically, yes, it is.

Rene.


View attachment "pnp_driver_res_do_not_test.diff" of type "text/plain" (2276 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ