Re: [PATCH] linux-input: bcm5974-0.57: mode-switch to atp_open,cleanup bug fixed

[Dmitry Torokhov]

On Tue, Jul 22, 2008 at 02:55:42AM +0200, Henrik Rydberg wrote:
> Hi Dmitri,
> 
> Regarding open/close and suspend/resume, I have difficulties finding out
> what the proper behavior is for the various error states that can
> appear. I also wonder whether open should commute with suspend or not.
> It would be of great help to get answers to the scenarios below.
>

Hm, hard questions. I will try answering them but I am also CCing Alan
Stern and Oliver Neikum who are experts in USB suspend/resume.
 
> 1. From the state (!opened,!suspended), calling open followed by
> suspend, or suspend followed by open, are we in the same state?
>

No, we are not... if we first open then suspend then device stays open
but we are not getting reports from it. Opening suspended device will
fail. Autosuspended device should be waken up by open() though.
 
> 2. From the state (!opened,!suspended), calling open fails. What state
> are we in?

Device is closed, the driver will have to make sure that it cleans up
steps that succeded while opening device (like if you submitted 1 URB
successfully and the 2nd URB failed open should kill the first one
before returning).

> 
> 3. From the state (!opened,suspended), calling open gets us to what
> state?
>

Depens on the kind of suspend - manual suspend will cause open to
fail. Autosuspend (if driver implements it) should resume the device.

> 4. From the state (!opened,suspended), calling open fails. Where are we?
>

Manual suspend will surely cause open to fail. Autosuspend - if
autoresume fails then (closed, unknown) otherwise (closed,
autosuspended - autosuspension may not kick in immediately I think).

> 5. From the state (opened,suspended), calling resume fails. What state
> are we in?
> 

Screwed up ;) From the driver POV still (opened, suspended) I think.

Thanks!

-- 
Dmitry
--
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/