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

[Hans de Goede <hdegoede@redhat.com>]

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@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 ? 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.

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

Regards,

Hans