Hey all. I've got an HP dv5178us notebook with an apparent BIOS
bug in which it doesn't properly report that it's completed the
EHCI handoff. Unfortunately, this causes a 5 second snag at
every boot. This is -much- too long in my opinion.

My resolution for the issue is simply to cut the 5 seconds down
to 0.5 seconds. I am unsure whether changing the timeout is
wise, though, because I suppose it's possible that a buggy BIOS
could announce the success of the handoff -after- the timeout.

Thoughts?

Steven Noonan (1):
  drivers/usb/host/pci-quirks.c: wait for EHCI handoff far too long in
    quirk_usb_disable_ehci()

 drivers/usb/host/pci-quirks.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

--

[ message continues ]

This patch fixes a very noticeable bootup delay on some
systems (in my particular case, an HP dv5178us). The
problem is caused by a buggy BIOS which doesn't properly
announce that the handoff was completed.

The delay in the current version of pci-quirks.c is 5 seconds,
which I've cut down to 0.5 seconds.

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
---
 drivers/usb/host/pci-quirks.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ae6e70e..9a3609a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -271,7 +271,7 @@ static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
 			/* if boot firmware now owns EHCI, spin till
 			 * it hands it over.
 			 */
-			msec = 5000;
+			msec = 500;
 			while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
 				tried_handoff = 1;
 				msleep(10);
-- 
1.6.0.1

--

[ message continues ]

(cc linux-usb)


I guess it risks breaking someone else's system.  Or perhaps the number
was just grabbed out of the air.

Can we do a separate quirk just for that machine (and ones with the
same bug)?

--

[ message continues ]

As far as I know, it was indeed just grabbed out of the air.  The spec 

My BIOS has the same bug.  I wouldn't mind seeing the delay reduced.

Alan Stern

--

[ message continues ]

I'm fairly sure that someone's system needed more than 1/2 second.
And that going from 500 to 5000 was the obvious "add a zero" way
to get to a long-enough timeout.
--

[ message continues ]