Re: asynchronous ugen(4) bulk transfers

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I did a lot of work on this under NetBSD-5  to allow the
libimobiledevice tools to work with iOS based Apple devices.  I have some
simple patches for libusb1 and a re-working of the ugen(4) driver to
address the issues you note below.  My plan is to port these fixes to
-current, but I hadn't finished that process yet.  My changes make the
libimobiledevice tools work reliably with Apple products, modulo a bug in
the ehci(4) and ohci(4) drivers that preclude the USB stack from sending
zero-length packets.  
	I discussed these fixes on tech-kern with the subject:

Potential problem with reading data from usb devices with ugen(4)


	The two major fixes I implemented were:

1.  Make poll(2) work with ugen(4) so  you know when data is ready to be
read from or written to a device asynchronously.

2.  Ensure that each read or write call to a ugen(4) device results in a
matching USB transaction to or from the device.

	If you'd like my patches to port to -current, let me know.
-thanks
-Brian

On Feb 3, 10:00pm, Brian Buhrow wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} 	hello.  I think the problem is related to the calculation on line
} 2914.  Unless I'm mistaken, that subtraction will yield a very large number
} because the result should be negative, but can't be, because we're talking
} about an unsigned integer.  When that happens, the allocator barfs since
} the result is way way larger than 5 pages.  Admittedly, I'm having trouble
} understanding all of the macros used in this section of code, but that
} seems like what I'm seeing when I try to send a zero-length packet through.
} 
} What am I missing?
} 
} -thanks
} -Brian
} 
} On Feb 2,  8:02am, Nick Hudson wrote:
} } Subject: Re: Potential problem with reading data from usb devices with uge
} } On 01/27/16 22:19, Brian Buhrow wrote:
} } > 	hello.  A patch would be great!  I realize I may have to back port it
} } > to NetBSD-5, but I'm ok with that .
} } > 	I do plan to make these changes to ugen(4) part of -current, but I
} } > wanted to be confident that my fixes work reliably in my known working
} } > environment before I move them to -current.  I'm getting closer.
} } 
} } 
} } OK, I'm a little confused why ehci(4) fails, but
} } 
} } In ehci
} } 
} }      http://nxr.netbsd.org/xref/src/sys/dev/usb/ehci.c#2910
} } 
} } With len = 0 we should go through the loop once and have 1 qtd of zero 
} } length
} } 
} }      len = 0,  curoffs = 0  gives curlen = 0
} } 
} } This conditional
} } 
} }      http://nxr.netbsd.org/xref/src/sys/dev/usb/ehci.c#2939
} } 
} } is false as curlen == 0 then next = NULL and the loop terminats.
} } 
} } 
} } As for ohci
} } 
} }      http://nxr.netbsd.org/xref/src/sys/dev/usb/ohci.c#475
} } 
} } dataphysend is all wrong, etc...
} } 
} } Nick
} } 
} } > -thanks
} } > -Brian
} } >
} } > On Jan 27,  9:46pm, Nick Hudson wrote:
} } > } I see the bug(s) and will try and cook up diffs soon. They'll be against
} } > } -current, though
} } > }
} } > }
} } >
} } 
} >-- End of excerpt from Nick Hudson
} 
} 
>-- End of excerpt from Brian Buhrow