Re: [PATCH 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in

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

 



On Fri, 2014-08-22 at 14:23 -0400, Alan Stern wrote:
> On Sat, 23 Aug 2014, vichy wrote:
> 
> > from your patch, I have some questions:
> > a. in Alan's version, if both HID_CLEAR_HALT and HID_RESET_PENDING are
> > set, hid_reset will both "clear ep halt" and "reset devcie".
> > But in original one, even HID_CLEAR_HALT and HID_RESET_PENDING are
> > both set, hid_reset only do one of them.
> 
> Yes.  In my patch, the clear-halt handler will turn on the
> HID_RESET_PENDING bit if something goes wrong.  In that case we want to
> do both things.

Why? If we reset, why bother clearing a halt? Especially as this
may mean waiting the full 5 seconds for a timeout.

> > is there any special reason in original hid_reset to use below flow?
> >     if (test_bit(HID_CLEAR_HALT, &usbhid->iofl)) {
> >             xxxxx
> >     } else if (test_bit(HID_RESET_PENDING, &usbhid->iofl)) {
> >             xxxxxx
> >     }
> 
> No special reason.  We probably never thought that both flags would be
> set.

Yes. And I'd say if this ever happens HID_RESET_PENDING must have
priority and implicitly clears a halt.

	Regards
		Oliver



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