[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111027000926.GB6804@core.coreip.homeip.net>
Date: Wed, 26 Oct 2011 17:09:27 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: KY Srinivasan <kys@...rosoft.com>
Cc: "gregkh@...e.de" <gregkh@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of
staging
On Sun, Oct 23, 2011 at 03:45:14PM +0000, KY Srinivasan wrote:
> > > +
> > > + t = wait_for_completion_timeout(&input_dev->wait_event, 5*HZ);
> > > + if (t == 0) {
> > > + ret = -ETIMEDOUT;
> > > + goto cleanup;
> > > + }
> > > +
> > > + response = &input_dev->protocol_resp;
> > > +
> > > + if (!response->response.approved) {
> > > + pr_err("synthhid protocol request failed (version %d)",
> > > + SYNTHHID_INPUT_VERSION);
> > > + ret = -ENODEV;
> > > + goto cleanup;
> > > + }
> > > +
> > > + t = wait_for_completion_timeout(&input_dev->wait_event, 5*HZ);
> >
> > We just completed the wait for this completion, why are we waiting on
> > the same completion again?
>
> In response to our initial query, we expect the host to respond back with two
> distinct pieces of information; we wait for both these responses.
I think you misunderstand how completion works in Linux. IIRC about
Windows events they are different ;) You can not signal completion
several times and then expect to wait corrsponding number of times. Once
you signal completion is it, well, complete.
>
> >
> > > + if (t == 0) {
> > > + ret = -ETIMEDOUT;
> > > + goto cleanup;
> > > + }
> > > +
> > > + /*
> > > + * We should have gotten the device attr, hid desc and report
> > > + * desc at this point
> > > + */
> > > + if (input_dev->dev_info_status)
> > > + ret = -ENOMEM;
> >
> > -ENOMEM seems wrong.
> >
> There are many failures here and not being able to allocate memory is the
> primary one; and so I chose to capture that.
Any chance that these failures have their own exit paths?
Thanks.
--
Dmitry
--
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