USB BIOS early handoff only when the we the driver is configured

PATCH In review David Engraf 4 participants 14 messages Jul 31, 2007 – Aug 7, 2007 1 message not in the archive

Share & tools

David Engraf

author

2007-07-31 08:32 UTC #0 lore raw

PATCH 1/1 USB BIOS early handoff only when the we the driver is configured

When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is not configured we don't need to call the quirk_usb_handoff_xxxx function in driver/usb/host/pci_quiks.c.

I think the kernel shouldn't take the control over the usb controller when we don't have the driver for it,
so with this patch the kernel takes the control only when the driver is configured.

linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c 2007-07-10 20:56:30.000000000
+0200
+++ drivers/usb/host/pci-quirks.c 2007-07-31 09:55:28.000000000 +0200
@@ -142,6 +142,7 @@ static inline int io_type_enabled(struct
#define pio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_IO) #define mmio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_MEMORY)

+#ifdef CONFIG_USB_UHCI_HCD
static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev)

 {
     unsigned long base = 0;
@@ -159,12 +160,14 @@ static void __devinit quirk_usb_handoff_
     if (base)
         uhci_check_and_reset_hc(pdev, base);

}
+#endif

static int __devinit mmio_resource_enabled(struct pci_dev *pdev, int idx)

 {
     return pci_resource_start(pdev, idx) && mmio_enabled(pdev);

}

+#ifdef CONFIG_USB_OHCI_HCD
static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)

 {
     void __iomem *base;

@@ -209,7 +212,9 @@ static void __devinit quirk_usb_handoff_

     iounmap(base);

}
+#endif

+#ifdef CONFIG_USB_EHCI_HCD
static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)

 {
     int wait_time, delta;

@@ -346,16 +351,24 @@ static void __devinit quirk_usb_disable_

     return;

}
-
+#endif

static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev) {
+#ifdef CONFIG_USB_UHCI_HCD

     if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
         quirk_usb_handoff_uhci(pdev);

- else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
+#endif
+
+#ifdef CONFIG_USB_OHCI_HCD
+ if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)

         quirk_usb_handoff_ohci(pdev);

- else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
+#endif
+
+#ifdef CONFIG_USB_EHCI_HCD
+ if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)

         quirk_usb_disable_ehci(pdev);

+#endif
}
DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);

Thanks

David Engraf

Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]

Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

Alan Stern

2007-07-31 15:04 UTC #1 lore raw

Quoted 8 lines · David Engraf

When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is not configured we don't need to call the quirk_usb_handoff_xxxx function in driver/usb/host/pci_quiks.c.
I think the kernel shouldn't take the control over the usb controller when we don't have the driver for it,
so with this patch the kernel takes the control only when the driver is configured.

Have you found a system where this really improves behavior or is it just theoretical?

There _is_ a theoretical reason for running the handoff routines even when the corresponding driver isn't configured. Namely, at startup the controller will be in some undetermined state as a result of usage by the firmware. Resetting it to a known idle state is a good idea.

Bear in mind that on some systems, not performing the handoff has caused interrupt storms during startup.

Alan Stern

A message that is not in the archive (sent off-list or not yet received): [email protected]

David Engraf

author

2007-08-01 07:22 UTC #3 lore raw

At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff.
Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.
On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

David Engraf

Quoted 28 lines · Alan Stern

Quoted 9 lines · David Engraf
When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is not configured we don't need to call the quirk_usb_handoff_xxxx function in driver/usb/host/pci_quiks.c.
I think the kernel shouldn't take the control over the usb controller when we don't have the driver for it,
so with this patch the kernel takes the control only when the driver is configured.
Have you found a system where this really improves behavior or is it just theoretical?
There _is_ a theoretical reason for running the handoff routines even when the corresponding driver isn't configured. Namely, at startup the controller will be in some undetermined state as a result of usage by the firmware. Resetting it to a known idle state is a good idea.
Bear in mind that on some systems, not performing the handoff has caused interrupt storms during startup.
Alan Stern

Signature · 20 lines

Mit freundlichen Grüßen

 

David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: 	+49 6131 6305 0
Fax: 	+49 6131 6305 40
Email: 	[email protected]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

Greg KH

2007-08-01 20:21 UTC #4 lore raw

Quoted 5 lines · David Engraf

At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff.
Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.

This sounds like a BIOS bug.

Quoted 5 lines

On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

We need to do this early to handle a wide range of machines that do very nasty things if we do not grab the device as early as possible. Even if we do not ever get around to loading that usb driver.

