From: Alan Stern <stern@rowland.harvard.edu>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Jeremy Figgins <kernel@jeremyfiggins.com>,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH] USB: usblp: add USBLP_QUIRK_NO_SET_INTF flag
Date: Thu, 21 Jan 2021 14:29:29 -0500 [thread overview]
Message-ID: <20210121192929.GA12502@rowland.harvard.edu> (raw)
In-Reply-To: <20210121131954.7103881d@suzdal.zaitcev.lan>
On Thu, Jan 21, 2021 at 01:19:54PM -0600, Pete Zaitcev wrote:
> On Mon, 18 Jan 2021 11:31:17 -0500
> Alan Stern <stern@rowland.harvard.edu> wrote:
> > Would it be practical simply to skip the usb_set_interface() call
> > whenever alts is 0? After all, devices use altsetting 0 by default; it
> > shouldn't be necessary to tell them to do so.
>
> Is it possible to bind and unbind the driver without enumeration, and
> thus inherit a non-zero altsetting?
In theory, yes. But the only way it could happen is if either the
driver itself or a userspace program installed the nonzero
altsetting.
> 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.
True, although I seriously doubt anyone would have written firmware that
required a Set-Interface request for initialization. Particularly if
the interface has only one altsetting.
How about skipping the call whenever the interface has only one
altsetting?
Alan Stern
next prev parent reply other threads:[~2021-01-21 19:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-17 21:36 [PATCH] USB: usblp: add USBLP_QUIRK_NO_SET_INTF flag Jeremy Figgins
2021-01-18 5:44 ` Pete Zaitcev
2021-01-18 16:31 ` Alan Stern
2021-01-18 16:43 ` Michael Sweet
2021-01-19 0:01 ` Jeremy Figgins
2021-01-21 19:21 ` Pete Zaitcev
2021-01-21 19:19 ` Pete Zaitcev
2021-01-21 19:29 ` Alan Stern [this message]
2021-01-21 23:02 ` Pete Zaitcev
2021-01-22 1:06 ` Jeremy Figgins
2021-01-22 16:22 ` Alan Stern
2021-01-23 18:46 ` Jeremy Figgins
2021-01-23 21:33 ` Alan Stern
2021-01-22 16:20 ` Alan Stern
2021-01-18 9:02 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210121192929.GA12502@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@jeremyfiggins.com \
--cc=linux-usb@vger.kernel.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox