hello. Although I've been silent on this issue for a while, I've
continued to make progress in getting the ugen(4) driver into a state where
it works well with the libimobiledevice tools and can reliably be used with
Apple products. The problem I've run into now is the one that's been
troubling me for a while, but which I now have a much better handle on.
Specifically, it seems to be impossible to ask the ehci(4) or ohci(4)
drivers to generate zero-length packets. The uhci(4) driver works
beautifully. To clarify, both the ehci(4) and ohci(4) drivers seem to have
fixes which allow them to generate zero-length packets in the case where a
write request is equal to the exact size of an USB packet. In that case,
they generate the required zero-length packet following the initial write
request. The problem is that if an upper layer usb driver wants to
generate a zero-length packet as its first write request, as the ugen(4)
driver would in response to a call from a user-level process, the ehci(4)
driver, and I believe the ohci(4) driver, will fail. the issue appears to
be how these drivers allocate memory forpassing the data to the chips
themselves. The allocator for these two drivers appears to assume that the
length parameter for all requests will be greater than 0, so they calculate
the amount of memory required for a given request by performing a number of
arithmetic operations against the length parameter to get the required
number of buffers to service the request. The issue is that if the length
parameter is 0, those operations result in a negative number, or a very
large number in this case, since the allocator assumes the parameter is an
unsigned integer. As a result, the ehci(4) and ohci(4) drivers fail when
asked to send zero-length packets with a USBD_NOMEM error.
I believe the problem lies around line 2931 of sys/dev/usb/ehci.c, V1.238.
For completenesS I should say that I've not tested the ohci() driver
directly, but code inspection leads me to believe it has the same issue as
the ehci(4) driver, which I have tested.
I am having trouble making sense of the ehci(4) allocation code and my
attempts to come up with a patch to work around the issue have been
unsuccessful so far. Perhaps someone can look at this section of the
ehci.c code and provide a little guidance on what's going on. I'll
continue to poke at it as well, but another set of eyes looking at the
issue would be much appreciated.