Yeah, hardware sucks at times :(

thanks,

greg k-h

David Engraf

author

2007-08-02 07:08 UTC #5 lore raw

Quoted 11 lines · Greg KH

Quoted 6 lines · David Engraf
At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff.
Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.
This sounds like a BIOS bug.

I think so too and I have to talk to Jetway/VIA what there is going wrong.

Quoted 8 lines

Quoted 7 lines
On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

Quoted 7 lines

We need to do this early to handle a wide range of machines that do very nasty things if we do not grab the device as early as possible. Even if we do not ever get around to loading that usb driver.
Yeah, hardware sucks at times :(

Ok, but when we don't habe the driver for the usb controller, I think the BIOS should control it because
maybe the BIOS found for example a keyboard or mouse and emulates it as an PS2 keayboard/mouse,
so we could use it without the usb driver. I think that's why they developed the handoff feature.
Are there any known hardware which has problems when we disable the handoff?

Quoted 4 lines

thanks,
greg k-h

Thanks

David Engraf

Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]

Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

Alan Stern

2007-08-01 14:41 UTC #6 lore raw

In reply to a message not in the archive

Quoted 5 lines · David Engraf

At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff. Even
when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.

I have the same problem on my Intel motherboard. Which is surprising, considering that Intel invented the BIOS-handoff technique.

Quoted 5 lines

On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

There ought to be a solution to satisfy everybody. For instance, you could add a Kconfig flag for enabling USB handoff, and make it be selected automatically if any of the PCI USB drivers are configured.

Alan Stern

David Engraf

author

2007-08-02 07:16 UTC #7 lore raw

Quoted 10 lines · Alan Stern

Quoted 6 lines · David Engraf
At the moment I have a Jetway/VIA Mainboard which seems to have a problem with the handoff. Even
when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.

Quoted 4 lines

I have the same problem on my Intel motherboard. Which is surprising, considering that Intel invented the BIOS-handoff technique.

Ok, so even Intel has problems with the handoff.

Quoted 7 lines

Quoted 6 lines
On the other hand, I don't need the EHCI controller in my kernel, so I think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

Quoted 7 lines

There ought to be a solution to satisfy everybody. For instance, you could add a Kconfig flag for enabling USB handoff, and make it be selected automatically if any of the PCI USB drivers are configured.
Alan Stern

This would be solution too, but what if someone uses the uhci controller and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3 flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel. The best solution would be when we could use the CONFIG_USB_xxxx_HCD flag, but it
seems that some hardware has problems when we disable the handoff and let the BIOS
control the usb controller. Do you know any of this hardware?

Thanks

David Engraf

Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]

Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

Alan Stern

2007-08-02 14:32 UTC #8 lore raw

Quoted 10 lines · David Engraf

This would be solution too, but what if someone uses the uhci controller and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3 flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel. The best solution would be when we could use the CONFIG_USB_xxxx_HCD flag, but it
seems that some hardware has problems when we disable the handoff and let the BIOS
control the usb controller. Do you know any of this hardware?

The email messages are hidden in the depths of the linux-usb-devel archives. Maybe you can find them by checking the Git history for drivers/usb/host/pci-quirks.c, finding the dates for patches that affected the handoff code, and then searching through the archives near those dates.

IIRC the problems arose on some MIPS machines. And I don't think the problem involved letting the firmware manage the USB controller; I think the problem came when the controller driver tried to do the handoff later on.

Alan Stern

Greg KH

2007-08-02 16:41 UTC #9 lore raw

Quoted 19 lines · Alan Stern

Quoted 10 lines · David Engraf
This would be solution too, but what if someone uses the uhci controller and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3 flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel. The best solution would be when we could use the CONFIG_USB_xxxx_HCD flag, but it
seems that some hardware has problems when we disable the handoff and let the BIOS
control the usb controller. Do you know any of this hardware?
The email messages are hidden in the depths of the linux-usb-devel archives. Maybe you can find them by checking the Git history for drivers/usb/host/pci-quirks.c, finding the dates for patches that affected the handoff code, and then searching through the archives near those dates.

Quoted 4 lines

IIRC the problems arose on some MIPS machines. And I don't think the problem involved letting the firmware manage the USB controller; I think the problem came when the controller driver tried to do the handoff later on.

It wasn't just MIPS. IBM has a very popular blade system that has huge issues with this, and I think there are some other IBM systems based on the same BIOS that also do bad things if we don't grab the USB controller away from the BIOS as soon as possible (nasty interrupt and other messes happen...)

thanks,

greg k-h

David Engraf

author

2007-08-03 06:54 UTC #10 lore raw

Quoted 34 lines · Greg KH

Quoted 20 lines · Alan Stern
Quoted 11 lines · David Engraf
This would be solution too, but what if someone uses the uhci controller and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3 flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel. The best solution would be when we could use the CONFIG_USB_xxxx_HCD flag, but it
seems that some hardware has problems when we disable the handoff and let the BIOS
control the usb controller. Do you know any of this hardware?
The email messages are hidden in the depths of the linux-usb-devel archives. Maybe you can find them by checking the Git history for drivers/usb/host/pci-quirks.c, finding the dates for patches that affected the handoff code, and then searching through the archives near those dates.
Quoted 5 lines
IIRC the problems arose on some MIPS machines. And I don't think the problem involved letting the firmware manage the USB controller; I think the problem came when the controller driver tried to do the handoff later on.
It wasn't just MIPS. IBM has a very popular blade system that has huge issues with this, and I think there are some other IBM systems based on the same BIOS that also do bad things if we don't grab the USB controller away from the BIOS as soon as possible (nasty interrupt and other messes happen...)

