Re: Unable to Use Isochronous Behavior w/ Isoc Endpoint in FunctionFC

["Sid Spry" <sid@aeam.us>]

On Mon, Jun 22, 2020, at 11:41 AM, Alan Stern wrote:
> On Mon, Jun 22, 2020 at 10:41:14AM -0500, Sid Spry wrote:
> > On Mon, Jun 22, 2020, at 9:02 AM, Alan Stern wrote:
> > > On Sun, Jun 21, 2020 at 09:25:53PM -0500, Sid Spry wrote:
> > > > I now must ask the list: What is the relation of the isochronous endpoint setup
> > > > to the allocated bandwidth on the bus?
> > > 
> > > Bandwidth allocation is determined by the host controller driver, or in 
> > > the case of xHCI, hardware.  Therefore it will vary with different drivers 
> > > or controllers.
> > > 
> > 
> > Ok, variation I expected. Sadly it seems like I am not made aware of which
> > interface alternate setting is chosen.
> > 
> > See: https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/
> > function/f_fs.c#L3265.
> > 
> > The ctrlrequest struct (https://elixir.bootlin.com/linux/latest/source/include
> > /uapi/linux/usb/ch9.h#L213) is only sent for SETUP events. Of which I have
> > yet to triggered.
> 
> Like I said before, you'll need to ask someone who knows more about 
> FunctionFS.
> 

This is a mailing list, I am not only expecting you to reply.

> > > > libusb seems to encounter an error:
> > > > 
> > > > (pyusb error output)
> > > > ```
> > > > >>> import usb
> > > > >>> ds = [d for d in usb.core.find(find_all=True, idVendor=0x1d6b, idProduct=0x0104)]
> > > > >>> d = ds[0]
> > > > >>> d.set_interface_altsetting(interface=1, alternate_setting=1)
> > > > Traceback (most recent call last):
> > > >   File "<stdin>", line 1, in <module>
> > > >   File "/usr/lib/python3.7/site-packages/usb/core.py", line 902, in set_interface_altsetting
> > > >     self._ctx.managed_set_interface(self, interface, alternate_setting)
> > > >   File "/usr/lib/python3.7/site-packages/usb/core.py", line 102, in wrapper
> > > >     return f(self, *args, **kwargs)
> > > >   File "/usr/lib/python3.7/site-packages/usb/core.py", line 204, in managed_set_interface
> > > >     self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt)
> > > >   File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 807, in set_interface_altsetting
> > > >     altsetting))
> > > >   File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 595, in _check
> > > >     raise USBError(_strerror(ret), ret, _libusb_errno[ret])
> > > > usb.core.USBError: [Errno None] Other error
> > > > ```
> > > > 
> > > > (libusb error from C code)
> > > > ```
> > > > libusb: error [op_set_interface] setintf failed error -1 errno 32
> > > > ```
> > > 
> > > Error 32 means that the device returned a STALL status when it received 
> > > the Set-Interface request.  The code responsible for this error response 
> > > might be in FunctionFS or in your driver.
> > >
> > 
> > I see the set-interface request in my code as a read/write error on the endpoints
> > (errno 11: resource temporarily unavailable) and an enable event. Otherwise
> > most things "just happen."
> > 
> > I've had issues reusing endpoint numbers like you are supposed to. Either the
> > descriptors aren't accepted or more commonly the UDC won't bind. E.g. I have
> > to give interface 0 eps 1, 2 and interface 1 eps 3, 4. The numbering is preserved
> > on the host, kind of. Eps are compacted into their numbering based on direction.
> > So you see interface 0 with eps 0x81 and 0x01, and interface 1 with eps 0x82 
> > and 0x02.
> 
> That's exactly how it's supposed to work.  Don't mix up endpoint _numbers_ 
> with endpoint _addresses_; they aren't the same thing.  Read through the 
> USB-2.0 specification for more information.
> 
> Also don't forget that two interfaces in the same configuration are not 
> allowed to share an endpoint (other than endpoint 0, which doesn't really 
> belong to any interface).
> 
> > This isn't causing me problems per se but does seem improper.
> 
> Why?
> 

Ah, yes, I was mixing up numbers/addresses. Strange as the only useful
number to me seems to be the address.

> > I'll look through the functionfs code when I have some time. The user mode
> > does not seem to be passed much information.
> 
> If you think this is a weakness of FunctionFS and it needs to be fixed, 
> report it to the FunctionFS maintainers.  See the MAINTAINERS file in the 
> top-level directory of the kernel source code.
> 
> > > > But, if interface 1 alternate setting 0 is dropped, and interface 1 alternate
> > > > setting 1 is kept, both invocations work and my C code spits out data very
> > > > fast, although I must inspect it further as I seem to be duplicating data in my
> > > > reads.
> > > 
> > > If you drop altsetting 0 then you're probably not issuing a Set-Interface 
> > > request.  That would explain why you don't get a failure.
> > > 
> > > If you like, you can try issuing a Set-Interface(0) request (even though 
> > > it's redundant) just to see if it fails.
> > > 
> > 
> > Ah, yes, I had done set-interface(0 [, 0]). set-interface(1, 0) also works. It is just
> > set-interface(1, 1) that is nonfunctional when an alternate mode 0 is provided.
> 
> Okay.  Maybe the problem occurs in the code that enables the endpoints for 
> altsetting 1.
> 

I do appreciate the help, I'll report to the maintainers later. I'll have to table it for
now. As it is I'm able to send reliably on each frame so I'm happy.