On 1/21/21 5:02 PM, Pete Zaitcev wrote:
On Thu, 21 Jan 2021 14:29:29 -0500
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
I'm also concerned about regressions. This is a legacy class driver,
only used where CUPS is not applicable, mostly with truly ancient
devices. So yes, setting a zero altsetting after enumeration should
be unnecessary. But you never know with the old firmware.
How about skipping the call whenever the interface has only one
altsetting?
Do you mean when it's only one and not equal to zero?
BTW, one other thing bothers me. Jeremy confirmed that my patch
worked, which skips the call when USB_QUIRK_NO_SET_INTF is set.
But if we look into drivers/usb/core/message.c, the control
exchange to set the altsetting is skipped in that case anyway.
So, usblp was calling usb_set_protocol, the suspect control was
skipped, but something else caused a problem. Could it be the
attempt to clear halt that triggered the problem?
-- Pete
In my debugging, I found that it was the calls to usb_control_msg_send()
in both usb_set_interface() and usb_clear_halt() caused the printer to
lockup. I suppose another way to resolve this would to have a flag to
prevent usb_clear_halt()'s call to usb_control_msg_send(), but I'm not
an expert in USB, so I'm not sure of the ramifications of that.
-- Jeremy
