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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
