lkml.org 
[lkml]   [2013]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On 04/23/2013 11:10 PM, Alan Stern wrote:
> On Tue, 23 Apr 2013, Greg KH wrote:
>
>> On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
>>> From: "Li, Zhen-Hua" <zhen-hual@hp.com>
>>>
>>> This patch is trying to fix bug QXCR1001261767.
>> What is that bug number? Where can it be referenced? If you are going
>> to put it in a public place (like a kernel changelog), it needs to be
>> publicly accessible.
>>
>>> On some HP platform, when usb driver inits the iLo Virtual USB Controller, there may be a warning "Controller not stopped yet!". It is because driver does not wait enough time.
>> What happened to your line endings?
>>
>>> This patch adds more time waiting and retries.
>> Why not only do this for your device?
> It won't hurt to do it for all devices, because the wait loop will
> terminate as soon as the controller goes into suspend. For normal
> controllers this will be on the first iteration.
Yes, most devices only need one time check.
>>> Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
>>> ---
>>> drivers/usb/host/uhci-hcd.c | 16 +++++++++++++++-
>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
>>> index 4a86b63..514e9d7 100644
>>> --- a/drivers/usb/host/uhci-hcd.c
>>> +++ b/drivers/usb/host/uhci-hcd.c
>>> @@ -277,6 +277,9 @@ static int global_suspend_mode_is_broken(struct uhci_hcd *uhci)
>>> uhci->global_suspend_mode_is_broken(uhci) : 0;
>>> }
>>>
>>> +#define UHCI_SUSPENDRH_RETRY_MAX 10
>>> +#define UHCI_SUSPENDRH_RETRY_DELAY 100
> Why is the delay set to 100 us? Isn't that excessively large? How
> long does it take for this controller to go into suspend?
This controller will take about 200~400 us, but I am not sure how long
other devices will take.
I set interval to 100 us, so it will save more time.

>
>>> static void suspend_rh(struct uhci_hcd *uhci, enum uhci_rh_state new_state)
>>> __releases(uhci->lock)
>>> __acquires(uhci->lock)
>>> @@ -284,6 +287,7 @@ __acquires(uhci->lock)
>>> int auto_stop;
>>> int int_enable, egsm_enable, wakeup_enable;
>>> struct usb_device *rhdev = uhci_to_hcd(uhci)->self.root_hub;
>>> + u16 try, stopped;
> Why are these variables u16? Why not int?
uhci_readw will return u16.
> Anyway, a better approach would be not to add a delay loop at all.
> Instead, change this test:
>
> if (!auto_stop && !(uhci_readw(uhci, USBSTS) & USBSTS_HCH)) {
> uhci->rh_state = UHCI_RH_SUSPENDING;
> spin_unlock_irq(&uhci->lock);
> msleep(1);
> spin_lock_irq(&uhci->lock);
> if (uhci->dead)
> return;
> }
>
> When the iLo controller is present, make the "if" statement always
> succeed. Then you'll get a whole 1-ms delay.
This will cause more operation and more time for other devices.
> Alan Stern
>



\
 
 \ /
  Last update: 2013-04-25 03:41    [W:0.169 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site