linux-kernel - Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Apr 2013 09:22:55 +0800
From:	ZhenHua <zhen-hual@...com>
To:	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <gregkh@...uxfoundation.org>
CC:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	tom.vaden@...com
Subject: Re: [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@...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@...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
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/