Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
From: "Andrew P. Lentvorski" <bsder@allcaps.org>
To: Felipe Balbi <balbi@kernel.org>, Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Subject: Re: Unable to set "iInterface" in usb gadget via configfs
Date: Fri, 17 Jan 2020 16:58:38 -0800
Message-ID: <76a34192-6b09-357c-f1e0-2228a9ebab76@allcaps.org> (raw)
In-Reply-To: <878sm65tak.fsf@kernel.org>

On 1/17/20 1:25 AM, Felipe Balbi wrote:

> why? No behavior changed. Look at the very first commit on
> f_hid.c. commit 71adf118946957839a13aa4d1094183e05c6c094 contains the
> following:

Oops.  I missed that.  Sorry for not being complete enough.  My fault.

> Now, if there's a real usecase for this. Something that can attract, as
> per Dave B., 3 or more users, then we can consider adding it
> upstream. Remember that if we add support for changing interface
> strings, it has to be implemented for *all* functions and validated on
> all functions, then properly documented as a configfs ABI which can
> never change anymore.

Erg.  I did not realize that this was not going to be limited to just
f_hid.c.

That's ... ugly.  Reeeally ugly.  And a *LOT* of work.

I can certainly see that "some devices do this" is nowhere close to
enough justification for that.

>> control board the ability to now also be accessed via ethernet or
>> wireless (or even a better USB protocol) and thus now has an upgrade or
>> higher performance path is a *really* useful thing.  And the Beaglebone
>> Black is a really good "protocol engine".  Finally, after making the usb
>> gadget emulation work, I can probably blow a bunch of Windows machines
>> away completely since something like a Beaglebone Black is more than
>> sufficient to handle the control without any outside intervention.
> 
> You're getting to a point where things start to get interesting. What
> exactly are you trying to do?

I've got both a GPIB (with USB 1.0(!) only--as far as I can tell--talk
about a relic) and an industrial controller (unknown protocol but USB
tracing and a signal analyzer shows pretty much 1-1 so reverse
engineering it doesn't seem problematic) currently sitting on my desk.
I have one system which has enough USB devices in it that it won't work
on a USB 3 system because the Intel USB 3 chipset allocates twice as
many endpoints per device and hits an internal limit--they want a USB
upgrade as an intermediate move to ethernet.

I have a half-dozen other similar type requests queued behind these.
People are finally reaching a critical point where they can't keep
ancient hardware, ancient drivers, ancient Windows, and ancient
computers all running anymore--even VM's are starting to fail as too
many things have some level of timing baked into the driver (normally
unintentionally).

>> Anyhow, let me know whether I should attack the problem or not.

At this point, I suspect that the correct answer is "Keep an eye on this
while moving forward."

If I stumble over more drivers that are trying to use iInterface for
some reason, I will see if setting it to 0x00 makes things choose a
different path.  Simply changing the default to effectively 0x00-unused
seems like a lot less work and might pick up 90% of the use cases.  It
also means the scope would be limited to f_hid.c.  If I hit this a
couple times, I'll have a lot more justification behind me.

If I start seeing cases where I actually need to specify the iInterface
stuff, I'll come back with data and we can revisit this again.  I
suspect that someone is eventually going to drop a CDC class device in
front of me, and that will give me more data, too.  If ever I reach the
 point where I have multiple devices working around this, hopefully you
will find my arguments far more persuasive.  :)

> you could use dummy_hcd as well.

Interesting.  I did not know about this, but I will keep it in mind.


Thanks for being so patient.  Sorry for wasting your time only to come
back to "do nothing".

-a

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 23:58 Andrew P. Lentvorski
2020-01-15 15:14 ` Alan Stern
2020-01-16  2:23   ` Andrew P. Lentvorski
2020-01-16 13:02     ` Felipe Balbi
2020-01-17  0:39       ` Andrew P. Lentvorski
2020-01-17  9:25         ` Felipe Balbi
2020-01-18  0:58           ` Andrew P. Lentvorski [this message]
2020-01-19 16:45             ` Felipe Balbi

Reply instructions:

You may reply publically 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=76a34192-6b09-357c-f1e0-2228a9ebab76@allcaps.org \
    --to=bsder@allcaps.org \
    --cc=balbi@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org
	public-inbox-index linux-usb

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git