2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* (C) Copyright David Brownell 2000-2002
|
2008-01-31 07:21:33 +08:00
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
|
* Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
|
* option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
|
|
|
|
|
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
|
* for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/pci.h>
|
2005-11-24 07:45:42 +08:00
|
|
|
#include <linux/usb.h>
|
2010-04-25 05:21:52 +08:00
|
|
|
#include <linux/usb/hcd.h>
|
2005-11-24 07:45:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/io.h>
|
|
|
|
|
#include <asm/irq.h>
|
2005-11-24 07:45:42 +08:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_PPC_PMAC
|
|
|
|
|
#include <asm/machdep.h>
|
|
|
|
|
#include <asm/pmac_feature.h>
|
|
|
|
|
#include <asm/pci-bridge.h>
|
|
|
|
|
#include <asm/prom.h>
|
|
|
|
|
#endif
|
2005-09-23 13:38:16 +08:00
|
|
|
|
|
|
|
|
#include "usb.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
2005-04-19 08:39:22 +08:00
|
|
|
/* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/*
|
|
|
|
|
* Coordinate handoffs between EHCI and companion controllers
|
|
|
|
|
* during EHCI probing and system resume.
|
2010-02-12 19:21:11 +08:00
|
|
|
*/
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
static DECLARE_RWSEM(companions_rwsem);
|
2010-02-12 19:21:11 +08:00
|
|
|
|
|
|
|
|
#define CL_UHCI PCI_CLASS_SERIAL_USB_UHCI
|
|
|
|
|
#define CL_OHCI PCI_CLASS_SERIAL_USB_OHCI
|
|
|
|
|
#define CL_EHCI PCI_CLASS_SERIAL_USB_EHCI
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
static inline int is_ohci_or_uhci(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
return pdev->class == CL_OHCI || pdev->class == CL_UHCI;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
typedef void (*companion_fn)(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd);
|
2010-02-12 19:21:11 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/* Iterate over PCI devices in the same slot as pdev and call fn for each */
|
|
|
|
|
static void for_each_companion(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
companion_fn fn)
|
2010-02-12 19:21:11 +08:00
|
|
|
{
|
|
|
|
|
struct pci_dev *companion;
|
|
|
|
|
struct usb_hcd *companion_hcd;
|
|
|
|
|
unsigned int slot = PCI_SLOT(pdev->devfn);
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/*
|
|
|
|
|
* Iterate through other PCI functions in the same slot.
|
|
|
|
|
* If the function's drvdata isn't set then it isn't bound to
|
|
|
|
|
* a USB host controller driver, so skip it.
|
2010-02-12 19:21:11 +08:00
|
|
|
*/
|
|
|
|
|
companion = NULL;
|
2010-07-04 00:04:47 +08:00
|
|
|
for_each_pci_dev(companion) {
|
2010-02-12 19:21:11 +08:00
|
|
|
if (companion->bus != pdev->bus ||
|
|
|
|
|
PCI_SLOT(companion->devfn) != slot)
|
|
|
|
|
continue;
|
|
|
|
|
companion_hcd = pci_get_drvdata(companion);
|
2014-04-15 01:48:47 +08:00
|
|
|
if (!companion_hcd || !companion_hcd->self.root_hub)
|
2010-02-12 19:21:11 +08:00
|
|
|
continue;
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
fn(pdev, hcd, companion, companion_hcd);
|
2010-02-12 19:21:11 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/*
|
|
|
|
|
* We're about to add an EHCI controller, which will unceremoniously grab
|
|
|
|
|
* all the port connections away from its companions. To prevent annoying
|
|
|
|
|
* error messages, lock the companion's root hub and gracefully unconfigure
|
|
|
|
|
* it beforehand. Leave it locked until the EHCI controller is all set.
|
|
|
|
|
*/
|
|
|
|
|
static void ehci_pre_add(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd)
|
2010-02-12 19:21:11 +08:00
|
|
|
{
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
struct usb_device *udev;
|
|
|
|
|
|
|
|
|
|
if (is_ohci_or_uhci(companion)) {
|
|
|
|
|
udev = companion_hcd->self.root_hub;
|
|
|
|
|
usb_lock_device(udev);
|
|
|
|
|
usb_set_configuration(udev, 0);
|
|
|
|
|
}
|
2010-02-12 19:21:11 +08:00
|
|
|
}
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/*
|
|
|
|
|
* Adding the EHCI controller has either succeeded or failed. Set the
|
|
|
|
|
* companion pointer accordingly, and in either case, reconfigure and
|
|
|
|
|
* unlock the root hub.
|
|
|
|
|
*/
|
|
|
|
|
static void ehci_post_add(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd)
|
2010-02-12 19:21:11 +08:00
|
|
|
{
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
struct usb_device *udev;
|
2010-02-12 19:21:11 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
if (is_ohci_or_uhci(companion)) {
|
|
|
|
|
if (dev_get_drvdata(&pdev->dev)) { /* Succeeded */
|
|
|
|
|
dev_dbg(&pdev->dev, "HS companion for %s\n",
|
|
|
|
|
dev_name(&companion->dev));
|
|
|
|
|
companion_hcd->self.hs_companion = &hcd->self;
|
|
|
|
|
}
|
|
|
|
|
udev = companion_hcd->self.root_hub;
|
|
|
|
|
usb_set_configuration(udev, 1);
|
|
|
|
|
usb_unlock_device(udev);
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-02-12 19:21:11 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/*
|
|
|
|
|
* We just added a non-EHCI controller. Find the EHCI controller to
|
|
|
|
|
* which it is a companion, and store a pointer to the bus structure.
|
|
|
|
|
*/
|
|
|
|
|
static void non_ehci_add(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd)
|
|
|
|
|
{
|
|
|
|
|
if (is_ohci_or_uhci(pdev) && companion->class == CL_EHCI) {
|
|
|
|
|
dev_dbg(&pdev->dev, "FS/LS companion for %s\n",
|
|
|
|
|
dev_name(&companion->dev));
|
|
|
|
|
hcd->self.hs_companion = &companion_hcd->self;
|
|
|
|
|
}
|
2010-02-12 19:21:11 +08:00
|
|
|
}
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/* We are removing an EHCI controller. Clear the companions' pointers. */
|
|
|
|
|
static void ehci_remove(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd)
|
2010-02-12 19:21:11 +08:00
|
|
|
{
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
if (is_ohci_or_uhci(companion))
|
|
|
|
|
companion_hcd->self.hs_companion = NULL;
|
2010-02-12 19:21:11 +08:00
|
|
|
}
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
#ifdef CONFIG_PM
|
2010-02-12 19:21:11 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/* An EHCI controller must wait for its companions before resuming. */
|
|
|
|
|
static void ehci_wait_for_companions(struct pci_dev *pdev, struct usb_hcd *hcd,
|
|
|
|
|
struct pci_dev *companion, struct usb_hcd *companion_hcd)
|
|
|
|
|
{
|
|
|
|
|
if (is_ohci_or_uhci(companion))
|
|
|
|
|
device_pm_wait_for_dev(&pdev->dev, &companion->dev);
|
|
|
|
|
}
|
2010-02-12 19:21:11 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
#endif /* CONFIG_PM */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
/* configure so an HC device and id are always provided */
|
|
|
|
|
/* always called with process context; sleeping is OK */
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* usb_hcd_pci_probe - initialize PCI-based HCDs
|
|
|
|
|
* @dev: USB Host Controller being probed
|
|
|
|
|
* @id: pci hotplug id connecting controller to HCD framework
|
|
|
|
|
* Context: !in_interrupt()
|
|
|
|
|
*
|
|
|
|
|
* Allocates basic PCI resources for this USB host controller, and
|
|
|
|
|
* then invokes the start() method for the HCD associated with it
|
|
|
|
|
* through the hotplug entry's driver_data.
|
|
|
|
|
*
|
|
|
|
|
* Store this function in the HCD's struct pci_driver as probe().
|
2013-08-03 02:10:04 +08:00
|
|
|
*
|
|
|
|
|
* Return: 0 if successful.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-01-31 07:21:33 +08:00
|
|
|
int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
struct hc_driver *driver;
|
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
int retval;
|
2013-03-05 00:14:43 +08:00
|
|
|
int hcd_irq = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
if (usb_disabled())
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
if (!id)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
driver = (struct hc_driver *)id->driver_data;
|
|
|
|
|
if (!driver)
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
if (pci_enable_device(dev) < 0)
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENODEV;
|
2008-01-31 07:21:33 +08:00
|
|
|
|
2013-03-05 00:14:43 +08:00
|
|
|
/*
|
|
|
|
|
* The xHCI driver has its own irq management
|
|
|
|
|
* make sure irq setup is not touched for xhci in generic hcd code
|
2012-02-14 08:25:57 +08:00
|
|
|
*/
|
2013-03-05 00:14:43 +08:00
|
|
|
if ((driver->flags & HCD_MASK) != HCD_USB3) {
|
|
|
|
|
if (!dev->irq) {
|
|
|
|
|
dev_err(&dev->dev,
|
|
|
|
|
"Found HC with no IRQ. Check BIOS/PCI %s setup!\n",
|
|
|
|
|
pci_name(dev));
|
|
|
|
|
retval = -ENODEV;
|
|
|
|
|
goto disable_pci;
|
|
|
|
|
}
|
|
|
|
|
hcd_irq = dev->irq;
|
2008-01-31 07:21:33 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
hcd = usb_create_hcd(driver, &dev->dev, pci_name(dev));
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!hcd) {
|
|
|
|
|
retval = -ENOMEM;
|
2010-10-16 01:33:48 +08:00
|
|
|
goto disable_pci;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2013-09-16 23:47:28 +08:00
|
|
|
hcd->amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev) &&
|
|
|
|
|
driver->flags & (HCD_USB11 | HCD_USB3)) ? 1 : 0;
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
if (driver->flags & HCD_MEMORY) {
|
|
|
|
|
/* EHCI, OHCI */
|
|
|
|
|
hcd->rsrc_start = pci_resource_start(dev, 0);
|
|
|
|
|
hcd->rsrc_len = pci_resource_len(dev, 0);
|
|
|
|
|
if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len,
|
2005-04-17 06:20:36 +08:00
|
|
|
driver->description)) {
|
2008-01-31 07:21:33 +08:00
|
|
|
dev_dbg(&dev->dev, "controller already in use\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -EBUSY;
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
goto put_hcd;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2008-01-31 07:21:33 +08:00
|
|
|
hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (hcd->regs == NULL) {
|
2008-01-31 07:21:33 +08:00
|
|
|
dev_dbg(&dev->dev, "error mapping memory\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -EFAULT;
|
2010-10-16 01:33:48 +08:00
|
|
|
goto release_mem_region;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
} else {
|
|
|
|
|
/* UHCI */
|
2005-04-17 06:20:36 +08:00
|
|
|
int region;
|
|
|
|
|
|
|
|
|
|
for (region = 0; region < PCI_ROM_RESOURCE; region++) {
|
2008-01-31 07:21:33 +08:00
|
|
|
if (!(pci_resource_flags(dev, region) &
|
2005-04-17 06:20:36 +08:00
|
|
|
IORESOURCE_IO))
|
|
|
|
|
continue;
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
hcd->rsrc_start = pci_resource_start(dev, region);
|
|
|
|
|
hcd->rsrc_len = pci_resource_len(dev, region);
|
|
|
|
|
if (request_region(hcd->rsrc_start, hcd->rsrc_len,
|
2005-04-17 06:20:36 +08:00
|
|
|
driver->description))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (region == PCI_ROM_RESOURCE) {
|
2008-01-31 07:21:33 +08:00
|
|
|
dev_dbg(&dev->dev, "no i/o regions available\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
retval = -EBUSY;
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
goto put_hcd;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
pci_set_master(dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/* Note: dev_set_drvdata must be called while holding the rwsem */
|
|
|
|
|
if (dev->class == CL_EHCI) {
|
|
|
|
|
down_write(&companions_rwsem);
|
|
|
|
|
dev_set_drvdata(&dev->dev, hcd);
|
|
|
|
|
for_each_companion(dev, hcd, ehci_pre_add);
|
|
|
|
|
retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
|
|
|
|
|
if (retval != 0)
|
|
|
|
|
dev_set_drvdata(&dev->dev, NULL);
|
|
|
|
|
for_each_companion(dev, hcd, ehci_post_add);
|
|
|
|
|
up_write(&companions_rwsem);
|
|
|
|
|
} else {
|
|
|
|
|
down_read(&companions_rwsem);
|
|
|
|
|
dev_set_drvdata(&dev->dev, hcd);
|
|
|
|
|
retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
|
|
|
|
|
if (retval != 0)
|
|
|
|
|
dev_set_drvdata(&dev->dev, NULL);
|
|
|
|
|
else
|
|
|
|
|
for_each_companion(dev, hcd, non_ehci_add);
|
|
|
|
|
up_read(&companions_rwsem);
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval != 0)
|
2010-10-16 01:33:48 +08:00
|
|
|
goto unmap_registers;
|
2013-11-05 10:46:02 +08:00
|
|
|
device_wakeup_enable(hcd->self.controller);
|
2010-06-26 02:02:57 +08:00
|
|
|
|
|
|
|
|
if (pci_dev_run_wake(dev))
|
|
|
|
|
pm_runtime_put_noidle(&dev->dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
return retval;
|
|
|
|
|
|
2010-10-16 01:33:48 +08:00
|
|
|
unmap_registers:
|
2005-04-17 06:20:36 +08:00
|
|
|
if (driver->flags & HCD_MEMORY) {
|
2008-01-31 07:21:33 +08:00
|
|
|
iounmap(hcd->regs);
|
2010-10-16 01:33:48 +08:00
|
|
|
release_mem_region:
|
2008-01-31 07:21:33 +08:00
|
|
|
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else
|
2008-01-31 07:21:33 +08:00
|
|
|
release_region(hcd->rsrc_start, hcd->rsrc_len);
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
put_hcd:
|
2008-01-31 07:21:33 +08:00
|
|
|
usb_put_hcd(hcd);
|
2010-10-16 01:33:48 +08:00
|
|
|
disable_pci:
|
2008-01-31 07:21:33 +08:00
|
|
|
pci_disable_device(dev);
|
|
|
|
|
dev_err(&dev->dev, "init %s fail, %d\n", pci_name(dev), retval);
|
2005-04-17 06:20:36 +08:00
|
|
|
return retval;
|
2008-01-31 07:21:33 +08:00
|
|
|
}
|
2008-01-26 01:12:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_hcd_pci_probe);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/* may be called without controller electrically present */
|
|
|
|
|
/* may be called with controller, bus, and devices active */
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* usb_hcd_pci_remove - shutdown processing for PCI-based HCDs
|
|
|
|
|
* @dev: USB Host Controller being removed
|
|
|
|
|
* Context: !in_interrupt()
|
|
|
|
|
*
|
|
|
|
|
* Reverses the effect of usb_hcd_pci_probe(), first invoking
|
|
|
|
|
* the HCD's stop() method. It is always called from a thread
|
|
|
|
|
* context, normally "rmmod", "apmd", or something similar.
|
|
|
|
|
*
|
|
|
|
|
* Store this function in the HCD's struct pci_driver as remove().
|
|
|
|
|
*/
|
2008-01-31 07:21:33 +08:00
|
|
|
void usb_hcd_pci_remove(struct pci_dev *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
|
|
|
|
|
hcd = pci_get_drvdata(dev);
|
|
|
|
|
if (!hcd)
|
|
|
|
|
return;
|
|
|
|
|
|
2010-06-26 02:02:57 +08:00
|
|
|
if (pci_dev_run_wake(dev))
|
|
|
|
|
pm_runtime_get_noresume(&dev->dev);
|
|
|
|
|
|
2010-06-10 05:34:27 +08:00
|
|
|
/* Fake an interrupt request in order to give the driver a chance
|
|
|
|
|
* to test whether the controller hardware has been removed (e.g.,
|
|
|
|
|
* cardbus physical eject).
|
|
|
|
|
*/
|
|
|
|
|
local_irq_disable();
|
|
|
|
|
usb_hcd_irq(0, hcd);
|
|
|
|
|
local_irq_enable();
|
|
|
|
|
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
/* Note: dev_set_drvdata must be called while holding the rwsem */
|
|
|
|
|
if (dev->class == CL_EHCI) {
|
|
|
|
|
down_write(&companions_rwsem);
|
|
|
|
|
for_each_companion(dev, hcd, ehci_remove);
|
|
|
|
|
usb_remove_hcd(hcd);
|
|
|
|
|
dev_set_drvdata(&dev->dev, NULL);
|
|
|
|
|
up_write(&companions_rwsem);
|
|
|
|
|
} else {
|
|
|
|
|
/* Not EHCI; just clear the companion pointer */
|
|
|
|
|
down_read(&companions_rwsem);
|
|
|
|
|
hcd->self.hs_companion = NULL;
|
|
|
|
|
usb_remove_hcd(hcd);
|
|
|
|
|
dev_set_drvdata(&dev->dev, NULL);
|
|
|
|
|
up_read(&companions_rwsem);
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (hcd->driver->flags & HCD_MEMORY) {
|
2008-01-31 07:21:33 +08:00
|
|
|
iounmap(hcd->regs);
|
|
|
|
|
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2008-01-31 07:21:33 +08:00
|
|
|
release_region(hcd->rsrc_start, hcd->rsrc_len);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
|
2008-01-31 07:21:33 +08:00
|
|
|
usb_put_hcd(hcd);
|
2005-04-17 06:20:36 +08:00
|
|
|
pci_disable_device(dev);
|
|
|
|
|
}
|
2008-01-26 01:12:21 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usb_hcd_pci_remove);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/**
|
2009-04-28 01:33:24 +08:00
|
|
|
* usb_hcd_pci_shutdown - shutdown host controller
|
|
|
|
|
* @dev: USB Host Controller being shutdown
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-04-28 01:33:24 +08:00
|
|
|
void usb_hcd_pci_shutdown(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
|
|
|
|
|
hcd = pci_get_drvdata(dev);
|
|
|
|
|
if (!hcd)
|
|
|
|
|
return;
|
|
|
|
|
|
2010-06-26 02:02:57 +08:00
|
|
|
if (test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags) &&
|
2010-09-11 04:37:05 +08:00
|
|
|
hcd->driver->shutdown) {
|
2009-04-28 01:33:24 +08:00
|
|
|
hcd->driver->shutdown(hcd);
|
2014-07-21 10:17:44 +08:00
|
|
|
if (usb_hcd_is_primary_hcd(hcd) && hcd->irq > 0)
|
|
|
|
|
free_irq(hcd->irq, hcd);
|
2010-09-11 04:37:05 +08:00
|
|
|
pci_disable_device(dev);
|
|
|
|
|
}
|
2009-04-28 01:33:24 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(usb_hcd_pci_shutdown);
|
|
|
|
|
|
2011-02-11 07:06:54 +08:00
|
|
|
#ifdef CONFIG_PM
|
2009-04-28 01:33:24 +08:00
|
|
|
|
2010-06-26 02:01:49 +08:00
|
|
|
#ifdef CONFIG_PPC_PMAC
|
|
|
|
|
static void powermac_set_asic(struct pci_dev *pci_dev, int enable)
|
|
|
|
|
{
|
|
|
|
|
/* Enanble or disable ASIC clocks for USB */
|
|
|
|
|
if (machine_is(powermac)) {
|
|
|
|
|
struct device_node *of_node;
|
|
|
|
|
|
|
|
|
|
of_node = pci_device_to_OF_node(pci_dev);
|
|
|
|
|
if (of_node)
|
|
|
|
|
pmac_call_feature(PMAC_FTR_USB_ENABLE,
|
|
|
|
|
of_node, 0, enable);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
static inline void powermac_set_asic(struct pci_dev *pci_dev, int enable)
|
|
|
|
|
{}
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_PPC_PMAC */
|
|
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
static int check_root_hub_suspended(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
|
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
|
|
|
|
|
|
2011-03-08 00:11:52 +08:00
|
|
|
if (HCD_RH_RUNNING(hcd)) {
|
2009-04-28 01:33:24 +08:00
|
|
|
dev_warn(dev, "Root hub is not suspended\n");
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
if (hcd->shared_hcd) {
|
|
|
|
|
hcd = hcd->shared_hcd;
|
|
|
|
|
if (HCD_RH_RUNNING(hcd)) {
|
|
|
|
|
dev_warn(dev, "Secondary root hub is not suspended\n");
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-04-28 01:33:24 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-26 02:02:57 +08:00
|
|
|
static int suspend_common(struct device *dev, bool do_wakeup)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-04-28 01:33:24 +08:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
|
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
|
|
|
|
|
int retval;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2005-09-23 13:38:16 +08:00
|
|
|
/* Root hub suspend should have stopped all downstream traffic,
|
|
|
|
|
* and all bus master traffic. And done so for both the interface
|
|
|
|
|
* and the stub usb_device (which we check here). But maybe it
|
|
|
|
|
* didn't; writing sysfs power/state files ignores such rules...
|
|
|
|
|
*/
|
2009-04-28 01:33:24 +08:00
|
|
|
retval = check_root_hub_suspended(dev);
|
|
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
2008-12-18 04:06:03 +08:00
|
|
|
|
2011-03-08 00:11:52 +08:00
|
|
|
if (hcd->driver->pci_suspend && !HCD_DEAD(hcd)) {
|
2010-06-26 02:02:35 +08:00
|
|
|
/* Optimization: Don't suspend if a root-hub wakeup is
|
|
|
|
|
* pending and it would cause the HCD to wake up anyway.
|
|
|
|
|
*/
|
|
|
|
|
if (do_wakeup && HCD_WAKEUP_PENDING(hcd))
|
|
|
|
|
return -EBUSY;
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
if (do_wakeup && hcd->shared_hcd &&
|
|
|
|
|
HCD_WAKEUP_PENDING(hcd->shared_hcd))
|
|
|
|
|
return -EBUSY;
|
2010-06-26 02:02:14 +08:00
|
|
|
retval = hcd->driver->pci_suspend(hcd, do_wakeup);
|
2008-04-04 06:03:06 +08:00
|
|
|
suspend_report_result(hcd->driver->pci_suspend, retval);
|
2010-06-26 02:02:35 +08:00
|
|
|
|
|
|
|
|
/* Check again in case wakeup raced with pci_suspend */
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
if ((retval == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) ||
|
|
|
|
|
(retval == 0 && do_wakeup && hcd->shared_hcd &&
|
|
|
|
|
HCD_WAKEUP_PENDING(hcd->shared_hcd))) {
|
2010-06-26 02:02:35 +08:00
|
|
|
if (hcd->driver->pci_resume)
|
|
|
|
|
hcd->driver->pci_resume(hcd, false);
|
|
|
|
|
retval = -EBUSY;
|
|
|
|
|
}
|
2006-03-23 17:38:34 +08:00
|
|
|
if (retval)
|
2009-04-28 01:33:24 +08:00
|
|
|
return retval;
|
2005-09-23 13:38:16 +08:00
|
|
|
}
|
|
|
|
|
|
2010-12-27 17:39:02 +08:00
|
|
|
/* If MSI-X is enabled, the driver will have synchronized all vectors
|
|
|
|
|
* in pci_suspend(). If MSI or legacy PCI is enabled, that will be
|
|
|
|
|
* synchronized here.
|
|
|
|
|
*/
|
|
|
|
|
if (!hcd->msix_enabled)
|
|
|
|
|
synchronize_irq(pci_dev->irq);
|
2005-04-19 08:39:22 +08:00
|
|
|
|
2009-01-20 08:26:56 +08:00
|
|
|
/* Downstream ports from this root hub should already be quiesced, so
|
|
|
|
|
* there will be no DMA activity. Now we can shut down the upstream
|
2009-04-28 01:33:24 +08:00
|
|
|
* link (except maybe for PME# resume signaling). We'll enter a
|
|
|
|
|
* low power state during suspend_noirq, if the hardware allows.
|
2009-01-20 08:26:56 +08:00
|
|
|
*/
|
2009-04-28 01:33:24 +08:00
|
|
|
pci_disable_device(pci_dev);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-26 02:02:03 +08:00
|
|
|
static int resume_common(struct device *dev, int event)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
|
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
|
|
|
|
|
int retval;
|
|
|
|
|
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
if (HCD_RH_RUNNING(hcd) ||
|
|
|
|
|
(hcd->shared_hcd &&
|
|
|
|
|
HCD_RH_RUNNING(hcd->shared_hcd))) {
|
2010-06-26 02:02:03 +08:00
|
|
|
dev_dbg(dev, "can't resume, not suspended!\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
retval = pci_enable_device(pci_dev);
|
|
|
|
|
if (retval < 0) {
|
|
|
|
|
dev_err(dev, "can't re-enable after resume, %d!\n", retval);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pci_set_master(pci_dev);
|
|
|
|
|
|
2011-03-08 00:11:52 +08:00
|
|
|
if (hcd->driver->pci_resume && !HCD_DEAD(hcd)) {
|
USB: improve port transitions when EHCI starts up
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-29 03:04:45 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Only EHCI controllers have to wait for their companions.
|
|
|
|
|
* No locking is needed because PCI controller drivers do not
|
|
|
|
|
* get unbound during system resume.
|
|
|
|
|
*/
|
|
|
|
|
if (pci_dev->class == CL_EHCI && event != PM_EVENT_AUTO_RESUME)
|
|
|
|
|
for_each_companion(pci_dev, hcd,
|
|
|
|
|
ehci_wait_for_companions);
|
2010-06-26 02:02:03 +08:00
|
|
|
|
|
|
|
|
retval = hcd->driver->pci_resume(hcd,
|
|
|
|
|
event == PM_EVENT_RESTORE);
|
|
|
|
|
if (retval) {
|
|
|
|
|
dev_err(dev, "PCI post-resume error %d!\n", retval);
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
if (hcd->shared_hcd)
|
|
|
|
|
usb_hc_died(hcd->shared_hcd);
|
2010-06-26 02:02:03 +08:00
|
|
|
usb_hc_died(hcd);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-26 02:02:57 +08:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
|
|
|
|
|
static int hcd_pci_suspend(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return suspend_common(dev, device_may_wakeup(dev));
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
static int hcd_pci_suspend_noirq(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
|
|
|
|
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
|
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
|
|
retval = check_root_hub_suspended(dev);
|
|
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
2009-01-20 08:26:56 +08:00
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
pci_save_state(pci_dev);
|
2009-01-20 08:26:56 +08:00
|
|
|
|
USB: Set usb_hcd->state and flags for shared roothubs.
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-03 11:10:02 +08:00
|
|
|
/* If the root hub is dead rather than suspended, disallow remote
|
|
|
|
|
* wakeup. usb_hc_died() should ensure that both hosts are marked as
|
|
|
|
|
* dying, so we only need to check the primary roothub.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2011-03-08 00:11:52 +08:00
|
|
|
if (HCD_DEAD(hcd))
|
2009-04-28 01:33:24 +08:00
|
|
|
device_set_wakeup_enable(dev, 0);
|
|
|
|
|
dev_dbg(dev, "wakeup: %d\n", device_may_wakeup(dev));
|
2008-12-18 04:06:03 +08:00
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
/* Possibly enable remote wakeup,
|
|
|
|
|
* choose the appropriate low-power state, and go to that state.
|
|
|
|
|
*/
|
|
|
|
|
retval = pci_prepare_to_sleep(pci_dev);
|
|
|
|
|
if (retval == -EIO) { /* Low-power not supported */
|
|
|
|
|
dev_dbg(dev, "--> PCI D0 legacy\n");
|
|
|
|
|
retval = 0;
|
|
|
|
|
} else if (retval == 0) {
|
|
|
|
|
dev_dbg(dev, "--> PCI %s\n",
|
|
|
|
|
pci_power_name(pci_dev->current_state));
|
2008-12-18 04:06:03 +08:00
|
|
|
} else {
|
2009-04-28 01:33:24 +08:00
|
|
|
suspend_report_result(pci_prepare_to_sleep, retval);
|
|
|
|
|
return retval;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2010-06-26 02:01:49 +08:00
|
|
|
powermac_set_asic(pci_dev, 0);
|
2005-04-17 06:20:36 +08:00
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
static int hcd_pci_resume_noirq(struct device *dev)
|
2008-12-18 04:06:03 +08:00
|
|
|
{
|
2009-04-28 01:33:24 +08:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2008-12-18 04:06:03 +08:00
|
|
|
|
2010-06-26 02:01:49 +08:00
|
|
|
powermac_set_asic(pci_dev, 1);
|
2009-01-20 08:26:56 +08:00
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
/* Go back to D0 and disable remote wakeup */
|
|
|
|
|
pci_back_from_sleep(pci_dev);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int hcd_pci_resume(struct device *dev)
|
USB: Properly unregister reboot notifier in case of failure in ehci hcd
If some problem occurs during ehci startup, for instance, request_irq fails,
echi hcd driver tries it best to cleanup, but fails to unregister reboot
notifier, which in turn leads to crash on reboot/poweroff.
The following patch resolves this problem by not using reboot notifiers
anymore, but instead making ehci/ohci driver get its own shutdown method. For
PCI, it is done through pci glue, for everything else through platform driver
glue.
One downside: sa1111 does not use platform driver stuff, and does not have its
own shutdown hook, so no 'shutdown' is called for it now. I'm not sure if it
is really necessary on that platform, though.
Signed-off-by: Aleks Gorelov <dared1st@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-09 08:24:08 +08:00
|
|
|
{
|
2010-06-26 02:02:03 +08:00
|
|
|
return resume_common(dev, PM_EVENT_RESUME);
|
2009-04-28 01:33:24 +08:00
|
|
|
}
|
USB: Properly unregister reboot notifier in case of failure in ehci hcd
If some problem occurs during ehci startup, for instance, request_irq fails,
echi hcd driver tries it best to cleanup, but fails to unregister reboot
notifier, which in turn leads to crash on reboot/poweroff.
The following patch resolves this problem by not using reboot notifiers
anymore, but instead making ehci/ohci driver get its own shutdown method. For
PCI, it is done through pci glue, for everything else through platform driver
glue.
One downside: sa1111 does not use platform driver stuff, and does not have its
own shutdown hook, so no 'shutdown' is called for it now. I'm not sure if it
is really necessary on that platform, though.
Signed-off-by: Aleks Gorelov <dared1st@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-09 08:24:08 +08:00
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
static int hcd_pci_restore(struct device *dev)
|
|
|
|
|
{
|
2010-06-26 02:02:03 +08:00
|
|
|
return resume_common(dev, PM_EVENT_RESTORE);
|
USB: Properly unregister reboot notifier in case of failure in ehci hcd
If some problem occurs during ehci startup, for instance, request_irq fails,
echi hcd driver tries it best to cleanup, but fails to unregister reboot
notifier, which in turn leads to crash on reboot/poweroff.
The following patch resolves this problem by not using reboot notifiers
anymore, but instead making ehci/ohci driver get its own shutdown method. For
PCI, it is done through pci glue, for everything else through platform driver
glue.
One downside: sa1111 does not use platform driver stuff, and does not have its
own shutdown hook, so no 'shutdown' is called for it now. I'm not sure if it
is really necessary on that platform, though.
Signed-off-by: Aleks Gorelov <dared1st@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-08-09 08:24:08 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-06-26 02:02:57 +08:00
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
#define hcd_pci_suspend NULL
|
|
|
|
|
#define hcd_pci_suspend_noirq NULL
|
|
|
|
|
#define hcd_pci_resume_noirq NULL
|
|
|
|
|
#define hcd_pci_resume NULL
|
|
|
|
|
#define hcd_pci_restore NULL
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
|
|
|
|
|
|
|
|
|
static int hcd_pci_runtime_suspend(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
|
|
retval = suspend_common(dev, true);
|
|
|
|
|
if (retval == 0)
|
|
|
|
|
powermac_set_asic(to_pci_dev(dev), 0);
|
|
|
|
|
dev_dbg(dev, "hcd_pci_runtime_suspend: %d\n", retval);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int hcd_pci_runtime_resume(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
|
|
powermac_set_asic(to_pci_dev(dev), 1);
|
|
|
|
|
retval = resume_common(dev, PM_EVENT_AUTO_RESUME);
|
|
|
|
|
dev_dbg(dev, "hcd_pci_runtime_resume: %d\n", retval);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-15 10:00:08 +08:00
|
|
|
const struct dev_pm_ops usb_hcd_pci_pm_ops = {
|
2009-04-28 01:33:24 +08:00
|
|
|
.suspend = hcd_pci_suspend,
|
|
|
|
|
.suspend_noirq = hcd_pci_suspend_noirq,
|
|
|
|
|
.resume_noirq = hcd_pci_resume_noirq,
|
|
|
|
|
.resume = hcd_pci_resume,
|
|
|
|
|
.freeze = check_root_hub_suspended,
|
|
|
|
|
.freeze_noirq = check_root_hub_suspended,
|
|
|
|
|
.thaw_noirq = NULL,
|
|
|
|
|
.thaw = NULL,
|
|
|
|
|
.poweroff = hcd_pci_suspend,
|
|
|
|
|
.poweroff_noirq = hcd_pci_suspend_noirq,
|
|
|
|
|
.restore_noirq = hcd_pci_resume_noirq,
|
|
|
|
|
.restore = hcd_pci_restore,
|
2010-06-26 02:02:57 +08:00
|
|
|
.runtime_suspend = hcd_pci_runtime_suspend,
|
|
|
|
|
.runtime_resume = hcd_pci_runtime_resume,
|
2009-04-28 01:33:24 +08:00
|
|
|
};
|
|
|
|
|
EXPORT_SYMBOL_GPL(usb_hcd_pci_pm_ops);
|
|
|
|
|
|
2011-02-11 07:06:54 +08:00
|
|
|
#endif /* CONFIG_PM */
|