[PATCH] USB:xhci: fix port switching on PantherPoint

[PATCH] USB:xhci: fix port switching on PantherPoint

[Oliver Neukum]

>From be9bdcf88b2974cfe95c1afea327b46135b65391 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver@neukum.org>
Date: Fri, 3 Feb 2012 12:01:12 +0100
Subject: [PATCH] USB:xhci: fix port switching on PantherPoint

The quirks of XHCI were called to early so that the
PCI device hadn't been enabled and the quirk handler bailed out.
The fix is to call it later.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
---
 drivers/usb/host/pci-quirks.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index caf8742..b49e3d0 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -873,7 +873,12 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
 		quirk_usb_handoff_ohci(pdev);
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
 		quirk_usb_disable_ehci(pdev);
-	else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
-		quirk_usb_handoff_xhci(pdev);
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
+
+static void __devinit quirk_xhci_early_handoff(struct pci_dev *pdev)
+{
+	 if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
+                quirk_usb_handoff_xhci(pdev);
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, quirk_xhci_early_handoff);
-- 
1.7.1

Re: [PATCH] USB:xhci: fix port switching on PantherPoint

[Alan Stern]

On Fri, 3 Feb 2012, Oliver Neukum wrote:

> From be9bdcf88b2974cfe95c1afea327b46135b65391 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.org>
> Date: Fri, 3 Feb 2012 12:01:12 +0100
> Subject: [PATCH] USB:xhci: fix port switching on PantherPoint
> 
> The quirks of XHCI were called to early so that the
> PCI device hadn't been enabled and the quirk handler bailed out.
> The fix is to call it later.

I don't understand.  How can PCI_FIXUP_FINAL be too late?  And if it 
is, why do all the other BIOS-handover routines work okay?

Alan Stern

Re: [PATCH] USB:xhci: fix port switching on PantherPoint

[Oliver Neukum]

Am Freitag, 3. Februar 2012, 16:16:58 schrieb Alan Stern:
> On Fri, 3 Feb 2012, Oliver Neukum wrote:
> 
> > From be9bdcf88b2974cfe95c1afea327b46135b65391 Mon Sep 17 00:00:00 2001
> > From: Oliver Neukum <oliver@neukum.org>
> > Date: Fri, 3 Feb 2012 12:01:12 +0100
> > Subject: [PATCH] USB:xhci: fix port switching on PantherPoint
> > 
> > The quirks of XHCI were called to early so that the
> > PCI device hadn't been enabled and the quirk handler bailed out.
> > The fix is to call it later.
> 
> I don't understand.  How can PCI_FIXUP_FINAL be too late?  And if it 
> is, why do all the other BIOS-handover routines work okay?

I don't understand it either. I can only report experimental findings.

	Regards
		Oliver

Re: [PATCH] USB:xhci: fix port switching on PantherPoint

[Sarah Sharp]

On Fri, Feb 03, 2012 at 12:22:43PM +0100, Oliver Neukum wrote:
> From be9bdcf88b2974cfe95c1afea327b46135b65391 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.org>
> Date: Fri, 3 Feb 2012 12:01:12 +0100
> Subject: [PATCH] USB:xhci: fix port switching on PantherPoint
> 
> The quirks of XHCI were called to early so that the
> PCI device hadn't been enabled and the quirk handler bailed out.
> The fix is to call it later.

Are the PCI fixups called before any PCI probe function?  I think this
patch is fine, but if the moved function now runs after the EHCI probe,
the EHCI host may notice disconnects from the ports being switched over
to xHCI.

Sarah Sharp

> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> ---
>  drivers/usb/host/pci-quirks.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index caf8742..b49e3d0 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -873,7 +873,12 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
>  		quirk_usb_handoff_ohci(pdev);
>  	else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
>  		quirk_usb_disable_ehci(pdev);
> -	else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
> -		quirk_usb_handoff_xhci(pdev);
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
> +
> +static void __devinit quirk_xhci_early_handoff(struct pci_dev *pdev)
> +{
> +	 if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
> +                quirk_usb_handoff_xhci(pdev);
> +}
> +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, quirk_xhci_early_handoff);
> -- 
> 1.7.1
> 

[RFC] xhci: Fix BIOS handoff failure on some Intel systems.

[Sarah Sharp]

On some systems with an Intel Panther Point xHCI host controller, the
BIOS disables the xHCI PCI device during boot, and switches the xHCI
ports over to EHCI.  This allows the BIOS to access USB devices without
having xHCI support.

