On 1/22/21 10:22 AM, Alan Stern wrote:
On Thu, Jan 21, 2021 at 07:06:27PM -0600, Jeremy Figgins wrote:
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.
The simplest solution in all cases is just to avoid calling either
usb_set_interface or usb_clear_halt. Especially since in cases where
the interface has only one altsetting, neither call should be necessary.
Alan Stern
I can confirm that only calling usb_clear_halt() if
USB_QUIRK_NO_SET_INTF is not set (and setting it for my device) does
allow my device to work. What is the next step? Should I submit a v2 patch?
-- Jeremy
