On Tue, Aug 21, 2012 at 2:13 PM, Sebastian Andrzej Siewior <sebastian@xxxxxxxxxxxxx> wrote: > please drop the "force all gadget drivers to also be dynamically linked" part. > We may want to change this one day :) Done in V3 >> + if (!pd->use_fullspeed && !use_fullspeed) > so it is a good advice to have pd not set to NULL :) In V3 the probe function will call dev_err() and exit, instead of crashing. I added a comment explaining why it's mandatory: the hardware requires specifying which port is shared between the device core + host core, and if we just "assume" the wrong value, the port won't pass traffic and it won't be obvious why. >> +static bool use_fullspeed; >> +module_param(use_fullspeed, bool, S_IRUGO); >> +MODULE_PARM_DESC(use_fullspeed, "true for fullspeed only"); > > How important is this option? Maybe this should become a generic option? In theory, the hardware core should always be able to support USB 2.0 without any problems, and bcm63xx_udc.c should always be used with gadget drivers that can handle USB 2.0. In practice, there are a number of boards floating around which are only reliable at USB 1.1 speeds, either due to impedance problems or noise. These fall into two categories: 1) Boards that have their own board definition in board_bcm963xx.c, and pass this ID to Linux - in this case use_fullspeed can be specified right in the platform data. 2) Products that copied the generic board name from the reference design. In this case they'll need another way of overriding use_fullspeed, because the reference board supports high speed. Some might just add "bcm63xx_udc.use_fullspeed=1" to CONFIG_CMDLINE. Others have to detect the board revision through other means (such as reading a GPIO) and then pass the appropriate option to insmod. use_fullspeed=1 just tells the core not to negotiate USB 2.0 PHY rates. It should be roughly equivalent to plugging the device into a full speed hub. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
