[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]

Hi,

On 09/23/2014 02:15 PM, Marek Vasut wrote:
> 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 ?

Yes, when that is 1, which it is on a start / reset, the deregister should never fail.

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

Ok.

Regards,

Hans