The downside is that the xHCI BIOS handoff mechanism will fail because
memory mapped I/O is not enabled for the disabled PCI device.  Make the
xHCI quirk handler call pci_enable_device() to re-enable MMIO, and call
pci_disable_device() once it's done with the BIOS handoff.  This will
balance the ref counts in the PCI core.  When the xHCI PCI probe is
called, usb_hcd_pci_probe() will call pci_enable_device() again.

Also add some debugging to the xHCI quirk failure paths, so we can pin
point the problem when a user says their xHCI PCI quirk function fails.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
---

Hi Oliver,

What about this approach instead?  This means the PCI quirk sequence
doesn't change, and the xHCI ports are still switched over before the
EHCI PCI probe starts.  With your original patch, the ports could be
switched over after the EHCI driver has already started to enumerate
devices.

Can you test and make sure this fixes the issue on your test systems?

Sarah Sharp

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

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ac53a66..ff31f69 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -786,13 +786,28 @@ static void __devinit quirk_usb_handoff_xhci(struct pci_dev *pdev)
 	u32 val;
 	int timeout;
 
-	if (!mmio_resource_enabled(pdev, 0))
+	/* Some BIOS manufacturers disable the Intel Panther Point xHCI PCI
+	 * device during boot and use the Panther Point EHCI host instead.
+	 * We attempt to re-enable it in order to have memory mapped I/O.
+	 */
+	if (pci_enable_device(pdev) < 0) {
+		dev_warn(&pdev->dev, "Can't enable PCI device, "
+				"xHCI BIOS handoff failed.\n");
 		return;
+	}
+	if (!mmio_resource_enabled(pdev, 0)) {
+		dev_warn(&pdev->dev, "PCI MMIO not enabled, "
+				"xHCI BIOS handoff failed.\n");
+		goto disable_pci;
+	}
 
 	base = ioremap_nocache(pci_resource_start(pdev, 0),
 				pci_resource_len(pdev, 0));
