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

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

	hello.  When I say sending zero-length transfers behave badly, I mean
diferent things happen depending on whether I'm using ehci(4), uhci(4) and
whether options DIAGNOSTIC is defined.

	If I'm using ehci(4) and option DIAGNOSTIC is defined, I get a panic:
"curlen == 0".
If option DIAGNOSTIC is not defined, then I'm simply unable to write to any
USB devices attached to that bus without a reboot.

	With uhci(4), things go better. that is, I can still write to the bus
and devices on the bus after I issue the ZLP write request, but I don't
think the ZLP request is making it all the way to the device itself.  At
least the device says it isn't getting said transactions.  

	I'm using ehci.c as follows:
/*	$NetBSD: ehci.c,v 1.154.4.3 2011/05/20 19:31:46 bouyer Exp $ */

	It's possible I'm not sending a ZLP request the right way.  Here's how
I'm trying to generate such traffic from the ugen(4) code:

[ . . . ]

					dbuf = (char *)usbd_get_buffer(xfer);
					usbd_setup_xfer(xfer,
					    sce->pipeh, sce, NULL, 0,
					    USBD_FORCE_SHORT_XFER | USBD_NO_COPY, USBD_NO_TIMEOUT,
					    ugen_bulkwb_intr);
					err = usbd_transfer(xfer);

	Since the length is 0 in that request, it seems like I should cause
the USB stack to generate a zero-length transaction to the target device.
I don't think that's happening, but I'm not entirely certain as yet.
The panics as described above and the inability to write to the bus after
such requests on the ehci(4) controlled busses are definitely true, but,
again, I may be trying to do this the wrong way.  Is there another way I
should be trying to generate such transactions on the USB bus?

-thanks
-Brian