RE: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of staging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
> Sent: Wednesday, October 26, 2011 8:09 PM
> To: KY Srinivasan
> Cc: gregkh@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; linux-
> input@xxxxxxxxxxxxxxx; Haiyang Zhang; Jiri Kosina
> 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.

Looking at the code for complete(), it looks like the "done" state is incremented
each time complete() is invoked and  the  code for do_wait_for_common() decrements the 
done state each time it is invoked (if the completion is properly signaled and we are not dealing
with a timeout. So, what am I missing here.

> 
> >
> > >
> > > > +	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?

This is called from the probe functions and these errors are percolated up. On a different
note, I cleaned up this code based on the feedback I got from you. The patches have been 
sent out.

Regards,

K. Y

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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux