| Message ID | 20141027223114.GU2560@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi! > Here's a patch that should fix the issues for built-in USB > gadgets. > > Pavel, care to see if this gets NFSroot over USB working again > for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! Tested-by: Pavel Machek <pavel@ucw.cz>
* Pavel Machek <pavel@ucw.cz> [141028 15:06]: > Hi! > > > Here's a patch that should fix the issues for built-in USB > > gadgets. > > > > Pavel, care to see if this gets NFSroot over USB working again > > for you? > > It seems to have did the trick for me. (Plus I needed to add > > +CONFIG_ARM_ATAG_DTB_COMPAT=y > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > > to be able to control the command line, that's why testing took me a > while.) Hmm I think I have a patch somewhere here to enable the standard bootz command for n900 mainline u-boot.. That way you can just do # bootz ${loadaddr} - ${fdtaddr} > Networking now works against 3.17-based kernel. Thanks! Right on! Ideally the gadget probe would be event driven and called after USB controller driver probe. But that would mean keeping a list of all the gadgets as Felipe told me. > Tested-by: Pavel Machek <pavel@ucw.cz> Thanks for testing, Tony
On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > Hi! > > > Here's a patch that should fix the issues for built-in USB > > gadgets. > > > > Pavel, care to see if this gets NFSroot over USB working again > > for you? > > It seems to have did the trick for me. (Plus I needed to add > > +CONFIG_ARM_ATAG_DTB_COMPAT=y > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > > to be able to control the command line, that's why testing took me a > while.) > > Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek <pavel@ucw.cz> Best regards, Pavel
* Pavel Machek <pavel@ucw.cz> [141028 15:22]: > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > Hi! > > > > > Here's a patch that should fix the issues for built-in USB > > > gadgets. > > > > > > Pavel, care to see if this gets NFSroot over USB working again > > > for you? > > > > It seems to have did the trick for me. (Plus I needed to add > > > > +CONFIG_ARM_ATAG_DTB_COMPAT=y > > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > > +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > > > > to be able to control the command line, that's why testing took me a > > while.) > > > > Networking now works against 3.17-based kernel. Thanks! > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply > to 3.17, no changes needed for 3.18-rc1.) > > Tested-by: Pavel Machek <pavel@ucw.cz> Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. Regards, Tony
Hi! > > > Here's a patch that should fix the issues for built-in USB > > > gadgets. > > > > > > Pavel, care to see if this gets NFSroot over USB working again > > > for you? > > > > It seems to have did the trick for me. (Plus I needed to add > > > > +CONFIG_ARM_ATAG_DTB_COMPAT=y > > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > > +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > > > > to be able to control the command line, that's why testing took me a > > while.) > > Hmm I think I have a patch somewhere here to enable the standard > bootz command for n900 mainline u-boot.. That way you can just do > > # bootz ${loadaddr} - ${fdtaddr} Actually, I guess booting directly from ROM using 0xffff is easier for testing for now. Speaking of testing: I'm not sure what is omap_l3_smx neccessary for, but it does not work. [ 0.223297] omap_l3_smx omap_l3_smx.0: couldn't request debug irq [ 0.223419] omap_l3_smx: probe of omap_l3_smx.0 failed with error -22 There is some fun in pinmuxing: [ 0.247131] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.248291] irq: no irq domain found for /ocp/pinmux@48002030 ! ... [ 0.384826] omap_i2c 48070000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c1_pins, deferring probe [ 0.384918] platform 48070000.i2c: Driver omap_i2c requests probe deferral [ 0.385070] omap_i2c 48072000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c2_pins, deferring probe [ 0.385162] platform 48072000.i2c: Driver omap_i2c requests probe deferral [ 0.385284] omap_i2c 48060000.i2c: could not find pctldev for node /ocp/pinmux@48002030/pinmux_i\ 2c3_pins, deferring probe [ 0.385375] platform 48060000.i2c: Driver omap_i2c requests probe deferral And serial has some problems: [ 0.482208] of_get_named_gpiod_flags: can't parse 'rts-gpio' property of node '/ocp/serial@4806c\ 000[0]' [ 0.482513] omap_uart 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 223, base_baud = 3000000)\ is a OMAP UART1 [ 0.484588] of_get_named_gpiod_flags: can't parse 'rts-gpio' property of node '/ocp/serial@49020\ 000[0]' [ 0.484771] omap_uart 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 224, base_baud = 3000000)\ is a OMAP UART2 There's a lot of noise from probe defferal :-(. And it looks like mmc properties have some problems: [ 0.739349] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp/mmc@4809c000\ [0]' [ 0.740142] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [ 0.740386] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [ 0.740661] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/ocp/mmc@480b4000\ [0]' [ 0.740692] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp/mmc@480b4000\ [0]' omapfb reports problems, but seems to work ok: [ 0.990386] omapfb omapfb: cannot parse default modes [ 1.004791] Console: switching to colour frame buffer device 100x30 [ 1.073150] omapfb omapfb: using display 'lcd' mode 800x480 Best regards, Pavel
* Pavel Machek <pavel@ucw.cz> [141029 01:48]: > > Speaking of testing: > > I'm not sure what is omap_l3_smx neccessary for, but it does not work. > > [ 0.223297] omap_l3_smx omap_l3_smx.0: couldn't request debug irq > [ 0.223419] omap_l3_smx: probe of omap_l3_smx.0 failed with error > -22 Hmm this should be fixed to get interrupts about invalid bus access. > There is some fun in pinmuxing: > > [ 0.247131] irq: no irq domain found for /ocp/pinmux@48002030 ! > [ 0.248291] irq: no irq domain found for /ocp/pinmux@48002030 ! > ... > [ 0.384826] omap_i2c 48070000.i2c: could not find pctldev for node > /ocp/pinmux@48002030/pinmux_i\ > 2c1_pins, deferring probe > [ 0.384918] platform 48070000.i2c: Driver omap_i2c requests probe > deferral > [ 0.385070] omap_i2c 48072000.i2c: could not find pctldev for node > /ocp/pinmux@48002030/pinmux_i\ > 2c2_pins, deferring probe > [ 0.385162] platform 48072000.i2c: Driver omap_i2c requests probe > deferral > [ 0.385284] omap_i2c 48060000.i2c: could not find pctldev for node > /ocp/pinmux@48002030/pinmux_i\ > 2c3_pins, deferring probe > [ 0.385375] platform 48060000.i2c: Driver omap_i2c requests probe > deferral These are related to deferred probe and should go away when we make drivers/i2c/busses/i2c-omap.c to use regular module_init and stop using subsys_initcall. But I think legacy booting still needs it early, could be omap1 only nowadays though. > And serial has some problems: > > [ 0.482208] of_get_named_gpiod_flags: can't parse 'rts-gpio' > property of node '/ocp/serial@4806c\ > 000[0]' > [ 0.482513] omap_uart 4806c000.serial: ttyO1 at MMIO 0x4806c000 > (irq = 223, base_baud = 3000000)\ > is a OMAP UART1 > [ 0.484588] of_get_named_gpiod_flags: can't parse 'rts-gpio' > property of node '/ocp/serial@49020\ > 000[0]' > [ 0.484771] omap_uart 49020000.serial: ttyO2 at MMIO 0x49020000 > (irq = 224, base_baud = 3000000)\ > is a OMAP UART2 I these come from the GPIO framework when booting with debug enabled. > There's a lot of noise from probe defferal :-(. And it looks like mmc > properties have some problems: > > [ 0.739349] of_get_named_gpiod_flags: can't parse 'wp-gpios' > property of node '/ocp/mmc@4809c000\ > [0]' > [ 0.740142] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator > -517 > [ 0.740386] platform 4809c000.mmc: Driver omap_hsmmc requests probe > deferral > [ 0.740661] of_get_named_gpiod_flags: can't parse 'cd-gpios' > property of node '/ocp/mmc@480b4000\ > [0]' > [ 0.740692] of_get_named_gpiod_flags: can't parse 'wp-gpios' > property of node '/ocp/mmc@480b4000\ > [0]' These too. But yeah, I agree, let's try to patch away some of the deferred probe noise. > omapfb reports problems, but seems to work ok: > > [ 0.990386] omapfb omapfb: cannot parse default modes > [ 1.004791] Console: switching to colour frame buffer device 100x30 > [ 1.073150] omapfb omapfb: using display 'lcd' mode 800x480 Tomi, is the default mode warning correct here? Regards, Tony
On 29/10/14 16:09, Tony Lindgren wrote: >> omapfb reports problems, but seems to work ok: >> >> [ 0.990386] omapfb omapfb: cannot parse default modes >> [ 1.004791] Console: switching to colour frame buffer device 100x30 >> [ 1.073150] omapfb omapfb: using display 'lcd' mode 800x480 > > Tomi, is the default mode warning correct here? omapfb warns that it couldn't parse kernel cmdline parameters ('omapfb.mode' parameter). I couldn't find in the thread what actual parameters were used in this case. Although I don't see why N900 would need any omapfb mode parameters in the first place, as the LCD has just one mode... Tomi
On Wed 2014-10-29 16:18:46, Tomi Valkeinen wrote: > On 29/10/14 16:09, Tony Lindgren wrote: > > >> omapfb reports problems, but seems to work ok: > >> > >> [ 0.990386] omapfb omapfb: cannot parse default modes > >> [ 1.004791] Console: switching to colour frame buffer device 100x30 > >> [ 1.073150] omapfb omapfb: using display 'lcd' mode 800x480 > > > > Tomi, is the default mode warning correct here? > > omapfb warns that it couldn't parse kernel cmdline parameters > ('omapfb.mode' parameter). I couldn't find in the thread what actual > parameters were used in this case. I had omapfb.mode=lcd:848x480-16 on command line. I removed it now. > Although I don't see why N900 would need any omapfb mode parameters in > the first place, as the LCD has just one mode... I don't know where I copied it from, sorry... Pavel
On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > Hi! > > > > > > > Here's a patch that should fix the issues for built-in USB > > > > gadgets. > > > > > > > > Pavel, care to see if this gets NFSroot over USB working again > > > > for you? > > > > > > It seems to have did the trick for me. (Plus I needed to add > > > > > > +CONFIG_ARM_ATAG_DTB_COMPAT=y > > > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > > > +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > > > > > > to be able to control the command line, that's why testing took > > > me a while.) > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to > > apply to 3.17, no changes needed for 3.18-rc1.) > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > Whatever we decice to do to fix this regression, it should probably > be backported to at least v3.16 stable for distro use, maybe earlier > too. I'd assume this is broken on multiple platforms currently. > > Regards, > > Tony Hi Tony, it looks like this patch was not included into any kernel version... I'm still using it on top of 4.x kernels. Are you going to send this patch into upstream? Or do you have another fix for this problem?
* Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to > > > apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > Whatever we decice to do to fix this regression, it should probably > > be backported to at least v3.16 stable for distro use, maybe earlier > > too. I'd assume this is broken on multiple platforms currently. > > > it looks like this patch was not included into any kernel version... I'm > still using it on top of 4.x kernels. Are you going to send this patch > into upstream? Or do you have another fix for this problem? I think Felipe mentioned a better built-in gether fix that's been reviewed on linux-usb list. Regards, Tony
On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to > > > > apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > > > Whatever we decice to do to fix this regression, it should probably > > > be backported to at least v3.16 stable for distro use, maybe earlier > > > too. I'd assume this is broken on multiple platforms currently. > > > > > it looks like this patch was not included into any kernel version... I'm > > still using it on top of 4.x kernels. Are you going to send this patch > > into upstream? Or do you have another fix for this problem? > > I think Felipe mentioned a better built-in gether fix that's been > reviewed on linux-usb list. > > Regards, > > Tony Do you have link to that email thread? Or was Felipe's fix already merged into mainline kernel?
* Pali Rohár <pali.rohar@gmail.com> [150707 00:48]: > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > > * Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to > > > > > apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > Whatever we decice to do to fix this regression, it should probably > > > > be backported to at least v3.16 stable for distro use, maybe earlier > > > > too. I'd assume this is broken on multiple platforms currently. > > > > > > > it looks like this patch was not included into any kernel version... I'm > > > still using it on top of 4.x kernels. Are you going to send this patch > > > into upstream? Or do you have another fix for this problem? > > > > I think Felipe mentioned a better built-in gether fix that's been > > reviewed on linux-usb list. > > Do you have link to that email thread? Or was Felipe's fix already > merged into mainline kernel? Sorry I don't have a link, maybe Felipe can point you to the right patch. Regards, Tony
On Tuesday 07 July 2015 13:46:59 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [150707 00:48]: > > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > > > * Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify > > > > > > patch to apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > > > Whatever we decice to do to fix this regression, it should > > > > > probably be backported to at least v3.16 stable for distro > > > > > use, maybe earlier too. I'd assume this is broken on > > > > > multiple platforms currently. > > > > > > > > it looks like this patch was not included into any kernel > > > > version... I'm still using it on top of 4.x kernels. Are you > > > > going to send this patch into upstream? Or do you have another > > > > fix for this problem? > > > > > > I think Felipe mentioned a better built-in gether fix that's been > > > reviewed on linux-usb list. > > > > Do you have link to that email thread? Or was Felipe's fix already > > merged into mainline kernel? > > Sorry I don't have a link, maybe Felipe can point you to the right > patch. > > Regards, > > Tony Felipe, ping
On Tuesday 19 January 2016 21:58:19 Pali Rohár wrote: > On Tuesday 07 July 2015 13:46:59 Tony Lindgren wrote: > > * Pali Rohár <pali.rohar@gmail.com> [150707 00:48]: > > > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > > > > * Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > > > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > > > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify > > > > > > > patch to apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > > > > > Whatever we decice to do to fix this regression, it should > > > > > > probably be backported to at least v3.16 stable for distro > > > > > > use, maybe earlier too. I'd assume this is broken on > > > > > > multiple platforms currently. > > > > > > > > > > it looks like this patch was not included into any kernel > > > > > version... I'm still using it on top of 4.x kernels. Are you > > > > > going to send this patch into upstream? Or do you have another > > > > > fix for this problem? > > > > > > > > I think Felipe mentioned a better built-in gether fix that's been > > > > reviewed on linux-usb list. > > > > > > Do you have link to that email thread? Or was Felipe's fix already > > > merged into mainline kernel? > > > > Sorry I don't have a link, maybe Felipe can point you to the right > > patch. > > > > Regards, > > > > Tony > > Felipe, ping > PING?
On Thursday 11 February 2016 15:43:47 Pali Rohár wrote: > On Tuesday 19 January 2016 21:58:19 Pali Rohár wrote: > > On Tuesday 07 July 2015 13:46:59 Tony Lindgren wrote: > > > * Pali Rohár <pali.rohar@gmail.com> [150707 00:48]: > > > > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > > > > > * Pali Rohár <pali.rohar@gmail.com> [150706 06:27]: > > > > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > > > > > * Pavel Machek <pavel@ucw.cz> [141028 15:22]: > > > > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify > > > > > > > > patch to apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > > > > > > > > > Tested-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > > > > > > > Whatever we decice to do to fix this regression, it should > > > > > > > probably be backported to at least v3.16 stable for distro > > > > > > > use, maybe earlier too. I'd assume this is broken on > > > > > > > multiple platforms currently. > > > > > > > > > > > > it looks like this patch was not included into any kernel > > > > > > version... I'm still using it on top of 4.x kernels. Are you > > > > > > going to send this patch into upstream? Or do you have another > > > > > > fix for this problem? > > > > > > > > > > I think Felipe mentioned a better built-in gether fix that's been > > > > > reviewed on linux-usb list. > > > > > > > > Do you have link to that email thread? Or was Felipe's fix already > > > > merged into mainline kernel? > > > > > > Sorry I don't have a link, maybe Felipe can point you to the right > > > patch. > > > > > > Regards, > > > > > > Tony > > > > Felipe, ping > > > > PING? > Ok, Felipe address is dead: 550 Invalid recipient <balbi@ti.com> (#5.1.1)
--- a/drivers/usb/gadget/udc/udc-core.c +++ b/drivers/usb/gadget/udc/udc-core.c @@ -440,13 +440,20 @@ out: } EXPORT_SYMBOL_GPL(udc_attach_driver); -int usb_gadget_probe_driver(struct usb_gadget_driver *driver) +#define USB_GADGET_BIND_RETRIES 5 +#define USB_GADGET_BIND_TIMEOUT (3 * HZ) +static void usb_gadget_work(struct work_struct *work) { + struct usb_gadget_driver *driver = container_of(work, + struct usb_gadget_driver, + work.work); struct usb_udc *udc = NULL; int ret; - if (!driver || !driver->bind || !driver->setup) - return -EINVAL; + if (driver->retries++ > USB_GADGET_BIND_RETRIES) { + pr_err("couldn't find an available UDC\n"); + return; + } mutex_lock(&udc_lock); list_for_each_entry(udc, &udc_list, list) { @@ -455,13 +462,24 @@ int usb_gadget_probe_driver(struct usb_gadget_driver *driver) goto found; } - pr_debug("couldn't find an available UDC\n"); mutex_unlock(&udc_lock); - return -ENODEV; + schedule_delayed_work(&driver->work, USB_GADGET_BIND_TIMEOUT); + return; + found: ret = udc_bind_to_driver(udc, driver); mutex_unlock(&udc_lock); - return ret; +} + +int usb_gadget_probe_driver(struct usb_gadget_driver *driver) +{ + if (!driver || !driver->bind || !driver->setup) + return -EINVAL; + + INIT_DELAYED_WORK(&driver->work, usb_gadget_work); + schedule_delayed_work(&driver->work, 0); + + return 0; } EXPORT_SYMBOL_GPL(usb_gadget_probe_driver); @@ -473,6 +491,8 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver) if (!driver || !driver->unbind) return -EINVAL; + cancel_delayed_work(&driver->work); + mutex_lock(&udc_lock); list_for_each_entry(udc, &udc_list, list) if (udc->driver == driver) { @@ -621,7 +641,7 @@ static int __init usb_udc_init(void) udc_class->dev_uevent = usb_udc_uevent; return 0; } -subsys_initcall(usb_udc_init); +late_initcall_sync(usb_udc_init); static void __exit usb_udc_exit(void) { --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -819,6 +819,8 @@ static inline int usb_gadget_disconnect(struct usb_gadget *gadget) * @resume: Invoked on USB resume. May be called in_interrupt. * @reset: Invoked on USB bus reset. It is mandatory for all gadget drivers * and should be called in_interrupt. + * @work: Gadget work used to bind to the USB controller. + * @retries: Gadget retries to bind to the USB controller. * @driver: Driver model state for this driver. * * Devices are disabled till a gadget driver successfully bind()s, which @@ -877,6 +879,8 @@ struct usb_gadget_driver { void (*suspend)(struct usb_gadget *); void (*resume)(struct usb_gadget *); void (*reset)(struct usb_gadget *); + struct delayed_work work; + int retries; /* FIXME support safe rmmod */ struct device_driver driver;