Re: sl811h_suspend() and PM_EVENT_PRETHAW state handling

[Alan Stern]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/