diff mbox

USB Ethernet gadget on Nokia n900

Message ID 20141027223114.GU2560@atomide.com
State New
Headers show

Commit Message

Tony Lindgren Oct. 27, 2014, 10:31 p.m. UTC
* Tony Lindgren <tony@atomide.com> [141027 12:55]:
> * Pali Rohár <pali.rohar@gmail.com> [141026 15:24]:
> > On Sunday 26 October 2014 22:55:48 Pavel Machek wrote:
> > > > > I have root prepared on /dev/mmcblk0p6. I tried 3.17 with
> > > > > rx51_defconfig, but no, it refuses to mount it.
> > > > > 
> > > > > VFS: Cannot open root device "mmcblk0p6" or ....: error
> > > > > -19.
> > > > > 
> > > > > And then it proceeds to list mmcblk0p6 as one of available
> > > > > options
> > > > > 
> > > > > :-(.
> > > > > 
> > > > > Ideas welcome.
> > > > 
> > > > Try to add rootdelay=30 or rootwait to kernel cmdline.
> > > 
> > > I had rootdelay=3. Will try rootwait... no change. This is
> > > v3.17 with rx51_defconfig. CONFIG_MACH_NOKIA_RX51=y => device
> > > tree will not be used AFAICT.
> > > 
> > > Now I'm back at 3.14 without device tree; same setup works
> > > there. I tried disabling RX51 support in 3.14 (to make it
> > > boot using device tree) but that did not work.
> > > 								Pavel
> > 
> > I remember that there was some problem with initializing mmc 
> > device. Sometimes something failed and reading from eMMC was not 
> > possible. Try to boot kernel from uboot. Maybe it can help.
> 
> Would be nice to have both the USB and the MMC issues sorted
> out in the mainline kernel naturally and get rid of any bootloader
> dependencies.
> 
> I think the USB issue because usb_gadget_probe_driver() bails
> out with -ENODEV before the USB controller is found. Felipe, got
> any ideas how to fix this to work with -EPROBE_DEFER? Should this
> get called only from the USB controller probe?

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?

Regards,

Tony

8< ---------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 27 Oct 2014 14:42:42 -0700
Subject: [PATCH] usb: gadget: Fix regressions for initializing built-in gadgets

Up to v3.14 we used to have built-in gadgets work just fine
because they got initialized in the Makefile order and the
dependencies were taken care of by the platform init code.

With device tree based booting, nothing currently assures the
USB controller is initialized by the time the gadgets probe.
This is because we may have GPIOs and PHYs on I2C bus that
cause EPROBE_DEFER to happen for the USB controller.

As the gadgets are not currently bound to any device, they
get initialized with just an initcall.

Let's fix the issue by adding delayed work for the gadgets
to try binding to the USB controller driver. And while at it,
let's make the subsys_initcall() into a late_initcall_sync()
as the gadget won't be able to do anything on it's own early
anyways.

Signed-off-by: Tony Lindgren <tony@atomide.com>

Comments

Pavel Machek Oct. 28, 2014, 10:04 p.m. UTC | #1
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>
Tony Lindgren Oct. 28, 2014, 10:11 p.m. UTC | #2
* 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
Pavel Machek Oct. 28, 2014, 10:21 p.m. UTC | #3
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
Tony Lindgren Oct. 28, 2014, 10:26 p.m. UTC | #4
* 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
Pavel Machek Oct. 29, 2014, 8:46 a.m. UTC | #5
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
Tony Lindgren Oct. 29, 2014, 2:09 p.m. UTC | #6
* 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
Tomi Valkeinen Oct. 29, 2014, 2:18 p.m. UTC | #7
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
Pavel Machek Oct. 29, 2014, 9:34 p.m. UTC | #8
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
Pali Rohár Oct. 31, 2014, 8:30 p.m. UTC | #9
On Friday 31 October 2014 21:03:18 Pavel Machek wrote:
> Hi!
> 
> I tried enabling audio. It works ...sometimes... after fixing
> kconfig. But I'm getting WARN_ON, about 50% of time. Ideas
> welcome.
> 
> 								Pavel
> 

I see same problem with audio. Sometimes after reboot it working 
and sometimes not. It looks like Nokia Bootloader set something 
somewhere and then it works... I have no idea how to fix it...
Pali Rohár July 6, 2015, 1:24 p.m. UTC | #10
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?
Tony Lindgren July 6, 2015, 1:53 p.m. UTC | #11
* 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
Pali Rohár July 7, 2015, 7:46 a.m. UTC | #12
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?
Tony Lindgren July 7, 2015, 11:46 a.m. UTC | #13
* 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
Pali Rohár Jan. 19, 2016, 8:58 p.m. UTC | #14
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
Pali Rohár Feb. 11, 2016, 2:43 p.m. UTC | #15
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?
Pali Rohár Feb. 11, 2016, 2:50 p.m. UTC | #16
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)
diff mbox

Patch

--- 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;