David Meggy wrote:
The other issues with the driver are that I created it to use with RNDIS. Meaning that it works as a CDC Ethernet device and a RNDIS device, but is missing functionality that other gadget drivers use, well at least it is totally untested.
Actually, except for iso transfer (n9604 doesn't do them it seems), Ethernet link (with CDC and RNDIS modes) covers most key code paths.
- Networking loads will pretty much guarantee you not only
use bulk queues with depth > 1, but also
* concurrent IN and OUT transfers
* packets will land in them at rates variable enough to
hit many of the potential race windows
* ... including those relating to queues where the length
varies from 0..N (not constant)
- With RNDIS, the interrupt transfers are covered too;
- The ep0out stuff isn't much used outside of RNDIS.You can test the "deferred response" mode for EP0 requests using gadgetfs or Alan's "File Storage" driver.
I use "gadget zero" in the new "autoresume" mode to test suspend, resume, and remote wakeup. Easiest to do with CONFIG_USB_SUSPEND, since that lets you just write sysfs files to suspend/resume, but probably also easier to wait till I submit that!
You will probably notice the voodoo variables. I'd like to get rid of these. They are specifically for the purpose of gadget drivers not setting req_zero. Although I noticed recently that the gadget drivers were fixed up to include this information.
Heh ... I knew that other hardware was going to need that info! I don't think those patches went into my 2.4 tree yet.
Towards the end I saw a "TODO" related to sorting out which requests should be handled by the gadget driver vs the n9604_udc.c driver. Relative to what you have there, I'd say basically n9604 should do:
- {SET,CLEAR}_FEATURE for hardware -- device or endpoint -- is invisible
to gadget drivers. Except that they can control the "selfpowered"
feature, and remote wakeup requests must fail if the host didn't
enable that feature. - Since gadget drivers can't see features, then GET_STATUS must
also be handled in the n9604_udc code. - Interface features and status too ... probably not important, but
some conformance testing may care.So you've got clear-feature for halt. If hardware handles most of the rest, you're set ... and in any case, just punt anything you don't handle up to the gadget driver.
I've been using this driver on linux 2.4.25, with many patches applied including gadget updates from upstream kernels. To keep things simple I'm just attaching the n9604 files, and you will have to edit the other gadget directory files required to use this driver.
It'd be good if when you submit this, you submit the changes to the "gadget_chips.h" code and at least some of those other files. The 2.4.27 and 2.6.7 trees should be close enough that non-kbuild/kconfig patches can probably be shared between both kernels.
Any problems using the endpoint autoconfig stuff? It might be good to rename the endpoints "ep1in-bulk" and so on; those can always be used as interrupt, but "bulk" names will never be used as iso.
- Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