Quoted 4 lines

thanks,
greg k-h

So we have hardware which has problems when we are not doing the handoff, and hardware which has
problems when we are doing the handoff...
What is the best way to solve the problem? Maybe a kernel parameter, a config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as the hardware has this bugs.

Thanks

David Engraf

Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel: +49 6131 6305 0
Fax: +49 6131 6305 40
Email: [email protected]

Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

Alan Stern

2007-08-03 15:03 UTC #11 lore raw

Quoted 3 lines · David Engraf

So we have hardware which has problems when we are not doing the handoff, and hardware which has
problems when we are doing the handoff...

What hardware has problems when we do the handoff? Your system and mine experience a delay, but it doesn't break anything.

Quoted 5 lines

What is the best way to solve the problem? Maybe a kernel parameter, a config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as the hardware has this bugs.

If we really need it, I say we should use a Kconfig flag.

Alan Stern

David Engraf

author

2007-08-07 08:48 UTC #12 lore raw

You said your Intel board has also problems with the handoff. Could you try the follwing patch, because the EHCI documentation says that the OS must set the EHCI_USBLEGSUP_OS bit and then wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never uses the EHCI_USBLEGSUP_OS flag at the moment.
On my system there is no change, but maybe this patch works on your system.

Thanks
David Engraf

linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c

--- drivers/usb/host/pci-quirks_orig.c 2007-07-10 20:56:30.000000000
+0200
+++ drivers/usb/host/pci-quirks.c 2007-08-07 10:38:33.000000000 +0200
@@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_

                  * handoff..
                  */
                 pci_write_config_byte(pdev, offset + 3, 1);
+
+                pci_write_config_byte(pdev, offset, cap |
EHCI_USBLEGSUP_OS);
             }
 
             /* if boot firmware now owns EHCI, spin till

Quoted 24 lines · Alan Stern

Quoted 4 lines · David Engraf
So we have hardware which has problems when we are not doing the handoff, and hardware which has
problems when we are doing the handoff...
What hardware has problems when we do the handoff? Your system and mine experience a delay, but it doesn't break anything.
Quoted 6 lines
What is the best way to solve the problem? Maybe a kernel parameter, a config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as the hardware has this bugs.
If we really need it, I say we should use a Kconfig flag.
Alan Stern

Alan Stern

2007-08-07 14:37 UTC #13 lore raw

Quoted 5 lines · David Engraf

You said your Intel board has also problems with the handoff. Could you try the follwing patch, because the EHCI documentation says that the OS must set the EHCI_USBLEGSUP_OS bit and then wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never uses the EHCI_USBLEGSUP_OS flag at the moment.

Yes it does. Maybe not by that name, but it does set the bit.

Quoted 14 lines

On my system there is no change, but maybe this patch works on your system.
Thanks
David Engraf
linux-2.6.22.1
diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c 2007-07-10 20:56:30.000000000
+0200
+++ drivers/usb/host/pci-quirks.c 2007-08-07 10:38:33.000000000 +0200

Review static void __devinit quirk_usb_disable_ · line 273

Quoted 6 lines

(quoted diff) +2 -0

@@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_
                  * handoff..
                  */
                 pci_write_config_byte(pdev, offset + 3, 1);
+
+                pci_write_config_byte(pdev, offset, cap |
 EHCI_USBLEGSUP_OS);

This patch is definitely wrong (besides being line-wrapped). Note that EHCI_USBLEGSUP_OS is equal to (1 << 24) -- it makes no sense to use it as an argument for a byte-sized write. Also note that the two low-order bytes in the USBLEGSUP register are read-only; you shouldn't try to write them at all.

It looks like you are simply attempting to do what the previous line of code already does.

Alan Stern

Grant Grundler

2007-08-03 22:25 UTC #14 lore raw

In reply to Greg KH

On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote:
...

Quoted 5 lines

It wasn't just MIPS. IBM has a very popular blade system that has huge issues with this, and I think there are some other IBM systems based on the same BIOS that also do bad things if we don't grab the USB controller away from the BIOS as soon as possible (nasty interrupt and other messes happen...)

PA-RISC has the same problem with USB. We can't reprogram the IOMMU windows at boot time unless the USB controller is forcefully stopped from doing DMA. "BIOS" leaves the USB DMA enabled to avoid loosing activity between polls for input.

PA-RISC solves this by calling back into the "BIOS" (aka PDC) to cleanly stop all possible DMA devices. Other arches probably don't have this luxury.

grant