The patch looks nice, a lot better than things were before. Also are these lines strictly required:
if (gadget_is_net2280 (gadget)) { device_desc.bcdDevice = __constant_cpu_to_le16 (0x0201); ...
It preserves the previous functionality. Not "necessary" in some senses, but autoconfiguration shouldn't mean losing any functionality.
? Or it's just good for debugging to know what UDC the gadget uses? I'm
It's normal to expose driver-visible firmware differences using bcdDevice. Often, host side USB device drivers don't actually parse the config descriptors; they just use bcdDevice, and they "know" how the device resources are numbered. Even some Linux drivers do that; and it's not uncommon on other hosts either.
It's specifically not a friendly thing to have two devices with the same vendor, product, and version (bcdDevice) codes use different endpoint numbering.
worried if someone will take g_zero as a template for his driver (and it *is* designed as a template), and will replicate without much thinking these lines, we'll end up with the same need to modify every gadget as soon as new UDC drivers are added, that your patch is supposed to alleviate :)
And "alleviate" is the right word: not "eliminate". I think it clearly "alleveates" the issue!
Testing is required, it's common that new controllers have restrictions that gadget driver must handle ... or bugs in the controller driver that only show up with the usage pattern of that driver.
Having to explicitly add a line to the gadget driver, flagging that at least _some_ thought went into support for that particular hardware, doesn't bother me much.
Notable changes were: - Assume self-powered operation for now.
This could be solved by using UDC capabilities bitflags :) Or use a gadget->name like "pxa2xx_udc_selfpowered" :)
Well, I did conclude that "gadget_is_dualspeed()" should be a "gadget->is_dualspeed" bit...
But most of those chips don't actually support bus-powered operation; they need too much current, in both active and (usb) suspend modes. An "is_bus_powered" bit might be reasonable too, but I'd rather wait until we have Linux hardware implementing bus-powered operation before making such a change; it may not be the only one needed.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
