> It's always a bug. However, the patch I sent to Matthew should fix the
> immediate problem.
>
> In fact, the original autosuspend design intended to allow drivers to
> do this -- keep devices awake by failing suspend requests even though
> the usage count is 0. Under some conditions, that's the approach with
> the least overhead. But the code to handle this got lost by mistake,
> so now it needs to be added back.
I tried the patch out, unfortunately it did not work. The second
suspend request returns with a -EINPROGRESS, here:
if (dev->power.runtime_status == RPM_SUSPENDING) {
DEFINE_WAIT(wait);
if (rpmflags & (RPM_ASYNC | RPM_NOWAIT)) {
retval = -EINPROGRESS;
goto out;
}
/* Wait for the other suspend running in parallel with us. */
for (;;) {
The reason is above my horizon, although RPM_ASYNC looks suspicious.
In general, we are re-entering rpm_suspend from within the driver
handler, so the exit condition of rpm_suspend may not have been
satisfied yet.
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
