On Saturday 14 August 2004 6:03 am, [EMAIL PROTECTED] wrote: > This patch implements the USB client controller (UDC) driver from > scratch on the LPD-LH7A40X development boards, using the new USB > interface that came with 2.6 series. Several gadget drivers have also > been patched in order for them to recognize the UDC driver when probed.
Great, I'm glad to see another UDC driver ready for use! > The driver is tested to work with both lpd7a400 and lpd7a404 > I first published this patch in linux-arm; however, Russell King has > requested that this patch would be published here so here it is. Thanks, I didn't have your email ... Russell pointed me at your patch in the ARM Linux database, that one seemed less mangled by some mailer than this one ... :) This seems to be three separate patches in one: - arch/arm/mach-lh7a40x/ stuff ... certainly should go through the ARM Linux system. I won't comment on these. - drivers/usb/gadget/lh7a40x_udc ...comments below, this could go through the ARM Linux patch system though I guess the drivers/usb/host/ohci-lh7a404 support didn't. - Gadget driver patches ... which I've already pulled out, updated, merged into the gadget-2.6 tree and submitted to Greg for 2.6.9). Comments below. These include a couple of Russell's comments; if they get resolved, I wouldn't know any particular reason this shouldn't get merged. - Formatting is messy. Indentation inconsistent within functions (4 spaces ugh; use only tabs), both for start-of-line and for variables/members. I suggest you start with scripts/Lindent. - At least one non-ASCII character (which may be what got this mangled in email) ... I understand the policy is now to stick to ASCII (7 bits) in kernel sources. - Why have a separate C file for the ep0 code? Just merge it with main part of the driver. - Seems odd to see "Bo Henriksen" be credited with Copyright, but "Sami Heino" get the author credit. Both names in both places, maybe? - Without DMA support in the driver, you should not set up a dma_mask in the udc probe() routine. (Higher level code is allowed to check that pointer to decide if it should kick in smarter DMA logic.) Personally, I'd remove all the DMA logic until it's usable in at least one direction. Otherwise, nothing looked particularly worrisome. But I'm also curious what level of testing has been done with this driver. Sanity testing with all gadget drivers? Stress testing with Gadget Zero? - Dave ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
