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]
Message-ID: <Pine.LNX.4.44L0.1308061433000.1154-100000@iolanthe.rowland.org>
Date:	Tue, 6 Aug 2013 14:38:45 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Shuah Khan <shuah.kh@...sung.com>
cc:	"rjw@...k.pl" <rjw@...k.pl>, "pavel@....cz" <pavel@....cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: sl811h_suspend() and PM_EVENT_PRETHAW state handling

On Tue, 6 Aug 2013, Shuah Khan wrote:

> sl811h_suspend() seems to be the odd routine in the way it handles the 
> PM_EVENT_PRETHAW state. It treats it same as PM_EVENT_SUSPEND and 
> PM_EVENT_HIBERNATE. All other uses I could find treat it same as 
> PM_EVENT_FREEZE and PM_EVENT_QUIESCE. Makes sense since PM_EVENT_PRETHAW 
> is PM_EVENT_QUIESCE.
> 
> #define PM_EVENT_PRETHAW PM_EVENT_QUIESCE
> 
> Reference: Commit 185849991d592497e43bcd264c6152af1261ffe2 introduced 
> PM_EVENT_PRETHAW state to sl811h_suspend().
> 
> Couple of questions?
> 
> - Why does sl811h_suspend() treat PM_EVENT_PRETHAW different from 
> PM_EVENT_FREEZE?

Because with FREEZE, the driver wants to retain the current bus state.  
With PRETHAW, it doesn't care about retaining the bus state.

At least, that's how it looks to me.  The original author of this 
driver died a couple of years ago.  I don't know if anyone is using it 
any more.

> There is no problem with this code as such, since state is passed in. 
> However, this usage conflicts with the rest of the usages and the way 
> pm_op() routine maps PM_EVENT_PRETHAW/PM_EVENT_QUIESCE to freeze() pm_ops.
> 
>          case PM_EVENT_FREEZE:
>          case PM_EVENT_QUIESCE:
>                  return ops->freeze;
> 
> Assuming the handling PM_EVENT_PRETHAW is correct in this routine, what 
> would be the right mapping for this legacy handling to dev_pm_ops?

It depends on the driver; there is no one answer.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