-	if (base == NULL)
-		return;
+	if (base == NULL) {
+		dev_warn(&pdev->dev, "PCI register memory map failed, "
+				"xHCI BIOS handoff failed.\n");
+		goto disable_pci;
+	}
 
 	/*
 	 * Find the Legacy Support Capability register -
@@ -863,6 +878,8 @@ hc_init:
 	}
 
 	iounmap(base);
+disable_pci:
+	pci_disable_device(pdev);
 }
 
 static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
-- 
1.7.9

Re: [RFC] xhci: Fix BIOS handoff failure on some Intel systems.

[Oliver Neukum]

Am Mittwoch, 8. Februar 2012, 00:31:18 schrieb Sarah Sharp:
> The downside is that the xHCI BIOS handoff mechanism will fail because
> memory mapped I/O is not enabled for the disabled PCI device.  Make the
> xHCI quirk handler call pci_enable_device() to re-enable MMIO, and call
> pci_disable_device() once it's done with the BIOS handoff.  This will
> balance the ref counts in the PCI core.  When the xHCI PCI probe is
> called, usb_hcd_pci_probe() will call pci_enable_device() again.
> 
> Also add some debugging to the xHCI quirk failure paths, so we can pin
> point the problem when a user says their xHCI PCI quirk function fails.
> 
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> ---
> 
> Hi Oliver,
> 
> What about this approach instead?  This means the PCI quirk sequence
> doesn't change, and the xHCI ports are still switched over before the
> EHCI PCI probe starts.  With your original patch, the ports could be
> switched over after the EHCI driver has already started to enumerate
> devices.
> 
> Can you test and make sure this fixes the issue on your test systems?

I've tested it and it works. Are you sure it is safe to enable a PCI device
at that point? If so, your patch is better than mine.

	Regards
		Oliver

Re: [RFC] xhci: Fix BIOS handoff failure on some Intel systems.

[Sarah Sharp]

On Wed, Feb 08, 2012 at 04:11:37PM +0100, Oliver Neukum wrote:
> Am Mittwoch, 8. Februar 2012, 00:31:18 schrieb Sarah Sharp:
> > The downside is that the xHCI BIOS handoff mechanism will fail because
> > memory mapped I/O is not enabled for the disabled PCI device.  Make the
> > xHCI quirk handler call pci_enable_device() to re-enable MMIO, and call
> > pci_disable_device() once it's done with the BIOS handoff.  This will
> > balance the ref counts in the PCI core.  When the xHCI PCI probe is
> > called, usb_hcd_pci_probe() will call pci_enable_device() again.
> > 
> > Also add some debugging to the xHCI quirk failure paths, so we can pin
> > point the problem when a user says their xHCI PCI quirk function fails.
> > 
> > Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> > ---
> > 
> > Hi Oliver,
> > 
> > What about this approach instead?  This means the PCI quirk sequence
> > doesn't change, and the xHCI ports are still switched over before the
> > EHCI PCI probe starts.  With your original patch, the ports could be
> > switched over after the EHCI driver has already started to enumerate
> > devices.
> > 
> > Can you test and make sure this fixes the issue on your test systems?
> 
> I've tested it and it works. Are you sure it is safe to enable a PCI device
> at that point? If so, your patch is better than mine.

Jesse Barnes told me it's fine over IRC, so I'm just going to send this
off, with your Tested-by line.

Thanks,
Sarah Sharp

Re: [RFC] xhci: Fix BIOS handoff failure on some Intel systems.

[Oliver Neukum]

Am Mittwoch, 8. Februar 2012, 22:48:51 schrieb Sarah Sharp:
> > > Can you test and make sure this fixes the issue on your test systems?
> > 
> > I've tested it and it works. Are you sure it is safe to enable a PCI device
> > at that point? If so, your patch is better than mine.
> 
> Jesse Barnes told me it's fine over IRC, so I'm just going to send this
> off, with your Tested-by line.

Very well, but then consequently you should do it for all HCIs.

	Regards
		Oliver

Re: [RFC] xhci: Fix BIOS handoff failure on some Intel systems.

[Sarah Sharp]

On Thu, Feb 09, 2012 at 09:56:22AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 8. Februar 2012, 22:48:51 schrieb Sarah Sharp:
> > > > Can you test and make sure this fixes the issue on your test systems?
> > > 
> > > I've tested it and it works. Are you sure it is safe to enable a PCI device
> > > at that point? If so, your patch is better than mine.
> > 
> > Jesse Barnes told me it's fine over IRC, so I'm just going to send this
> > off, with your Tested-by line.
> 
> Very well, but then consequently you should do it for all HCIs.

Ok, sure. :)  I'll send the patch out later today.

Sarah Sharp

[RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Sarah Sharp]

On some systems with an Intel Panther Point xHCI host controller, the
BIOS disables the xHCI PCI device during boot, and switches the xHCI
ports over to EHCI.  This allows the BIOS to access USB devices without
having xHCI support.

The downside is that the xHCI BIOS handoff mechanism will fail because
memory mapped I/O is not enabled for the disabled PCI device.
Jesse Barnes says this is expected behavior.  The PCI core will enable
BARs before quirks run, but it will leave it in an undefined state, and
it may not have memory mapped I/O enabled.

Make the generic USB quirk handler call pci_enable_device() to re-enable
MMIO, and call pci_disable_device() once the host-specific BIOS handoff
is finished.  This will balance the ref counts in the PCI core.  When
the PCI probe function is called, usb_hcd_pci_probe() will call
pci_enable_device() again.

This should be backported to kernels as old as 2.6.32.  That was the
first kernel with xHCI support, and no one has complained about BIOS
handoffs failing due to memory mapped I/O being disabled on other hosts
(EHCI, UHCI, or OHCI).

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
---
 drivers/usb/host/pci-quirks.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ac53a66..7732d69 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -872,7 +872,17 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
 	 */
 	if (pdev->vendor == 0x184e)	/* vendor Netlogic */
 		return;
+	if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
+			pdev->class != PCI_CLASS_SERIAL_USB_XHCI)
+		return;
 
+	if (pci_enable_device(pdev) < 0) {
+		dev_warn(&pdev->dev, "Can't enable PCI device, "
+				"BIOS handoff failed.\n");
+		return;
+	}
 	if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
 		quirk_usb_handoff_uhci(pdev);
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
@@ -881,5 +891,6 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
 		quirk_usb_disable_ehci(pdev);
 	else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
 		quirk_usb_handoff_xhci(pdev);
+	pci_disable_device(pdev);
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
-- 
1.7.9

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Sarah Sharp]

Hi Oliver,

Have you gotten a chance to test this patch on your test system?  I'd
like to get it out, but I want to make sure it fixes your problem.

Thanks,
Sarah Sharp

