WSL2-Linux-Kernel/drivers/usb/core/hcd-pci.c

657 строки
17 KiB
C
Исходник Обычный вид История

/*
* (C) Copyright David Brownell 2000-2002
*
* 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>
#include <linux/usb.h>
#include <linux/usb/hcd.h>
#include <asm/io.h>
#include <asm/irq.h>
#ifdef CONFIG_PPC_PMAC
#include <asm/machdep.h>
#include <asm/pmac_feature.h>
#include <asm/pci-bridge.h>
#include <asm/prom.h>
#endif
#include "usb.h"
/* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
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-28 23:04:45 +04:00
/*
* Coordinate handoffs between EHCI and companion controllers
* during EHCI probing and system resume.
2010-02-12 14:21:11 +03: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-28 23:04:45 +04:00
static DECLARE_RWSEM(companions_rwsem);
2010-02-12 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03:00
*/
companion = NULL;
for_each_pci_dev(companion) {
2010-02-12 14:21:11 +03:00
if (companion->bus != pdev->bus ||
PCI_SLOT(companion->devfn) != slot)
continue;
companion_hcd = pci_get_drvdata(companion);
if (!companion_hcd)
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-28 23:04:45 +04:00
fn(pdev, hcd, companion, companion_hcd);
2010-02-12 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04:00
struct usb_device *udev;
2010-02-12 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04:00
if (is_ohci_or_uhci(companion))
companion_hcd->self.hs_companion = NULL;
2010-02-12 14:21:11 +03: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-28 23:04:45 +04:00
#ifdef CONFIG_PM
2010-02-12 14:21:11 +03: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-28 23:04:45 +04: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 14:21:11 +03: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-28 23:04:45 +04:00
#endif /* CONFIG_PM */
/*-------------------------------------------------------------------------*/
/* 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().
*
* Return: 0 if successful.
*/
int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
struct hc_driver *driver;
struct usb_hcd *hcd;
int retval;
int hcd_irq = 0;
if (usb_disabled())
return -ENODEV;
if (!id)
return -EINVAL;
driver = (struct hc_driver *)id->driver_data;
if (!driver)
return -EINVAL;
if (pci_enable_device(dev) < 0)
return -ENODEV;
dev->current_state = PCI_D0;
/*
* The xHCI driver has its own irq management
* make sure irq setup is not touched for xhci in generic hcd code
*/
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;
}
hcd = usb_create_hcd(driver, &dev->dev, pci_name(dev));
if (!hcd) {
retval = -ENOMEM;
goto disable_pci;
}
usb: core: implement AMD remote wakeup quirk The following patch is required to resolve remote wake issues with certain devices. Issue description: If the remote wake is issued from the device in a specific timing condition while the system is entering sleep state then it may cause system to auto wake on subsequent sleep cycle. Root cause: Host controller rebroadcasts the Resume signal > 100 µseconds after receiving the original resume event from the device. For proper function, some devices may require the rebroadcast of resume event within the USB spec of 100µS. Workaroud: 1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb devices are mouse or not. And get out the port id which attached a mouse with Pixart controller. 2. Then reset the port which attached issue device during system resume from S3. [Q] Why the special devices are only mice? Would high speed devices such as 3G modem or USB Bluetooth adapter trigger this issue? - Current this sensitivity is only confined to devices that use Pixart controllers. This controller is designed for use with LS mouse devices only. We have not observed any other devices failing. There may be a small risk for other devices also but this patch (reset device in resume phase) will cover the cases if required. [Q] Shouldn’t the resume signal be sent within 100 us for every device? - The Host controller may not send the resume signal within 100us, this our host controller specification change. This is why we require the patch to prevent side effects on certain known devices. [Q] Why would clicking mouse INTENSELY to wake the system up trigger this issue? - This behavior is specific to the devices that use Pixart controller. It is timing dependent on when the resume event is triggered during the sleep state. [Q] Is it a host controller issue or mouse? - It is the host controller behavior during resume that triggers the device incorrect behavior on the next resume. This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice when they attached to platforms with AMD Yangtze chipset. Signed-off-by: Huang Rui <ray.huang@amd.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-16 19:47:28 +04:00
hcd->amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev) &&
driver->flags & (HCD_USB11 | HCD_USB3)) ? 1 : 0;
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,
driver->description)) {
dev_dbg(&dev->dev, "controller already in use\n");
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-28 23:04:45 +04:00
goto put_hcd;
}
hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
if (hcd->regs == NULL) {
dev_dbg(&dev->dev, "error mapping memory\n");
retval = -EFAULT;
goto release_mem_region;
}
} else {
/* UHCI */
int region;
for (region = 0; region < PCI_ROM_RESOURCE; region++) {
if (!(pci_resource_flags(dev, region) &
IORESOURCE_IO))
continue;
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,
driver->description))
break;
}
if (region == PCI_ROM_RESOURCE) {
dev_dbg(&dev->dev, "no i/o regions available\n");
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-28 23:04:45 +04:00
goto put_hcd;
}
}
pci_set_master(dev);
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-28 23:04:45 +04: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);
}
if (retval != 0)
goto unmap_registers;
if (pci_dev_run_wake(dev))
pm_runtime_put_noidle(&dev->dev);
return retval;
unmap_registers:
if (driver->flags & HCD_MEMORY) {
iounmap(hcd->regs);
release_mem_region:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
} else
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-28 23:04:45 +04:00
put_hcd:
usb_put_hcd(hcd);
disable_pci:
pci_disable_device(dev);
dev_err(&dev->dev, "init %s fail, %d\n", pci_name(dev), retval);
return retval;
}
EXPORT_SYMBOL_GPL(usb_hcd_pci_probe);
/* 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().
*/
void usb_hcd_pci_remove(struct pci_dev *dev)
{
struct usb_hcd *hcd;
hcd = pci_get_drvdata(dev);
if (!hcd)
return;
if (pci_dev_run_wake(dev))
pm_runtime_get_noresume(&dev->dev);
/* 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-28 23:04:45 +04: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);
}
if (hcd->driver->flags & HCD_MEMORY) {
iounmap(hcd->regs);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
} else {
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-28 23:04:45 +04:00
usb_put_hcd(hcd);
pci_disable_device(dev);
}
EXPORT_SYMBOL_GPL(usb_hcd_pci_remove);
/**
* usb_hcd_pci_shutdown - shutdown host controller
* @dev: USB Host Controller being shutdown
*/
void usb_hcd_pci_shutdown(struct pci_dev *dev)
{
struct usb_hcd *hcd;
hcd = pci_get_drvdata(dev);
if (!hcd)
return;
if (test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags) &&
OHCI: work around for nVidia shutdown problem This patch (as1417) fixes a problem affecting some (or all) nVidia chipsets. When the computer is shut down, the OHCI controllers continue to power the USB buses and evidently they drive a Reset signal out all their ports. This prevents attached devices from going to low power. Mouse LEDs stay on, for example, which is disconcerting for users and a drain on laptop batteries. The fix involves leaving each OHCI controller in the OPERATIONAL state during system shutdown rather than putting it in the RESET state. Although this nominally means the controller is running, in fact it's not doing very much since all the schedules are all disabled. However there is ongoing DMA to the Host Controller Communications Area, so the patch also disables the bus-master capability of all PCI USB controllers after the shutdown routine runs. The fix is applied only to nVidia-based PCI OHCI controllers, so it shouldn't cause problems on systems using other hardware. As an added safety measure, in case the kernel encounters one of these running controllers during boot, the patch changes quirk_usb_handoff_ohci() (which runs early on during PCI discovery) to reset the controller before anything bad can happen. Reported-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Tested-by: Pali Rohár <pali.rohar@gmail.com> CC: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-09-11 00:37:05 +04:00
hcd->driver->shutdown) {
hcd->driver->shutdown(hcd);
OHCI: work around for nVidia shutdown problem This patch (as1417) fixes a problem affecting some (or all) nVidia chipsets. When the computer is shut down, the OHCI controllers continue to power the USB buses and evidently they drive a Reset signal out all their ports. This prevents attached devices from going to low power. Mouse LEDs stay on, for example, which is disconcerting for users and a drain on laptop batteries. The fix involves leaving each OHCI controller in the OPERATIONAL state during system shutdown rather than putting it in the RESET state. Although this nominally means the controller is running, in fact it's not doing very much since all the schedules are all disabled. However there is ongoing DMA to the Host Controller Communications Area, so the patch also disables the bus-master capability of all PCI USB controllers after the shutdown routine runs. The fix is applied only to nVidia-based PCI OHCI controllers, so it shouldn't cause problems on systems using other hardware. As an added safety measure, in case the kernel encounters one of these running controllers during boot, the patch changes quirk_usb_handoff_ohci() (which runs early on during PCI discovery) to reset the controller before anything bad can happen. Reported-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Tested-by: Pali Rohár <pali.rohar@gmail.com> CC: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-09-11 00:37:05 +04:00
pci_disable_device(dev);
}
}
EXPORT_SYMBOL_GPL(usb_hcd_pci_shutdown);
#ifdef CONFIG_PM
#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 */
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);
USB: move usbcore away from hcd->state The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-07 19:11:52 +03:00
if (HCD_RH_RUNNING(hcd)) {
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 06:10:02 +03: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;
}
}
return 0;
}
#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
static int suspend_common(struct device *dev, bool do_wakeup)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
int retval;
/* 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...
*/
retval = check_root_hub_suspended(dev);
if (retval)
return retval;
USB: move usbcore away from hcd->state The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-07 19:11:52 +03:00
if (hcd->driver->pci_suspend && !HCD_DEAD(hcd)) {
/* 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 06:10:02 +03:00
if (do_wakeup && hcd->shared_hcd &&
HCD_WAKEUP_PENDING(hcd->shared_hcd))
return -EBUSY;
retval = hcd->driver->pci_suspend(hcd, do_wakeup);
suspend_report_result(hcd->driver->pci_suspend, retval);
/* 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 06:10:02 +03:00
if ((retval == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) ||
(retval == 0 && do_wakeup && hcd->shared_hcd &&
HCD_WAKEUP_PENDING(hcd->shared_hcd))) {
if (hcd->driver->pci_resume)
hcd->driver->pci_resume(hcd, false);
retval = -EBUSY;
}
if (retval)
return retval;
}
/* 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);
/* Downstream ports from this root hub should already be quiesced, so
* there will be no DMA activity. Now we can shut down the upstream
* link (except maybe for PME# resume signaling). We'll enter a
* low power state during suspend_noirq, if the hardware allows.
*/
pci_disable_device(pci_dev);
return retval;
}
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 06:10:02 +03:00
if (HCD_RH_RUNNING(hcd) ||
(hcd->shared_hcd &&
HCD_RH_RUNNING(hcd->shared_hcd))) {
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);
USB: move usbcore away from hcd->state The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-07 19:11:52 +03: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-28 23:04:45 +04: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);
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 06:10:02 +03:00
if (hcd->shared_hcd)
usb_hc_died(hcd->shared_hcd);
usb_hc_died(hcd);
}
}
return retval;
}
#endif /* SLEEP || RUNTIME */
#ifdef CONFIG_PM_SLEEP
static int hcd_pci_suspend(struct device *dev)
{
return suspend_common(dev, device_may_wakeup(dev));
}
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;
pci_save_state(pci_dev);
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 06:10:02 +03: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.
*/
USB: move usbcore away from hcd->state The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-03-07 19:11:52 +03:00
if (HCD_DEAD(hcd))
device_set_wakeup_enable(dev, 0);
dev_dbg(dev, "wakeup: %d\n", device_may_wakeup(dev));
/* 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));
} else {
suspend_report_result(pci_prepare_to_sleep, retval);
return retval;
}
powermac_set_asic(pci_dev, 0);
return retval;
}
static int hcd_pci_resume_noirq(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
powermac_set_asic(pci_dev, 1);
/* Go back to D0 and disable remote wakeup */
pci_back_from_sleep(pci_dev);
return 0;
}
static int hcd_pci_resume(struct device *dev)
{
return resume_common(dev, PM_EVENT_RESUME);
}
static int hcd_pci_restore(struct device *dev)
{
return resume_common(dev, PM_EVENT_RESTORE);
}
#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 */
#ifdef CONFIG_PM_RUNTIME
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;
}
#else
#define hcd_pci_runtime_suspend NULL
#define hcd_pci_runtime_resume NULL
#endif /* CONFIG_PM_RUNTIME */
const struct dev_pm_ops usb_hcd_pci_pm_ops = {
.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,
.runtime_suspend = hcd_pci_runtime_suspend,
.runtime_resume = hcd_pci_runtime_resume,
};
EXPORT_SYMBOL_GPL(usb_hcd_pci_pm_ops);
#endif /* CONFIG_PM */