[U-Boot] [PATCH fix for v2014.10 2/5] usb: kbd: On a "usb reset" call usb_kbd_deregister() before calling usb_stop()

[Marek Vasut]

On Tuesday, September 23, 2014 at 11:10:34 AM, Hans de Goede wrote:
> Hi,
> 
> On 09/22/2014 02:01 PM, Marek Vasut wrote:
> > On Saturday, September 20, 2014 at 04:54:35 PM, Hans de Goede wrote:
> >> We need to call usb_kbd_deregister() before calling usb_stop().
> >> 
> >> usbkbd's stdio_dev->priv points to the usb_device, and usb_kbd_testc
> >> dereferences usb_device->privptr.
> >> 
> >> usb_stop zeros usb_device, leaving usb_device->privptr NULL, causing
> >> bad things (tm) to happen once control returns to the main loop and
> >> usb_kbd_testc gets called.
> >> 
> >> Calling usb_kbd_deregister() avoids this. Note that we do not allow
> >> the "usb reset" to continue when the deregister fails. This will be
> >> fixed in a later patch.
> >> 
> >> For the same reasons always fail "usb stop" if the usb_kbd_deregister()
> >> fails, even in the force path. This can happen when
> >> CONFIG_SYS_STDIO_DEREGISTER is not set.
> >> 
> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> >> ---
> >> 
> >>  common/cmd_usb.c | 27 +++++++++++++++------------
> >>  1 file changed, 15 insertions(+), 12 deletions(-)
> >> 
> >> diff --git a/common/cmd_usb.c b/common/cmd_usb.c
> >> index 2519497..b2aa44c 100644
> >> --- a/common/cmd_usb.c
> >> +++ b/common/cmd_usb.c
> >> @@ -430,6 +430,16 @@ static int do_usbboot(cmd_tbl_t *cmdtp, int flag,
> >> int argc, char * const argv[]) }
> >> 
> >>  #endif /* CONFIG_USB_STORAGE */
> >> 
> >> +static int do_usb_stop_keyboard(void)
> >> +{
> >> +#ifdef CONFIG_USB_KEYBOARD
> >> +	if (usb_kbd_deregister() != 0) {
> >> +		printf("USB not stopped: usbkbd still using USB\n");
> > 
> > I tried this set of patches with the DWC2 driver on RPI just now and i
> > get this message and 'usb start' fails and doesn't scan bus. I suspect
> > we have a problem here, can you check and post a fix ?
> 
> Do you have the entire set applied ?

Yes, the current u-boot-usb/master

> This is a known regression as
> mentioned in the commit msg. Once the force parameter is in place this
> should go away for a start/reset.

You mean the 'force' param ?

> Also is usb start being called twice ? The first deregister should never
> fail, since then no device is registered.

Ugh, I must be dumb or somesuch, for whatever reason the issue went away and I 
can no longer replicate it. I will keep on a lookout.

Best regards,
Marek Vasut