On Thu, Feb 09, 2012 at 12:13:54PM -0800, Sarah Sharp wrote:
> On some systems with an Intel Panther Point xHCI host controller, the
> BIOS disables the xHCI PCI device during boot, and switches the xHCI
> ports over to EHCI.  This allows the BIOS to access USB devices without
> having xHCI support.
> 
> The downside is that the xHCI BIOS handoff mechanism will fail because
> memory mapped I/O is not enabled for the disabled PCI device.
> Jesse Barnes says this is expected behavior.  The PCI core will enable
> BARs before quirks run, but it will leave it in an undefined state, and
> it may not have memory mapped I/O enabled.
> 
> Make the generic USB quirk handler call pci_enable_device() to re-enable
> MMIO, and call pci_disable_device() once the host-specific BIOS handoff
> is finished.  This will balance the ref counts in the PCI core.  When
> the PCI probe function is called, usb_hcd_pci_probe() will call
> pci_enable_device() again.
> 
> This should be backported to kernels as old as 2.6.32.  That was the
> first kernel with xHCI support, and no one has complained about BIOS
> handoffs failing due to memory mapped I/O being disabled on other hosts
> (EHCI, UHCI, or OHCI).
> 
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Cc: Oliver Neukum <oneukum@suse.de>
> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: stable@kernel.org
> ---
>  drivers/usb/host/pci-quirks.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index ac53a66..7732d69 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -872,7 +872,17 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
>  	 */
>  	if (pdev->vendor == 0x184e)	/* vendor Netlogic */
>  		return;
> +	if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
> +			pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
> +			pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
> +			pdev->class != PCI_CLASS_SERIAL_USB_XHCI)
> +		return;
>  
> +	if (pci_enable_device(pdev) < 0) {
> +		dev_warn(&pdev->dev, "Can't enable PCI device, "
> +				"BIOS handoff failed.\n");
> +		return;
> +	}
>  	if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
>  		quirk_usb_handoff_uhci(pdev);
>  	else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
> @@ -881,5 +891,6 @@ static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
>  		quirk_usb_disable_ehci(pdev);
>  	else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
>  		quirk_usb_handoff_xhci(pdev);
> +	pci_disable_device(pdev);
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
> -- 
> 1.7.9
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Oliver Neukum]

Am Dienstag, 14. Februar 2012, 21:33:11 schrieb Sarah Sharp:
> Hi Oliver,
> 
> Have you gotten a chance to test this patch on your test system?  I'd
> like to get it out, but I want to make sure it fixes your problem.

Did I forget to answer? Anyway, yes it works. However it seems a bad idea
to me to unconditionally disable the device, on second thought.

	Regards
		Oliver

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Sarah Sharp]

On Wed, Feb 15, 2012 at 09:48:07AM +0100, Oliver Neukum wrote:
> Am Dienstag, 14. Februar 2012, 21:33:11 schrieb Sarah Sharp:
> > Hi Oliver,
> > 
> > Have you gotten a chance to test this patch on your test system?  I'd
> > like to get it out, but I want to make sure it fixes your problem.
> 
> Did I forget to answer? Anyway, yes it works. However it seems a bad idea
> to me to unconditionally disable the device, on second thought.

Why?  The USB core will re-enable the device during the PCI probe, so I
don't see the harm in it.  What else might be accessing the PCI device?
Obviously the PCI core didn't care if the device was enabled or not
pre-probe, or it would have enabled the PCI device itself.

Sarah Sharp

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Oliver Neukum]

Am Mittwoch, 15. Februar 2012, 17:38:07 schrieb Sarah Sharp:
> On Wed, Feb 15, 2012 at 09:48:07AM +0100, Oliver Neukum wrote:
> > Am Dienstag, 14. Februar 2012, 21:33:11 schrieb Sarah Sharp:
> > > Hi Oliver,
> > > 
> > > Have you gotten a chance to test this patch on your test system?  I'd
> > > like to get it out, but I want to make sure it fixes your problem.
> > 
> > Did I forget to answer? Anyway, yes it works. However it seems a bad idea
> > to me to unconditionally disable the device, on second thought.
> 
> Why?  The USB core will re-enable the device during the PCI probe, so I

Provided the device is probed. Typically of course it wii be, but
we cannot assume that the xhci driver will always be loaded.

> don't see the harm in it.  What else might be accessing the PCI device?
> Obviously the PCI core didn't care if the device was enabled or not
> pre-probe, or it would have enabled the PCI device itself.

The BIOS might touch it. Are you really willing to say that there won't
be BIOSes that assume that what they enabled must stay enabled?

	Regards
		Oliver

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Sarah Sharp]

