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:	Sat, 12 Jan 2008 02:23:27 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	Pavel Machek <pavel@...e.cz>, "Rafael J. Wysocki" <rjw@...k.pl>
CC:	Ondrej Zary <linux@...nbow-software.org>,
	Pierre Ossman <drzeus@...eus.cx>,
	Jaroslav Kysela <perex@...ex.cz>,
	ALSA development <alsa-devel@...a-project.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Andrew Morton <akpm@...l.org>, Takashi Iwai <tiwai@...e.de>,
	linux-pm@...ts.linux-foundation.org
Subject: Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with
 snd_cs4236

On 11-01-08 19:40, Ondrej Zary wrote:

> On Friday 11 January 2008 15:21:55 Rene Herman wrote:

>> Hrmpf. Well, okay. Ondrej -- I assume this patch fixes things?
> 
> Yes, it works fine. 3c509 card still does not work after resume, but that
> looks like another problem.

Okay. Would now only still like to know why the test in resume() means 
trouble for you while it seems the same test in suspend() should've 
triggered as well and not have stopped the device in the first place.

Know absolutely nothing about hibernation so added the listed maintainers to 
the CC.

Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for 
Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test 
triggering in pnp_bus_resume() and keeping the card in a suspended state.

There's issues on wether or not the flag _should_ be set (that is, be part 
of PNP_DRIVER_RES_DISABLE) and that it shouldn't be tested by these code 
patchs in the first place, but is it in fact expected that this would be 
neccessary?

That is, is it expected/designed that the same test in pnp_bus_suspend() 
didn't cause the device to not be disabled in the first place?

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