On Thu, Feb 16, 2012 at 11:15:48AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 15. Februar 2012, 17:38:07 schrieb Sarah Sharp:
> > On Wed, Feb 15, 2012 at 09:48:07AM +0100, Oliver Neukum wrote:
> > > Am Dienstag, 14. Februar 2012, 21:33:11 schrieb Sarah Sharp:
> > > > Hi Oliver,
> > > > 
> > > > Have you gotten a chance to test this patch on your test system?  I'd
> > > > like to get it out, but I want to make sure it fixes your problem.
> > > 
> > > Did I forget to answer? Anyway, yes it works. However it seems a bad idea
> > > to me to unconditionally disable the device, on second thought.
> > 
> > Why?  The USB core will re-enable the device during the PCI probe, so I
> 
> Provided the device is probed. Typically of course it wii be, but
> we cannot assume that the xhci driver will always be loaded.

Sure.  That's why I want to balance the enable/disable calls in the PCI
quirks handler.  If we don't disable the PCI device, and the driver
never gets loaded, then the PCI device will remain enabled.  I'm not
sure if that's a terrible thing, but it does mean the ref count never
goes to zero.

Jesse?

> > don't see the harm in it.  What else might be accessing the PCI device?
> > Obviously the PCI core didn't care if the device was enabled or not
> > pre-probe, or it would have enabled the PCI device itself.
> 
> The BIOS might touch it. Are you really willing to say that there won't
> be BIOSes that assume that what they enabled must stay enabled?

Once the xHCI PCI quirk handler runs, we've taken the host controller
away from the BIOS with the BIOS/OS semaphore handshake.  (If the BIOS
is smart enough to actually handle that.)  Any BIOS that touches the
xHCI host controller after that point is just broken.  There is only so
much we can do about the BIOS breakage. :)

Sarah Sharp

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Oliver Neukum]

Am Donnerstag, 16. Februar 2012, 15:33:21 schrieb Sarah Sharp:
> > The BIOS might touch it. Are you really willing to say that there won't
> > be BIOSes that assume that what they enabled must stay enabled?
> 
> Once the xHCI PCI quirk handler runs, we've taken the host controller
> away from the BIOS with the BIOS/OS semaphore handshake.  (If the BIOS
> is smart enough to actually handle that.)  Any BIOS that touches the
> xHCI host controller after that point is just broken.  There is only so
> much we can do about the BIOS breakage. :)

What about S3 when the BIOS takes control?

	Regards
		Oliver

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Sarah Sharp]

On Thu, Feb 16, 2012 at 03:48:53PM +0100, Oliver Neukum wrote:
> Am Donnerstag, 16. Februar 2012, 15:33:21 schrieb Sarah Sharp:
> > > The BIOS might touch it. Are you really willing to say that there won't
> > > be BIOSes that assume that what they enabled must stay enabled?
> > 
> > Once the xHCI PCI quirk handler runs, we've taken the host controller
> > away from the BIOS with the BIOS/OS semaphore handshake.  (If the BIOS
> > is smart enough to actually handle that.)  Any BIOS that touches the
> > xHCI host controller after that point is just broken.  There is only so
> > much we can do about the BIOS breakage. :)
> 
> What about S3 when the BIOS takes control?

If that was a problem, we would see BIOS issues during S3 with the
current code when a host controller driver wasn't loaded before
suspend.  In fact, I think several distros used to unload the USB
drivers when the user selected suspend from the menu.

When the driver is unloaded, usb_hcd_pci_remove() is called, which will
call pci_disable_device().  If the ref counts were balanced (and I
believe they are), then the PCI device would have been disabled before
S3 for distros that unloaded the USB drivers on suspend.  So the BIOS
would have seen a disabled PCI device for these distros, just like it
would with my patch if the driver never got loaded.

I don't think this is an issue.

Sarah Sharp

Re: [RFC v2] USB: Fix handoff when BIOS disables host PCI device.

[Oliver Neukum]

Am Donnerstag, 16. Februar 2012, 17:54:24 schrieb Sarah Sharp:
> When the driver is unloaded, usb_hcd_pci_remove() is called, which will
> call pci_disable_device().  If the ref counts were balanced (and I
> believe they are), then the PCI device would have been disabled before
> S3 for distros that unloaded the USB drivers on suspend.  So the BIOS
> would have seen a disabled PCI device for these distros, just like it
> would with my patch if the driver never got loaded.
> 
> I don't think this is an issue.

OK, I am convinced.

	Regards
		Oliver