2005-09-23 13:31:15 +08:00
|
|
|
/*
|
|
|
|
|
* EHCI HCD (Host Controller Driver) PCI Bus Glue.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2000-2004 by David Brownell
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef CONFIG_PCI
|
|
|
|
|
#error "This file is PCI bus glue. CONFIG_PCI must be defined."
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-11-17 23:43:09 +08:00
|
|
|
/* defined here to avoid adding to pci_ids.h for single instance use */
|
|
|
|
|
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
|
|
|
|
|
|
2005-09-23 13:31:15 +08:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
2005-11-24 07:45:37 +08:00
|
|
|
/* called after powerup, by probe or system-pm "wakeup" */
|
|
|
|
|
static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
|
2006-01-24 23:15:30 +08:00
|
|
|
/* we expect static quirk code to handle the "extended capabilities"
|
|
|
|
|
* (currently just BIOS handoff) allowed starting with EHCI 0.96
|
|
|
|
|
*/
|
2005-11-24 07:45:37 +08:00
|
|
|
|
|
|
|
|
/* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
|
|
|
|
|
retval = pci_set_mwi(pdev);
|
|
|
|
|
if (!retval)
|
|
|
|
|
ehci_dbg(ehci, "MWI active\n");
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2005-11-29 00:40:38 +08:00
|
|
|
/* called during probe() after chip reset completes */
|
|
|
|
|
static int ehci_pci_setup(struct usb_hcd *hcd)
|
2005-09-23 13:31:15 +08:00
|
|
|
{
|
2005-11-24 07:45:32 +08:00
|
|
|
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
2008-11-14 11:42:29 +08:00
|
|
|
struct pci_dev *p_smbus;
|
|
|
|
|
u8 rev;
|
2005-09-23 13:31:15 +08:00
|
|
|
u32 temp;
|
2005-11-24 07:45:37 +08:00
|
|
|
int retval;
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2006-12-15 03:54:08 +08:00
|
|
|
switch (pdev->vendor) {
|
|
|
|
|
case PCI_VENDOR_ID_TOSHIBA_2:
|
|
|
|
|
/* celleb's companion chip */
|
|
|
|
|
if (pdev->device == 0x01b5) {
|
|
|
|
|
#ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO
|
|
|
|
|
ehci->big_endian_mmio = 1;
|
|
|
|
|
#else
|
|
|
|
|
ehci_warn(ehci,
|
|
|
|
|
"unsupported big endian Toshiba quirk\n");
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-23 13:31:15 +08:00
|
|
|
ehci->caps = hcd->regs;
|
2006-12-15 03:54:08 +08:00
|
|
|
ehci->regs = hcd->regs +
|
2011-05-04 02:11:57 +08:00
|
|
|
HC_LENGTH(ehci, ehci_readl(ehci, &ehci->caps->hc_capbase));
|
2006-12-15 03:54:08 +08:00
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
dbg_hcs_params(ehci, "reset");
|
|
|
|
|
dbg_hcc_params(ehci, "reset");
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2006-06-08 01:23:38 +08:00
|
|
|
/* ehci_init() causes memory for DMA transfers to be
|
|
|
|
|
* allocated. Thus, any vendor-specific workarounds based on
|
|
|
|
|
* limiting the type of memory used for DMA transfers must
|
|
|
|
|
* happen before ehci_init() is called. */
|
|
|
|
|
switch (pdev->vendor) {
|
|
|
|
|
case PCI_VENDOR_ID_NVIDIA:
|
|
|
|
|
/* NVidia reports that certain chips don't handle
|
|
|
|
|
* QH, ITD, or SITD addresses above 2GB. (But TD,
|
|
|
|
|
* data buffer, and periodic schedule are normal.)
|
|
|
|
|
*/
|
|
|
|
|
switch (pdev->device) {
|
|
|
|
|
case 0x003c: /* MCP04 */
|
|
|
|
|
case 0x005b: /* CK804 */
|
|
|
|
|
case 0x00d8: /* CK8 */
|
|
|
|
|
case 0x00e8: /* CK8S */
|
|
|
|
|
if (pci_set_consistent_dma_mask(pdev,
|
2009-04-07 10:01:16 +08:00
|
|
|
DMA_BIT_MASK(31)) < 0)
|
2006-06-08 01:23:38 +08:00
|
|
|
ehci_warn(ehci, "can't enable NVidia "
|
|
|
|
|
"workaround for >2GB RAM\n");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-23 13:31:15 +08:00
|
|
|
/* cache this readonly data; minimize chip reads */
|
2006-12-15 03:54:08 +08:00
|
|
|
ehci->hcs_params = ehci_readl(ehci, &ehci->caps->hcs_params);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2005-11-24 07:45:37 +08:00
|
|
|
retval = ehci_halt(ehci);
|
|
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
|
|
|
|
|
2010-11-08 17:58:35 +08:00
|
|
|
if ((pdev->vendor == PCI_VENDOR_ID_AMD && pdev->device == 0x7808) ||
|
|
|
|
|
(pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x4396)) {
|
|
|
|
|
/* EHCI controller on AMD SB700/SB800/Hudson-2/3 platforms may
|
|
|
|
|
* read/write memory space which does not belong to it when
|
|
|
|
|
* there is NULL pointer with T-bit set to 1 in the frame list
|
|
|
|
|
* table. To avoid the issue, the frame list link pointer
|
|
|
|
|
* should always contain a valid pointer to a inactive qh.
|
|
|
|
|
*/
|
|
|
|
|
ehci->use_dummy_qh = 1;
|
|
|
|
|
ehci_info(ehci, "applying AMD SB700/SB800/Hudson-2/3 EHCI "
|
|
|
|
|
"dummy qh workaround\n");
|
|
|
|
|
}
|
|
|
|
|
|
2005-11-29 00:40:38 +08:00
|
|
|
/* data structure init */
|
|
|
|
|
retval = ehci_init(hcd);
|
|
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
|
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
switch (pdev->vendor) {
|
2010-04-07 09:26:03 +08:00
|
|
|
case PCI_VENDOR_ID_NEC:
|
|
|
|
|
ehci->need_io_watchdog = 0;
|
|
|
|
|
break;
|
2009-07-13 17:30:41 +08:00
|
|
|
case PCI_VENDOR_ID_INTEL:
|
|
|
|
|
ehci->need_io_watchdog = 0;
|
2010-07-14 23:03:23 +08:00
|
|
|
ehci->fs_i_thresh = 1;
|
2009-11-27 22:17:59 +08:00
|
|
|
if (pdev->device == 0x27cc) {
|
|
|
|
|
ehci->broken_periodic = 1;
|
|
|
|
|
ehci_info(ehci, "using broken periodic workaround\n");
|
|
|
|
|
}
|
2010-09-06 21:50:57 +08:00
|
|
|
if (pdev->device == 0x0806 || pdev->device == 0x0811
|
|
|
|
|
|| pdev->device == 0x0829) {
|
|
|
|
|
ehci_info(ehci, "disable lpm for langwell/penwell\n");
|
|
|
|
|
ehci->has_lpm = 0;
|
|
|
|
|
}
|
2010-11-17 23:43:09 +08:00
|
|
|
if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB) {
|
|
|
|
|
hcd->has_tt = 1;
|
|
|
|
|
tdi_reset(ehci);
|
|
|
|
|
}
|
2009-07-13 17:30:41 +08:00
|
|
|
break;
|
2005-11-24 07:45:32 +08:00
|
|
|
case PCI_VENDOR_ID_TDI:
|
|
|
|
|
if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) {
|
2008-04-04 06:02:56 +08:00
|
|
|
hcd->has_tt = 1;
|
2005-11-24 07:45:32 +08:00
|
|
|
tdi_reset(ehci);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case PCI_VENDOR_ID_AMD:
|
2011-03-01 14:57:05 +08:00
|
|
|
/* AMD PLL quirk */
|
|
|
|
|
if (usb_amd_find_chipset_info())
|
|
|
|
|
ehci->amd_pll_fix = 1;
|
2005-11-24 07:45:32 +08:00
|
|
|
/* AMD8111 EHCI doesn't work, according to AMD errata */
|
|
|
|
|
if (pdev->device == 0x7463) {
|
|
|
|
|
ehci_info(ehci, "ignoring AMD8111 (errata)\n");
|
2005-11-29 00:40:38 +08:00
|
|
|
retval = -EIO;
|
|
|
|
|
goto done;
|
2005-11-24 07:45:32 +08:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case PCI_VENDOR_ID_NVIDIA:
|
2006-01-21 05:55:14 +08:00
|
|
|
switch (pdev->device) {
|
|
|
|
|
/* Some NForce2 chips have problems with selective suspend;
|
|
|
|
|
* fixed in newer silicon.
|
|
|
|
|
*/
|
|
|
|
|
case 0x0068:
|
2007-06-09 06:46:36 +08:00
|
|
|
if (pdev->revision < 0xa4)
|
2006-01-21 05:55:14 +08:00
|
|
|
ehci->no_selective_suspend = 1;
|
|
|
|
|
break;
|
2010-11-22 13:15:52 +08:00
|
|
|
|
|
|
|
|
/* MCP89 chips on the MacBookAir3,1 give EPROTO when
|
|
|
|
|
* fetching device descriptors unless LPM is disabled.
|
|
|
|
|
* There are also intermittent problems enumerating
|
|
|
|
|
* devices with PPCD enabled.
|
|
|
|
|
*/
|
|
|
|
|
case 0x0d9d:
|
|
|
|
|
ehci_info(ehci, "disable lpm/ppcd for nvidia mcp89");
|
|
|
|
|
ehci->has_lpm = 0;
|
|
|
|
|
ehci->has_ppcd = 0;
|
|
|
|
|
ehci->command &= ~CMD_PPCEE;
|
|
|
|
|
break;
|
2005-09-23 13:31:15 +08:00
|
|
|
}
|
2005-11-24 07:45:32 +08:00
|
|
|
break;
|
2008-03-20 15:58:16 +08:00
|
|
|
case PCI_VENDOR_ID_VIA:
|
|
|
|
|
if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x60) {
|
|
|
|
|
u8 tmp;
|
|
|
|
|
|
|
|
|
|
/* The VT6212 defaults to a 1 usec EHCI sleep time which
|
|
|
|
|
* hogs the PCI bus *badly*. Setting bit 5 of 0x4B makes
|
|
|
|
|
* that sleep time use the conventional 10 usec.
|
|
|
|
|
*/
|
|
|
|
|
pci_read_config_byte(pdev, 0x4b, &tmp);
|
|
|
|
|
if (tmp & 0x20)
|
|
|
|
|
break;
|
|
|
|
|
pci_write_config_byte(pdev, 0x4b, tmp | 0x20);
|
|
|
|
|
}
|
|
|
|
|
break;
|
2008-11-14 11:42:29 +08:00
|
|
|
case PCI_VENDOR_ID_ATI:
|
2011-03-01 14:57:05 +08:00
|
|
|
/* AMD PLL quirk */
|
|
|
|
|
if (usb_amd_find_chipset_info())
|
|
|
|
|
ehci->amd_pll_fix = 1;
|
2008-11-25 15:12:33 +08:00
|
|
|
/* SB600 and old version of SB700 have a bug in EHCI controller,
|
2008-11-14 11:42:29 +08:00
|
|
|
* which causes usb devices lose response in some cases.
|
|
|
|
|
*/
|
2008-11-25 15:12:33 +08:00
|
|
|
if ((pdev->device == 0x4386) || (pdev->device == 0x4396)) {
|
2008-11-14 11:42:29 +08:00
|
|
|
p_smbus = pci_get_device(PCI_VENDOR_ID_ATI,
|
|
|
|
|
PCI_DEVICE_ID_ATI_SBX00_SMBUS,
|
|
|
|
|
NULL);
|
|
|
|
|
if (!p_smbus)
|
|
|
|
|
break;
|
|
|
|
|
rev = p_smbus->revision;
|
2008-11-25 15:12:33 +08:00
|
|
|
if ((pdev->device == 0x4386) || (rev == 0x3a)
|
|
|
|
|
|| (rev == 0x3b)) {
|
2008-11-14 11:42:29 +08:00
|
|
|
u8 tmp;
|
2008-11-25 15:12:33 +08:00
|
|
|
ehci_info(ehci, "applying AMD SB600/SB700 USB "
|
|
|
|
|
"freeze workaround\n");
|
2008-11-14 11:42:29 +08:00
|
|
|
pci_read_config_byte(pdev, 0x53, &tmp);
|
|
|
|
|
pci_write_config_byte(pdev, 0x53, tmp | (1<<3));
|
|
|
|
|
}
|
|
|
|
|
pci_dev_put(p_smbus);
|
|
|
|
|
}
|
|
|
|
|
break;
|
2011-10-12 22:39:14 +08:00
|
|
|
case PCI_VENDOR_ID_NETMOS:
|
|
|
|
|
/* MosChip frame-index-register bug */
|
|
|
|
|
ehci_info(ehci, "applying MosChip frame-index workaround\n");
|
|
|
|
|
ehci->frame_index_bug = 1;
|
|
|
|
|
break;
|
2005-11-24 07:45:32 +08:00
|
|
|
}
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2009-08-21 04:39:54 +08:00
|
|
|
/* optional debug port, normally in the first BAR */
|
|
|
|
|
temp = pci_find_capability(pdev, 0x0a);
|
|
|
|
|
if (temp) {
|
|
|
|
|
pci_read_config_dword(pdev, temp, &temp);
|
|
|
|
|
temp >>= 16;
|
|
|
|
|
if ((temp & (3 << 13)) == (1 << 13)) {
|
|
|
|
|
temp &= 0x1fff;
|
|
|
|
|
ehci->debug = ehci_to_hcd(ehci)->regs + temp;
|
|
|
|
|
temp = ehci_readl(ehci, &ehci->debug->control);
|
|
|
|
|
ehci_info(ehci, "debug port %d%s\n",
|
|
|
|
|
HCS_DEBUG_PORT(ehci->hcs_params),
|
|
|
|
|
(temp & DBGP_ENABLED)
|
|
|
|
|
? " IN USE"
|
|
|
|
|
: "");
|
|
|
|
|
if (!(temp & DBGP_ENABLED))
|
|
|
|
|
ehci->debug = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-08-21 09:13:27 +08:00
|
|
|
ehci_reset(ehci);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
|
|
|
|
/* at least the Genesys GL880S needs fixup here */
|
|
|
|
|
temp = HCS_N_CC(ehci->hcs_params) * HCS_N_PCC(ehci->hcs_params);
|
|
|
|
|
temp &= 0x0f;
|
|
|
|
|
if (temp && HCS_N_PORTS(ehci->hcs_params) > temp) {
|
2005-11-24 07:45:32 +08:00
|
|
|
ehci_dbg(ehci, "bogus port configuration: "
|
2005-09-23 13:31:15 +08:00
|
|
|
"cc=%d x pcc=%d < ports=%d\n",
|
|
|
|
|
HCS_N_CC(ehci->hcs_params),
|
|
|
|
|
HCS_N_PCC(ehci->hcs_params),
|
|
|
|
|
HCS_N_PORTS(ehci->hcs_params));
|
|
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
switch (pdev->vendor) {
|
|
|
|
|
case 0x17a0: /* GENESYS */
|
|
|
|
|
/* GL880S: should be PORTS=2 */
|
|
|
|
|
temp |= (ehci->hcs_params & ~0xf);
|
|
|
|
|
ehci->hcs_params = temp;
|
|
|
|
|
break;
|
|
|
|
|
case PCI_VENDOR_ID_NVIDIA:
|
|
|
|
|
/* NF4: should be PCC=10 */
|
|
|
|
|
break;
|
2005-09-23 13:31:15 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
/* Serial Bus Release Number is at PCI 0x60 offset */
|
|
|
|
|
pci_read_config_byte(pdev, 0x60, &ehci->sbrn);
|
2012-01-06 20:33:28 +08:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_STMICRO
|
|
|
|
|
&& pdev->device == PCI_DEVICE_ID_STMICRO_USB_HOST)
|
|
|
|
|
ehci->sbrn = 0x20; /* ConneXT has no sbrn register */
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2008-12-18 06:20:38 +08:00
|
|
|
/* Keep this around for a while just in case some EHCI
|
|
|
|
|
* implementation uses legacy PCI PM support. This test
|
|
|
|
|
* can be removed on 17 Dec 2009 if the dev_warn() hasn't
|
|
|
|
|
* been triggered by then.
|
2005-11-08 07:24:46 +08:00
|
|
|
*/
|
|
|
|
|
if (!device_can_wakeup(&pdev->dev)) {
|
|
|
|
|
u16 port_wake;
|
|
|
|
|
|
|
|
|
|
pci_read_config_word(pdev, 0x62, &port_wake);
|
2008-12-18 06:20:38 +08:00
|
|
|
if (port_wake & 0x0001) {
|
|
|
|
|
dev_warn(&pdev->dev, "Enabling legacy PCI PM\n");
|
2009-01-14 00:35:54 +08:00
|
|
|
device_set_wakeup_capable(&pdev->dev, 1);
|
2008-12-18 06:20:38 +08:00
|
|
|
}
|
2005-11-08 07:24:46 +08:00
|
|
|
}
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2006-01-21 05:55:14 +08:00
|
|
|
#ifdef CONFIG_USB_SUSPEND
|
|
|
|
|
/* REVISIT: the controller works fine for wakeup iff the root hub
|
|
|
|
|
* itself is "globally" suspended, but usbcore currently doesn't
|
|
|
|
|
* understand such things.
|
|
|
|
|
*
|
|
|
|
|
* System suspend currently expects to be able to suspend the entire
|
|
|
|
|
* device tree, device-at-a-time. If we failed selective suspend
|
|
|
|
|
* reports, system suspend would fail; so the root hub code must claim
|
2009-07-07 17:54:23 +08:00
|
|
|
* success. That's lying to usbcore, and it matters for runtime
|
2006-01-21 05:55:14 +08:00
|
|
|
* PM scenarios with selective suspend and remote wakeup...
|
|
|
|
|
*/
|
|
|
|
|
if (ehci->no_selective_suspend && device_can_wakeup(&pdev->dev))
|
|
|
|
|
ehci_warn(ehci, "selective suspend/wakeup unavailable\n");
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-04-18 23:11:26 +08:00
|
|
|
ehci_port_power(ehci, 1);
|
2005-11-24 07:45:37 +08:00
|
|
|
retval = ehci_pci_reinit(ehci, pdev);
|
2005-11-29 00:40:38 +08:00
|
|
|
done:
|
|
|
|
|
return retval;
|
2005-09-23 13:31:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
|
|
|
|
|
/* suspend/resume, section 4.3 */
|
|
|
|
|
|
2005-11-24 07:45:28 +08:00
|
|
|
/* These routines rely on the PCI bus glue
|
2005-09-23 13:31:15 +08:00
|
|
|
* to handle powerdown and wakeup, and currently also on
|
|
|
|
|
* transceivers that don't need any software attention to set up
|
|
|
|
|
* the right sort of wakeup.
|
2005-11-24 07:45:28 +08:00
|
|
|
* Also they depend on separate root hub suspend/resume.
|
2005-09-23 13:31:15 +08:00
|
|
|
*/
|
|
|
|
|
|
2010-06-26 02:02:14 +08:00
|
|
|
static int ehci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
|
2005-09-23 13:31:15 +08:00
|
|
|
{
|
2005-11-24 07:45:32 +08:00
|
|
|
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
int rc = 0;
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
if (time_before(jiffies, ehci->next_statechange))
|
|
|
|
|
msleep(10);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
/* Root hub was already suspended. Disable irq emission and
|
2010-05-13 06:21:35 +08:00
|
|
|
* mark HW unaccessible. The PM and USB cores make sure that
|
|
|
|
|
* the root hub is either suspended or stopped.
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
*/
|
2010-06-26 02:02:14 +08:00
|
|
|
ehci_prepare_ports_for_controller_suspend(ehci, do_wakeup);
|
2011-01-28 12:04:35 +08:00
|
|
|
spin_lock_irqsave (&ehci->lock, flags);
|
2006-12-15 03:54:08 +08:00
|
|
|
ehci_writel(ehci, 0, &ehci->regs->intr_enable);
|
|
|
|
|
(void)ehci_readl(ehci, &ehci->regs->intr_enable);
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
|
|
|
|
|
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
|
|
|
|
|
spin_unlock_irqrestore (&ehci->lock, flags);
|
|
|
|
|
|
2005-11-24 07:45:28 +08:00
|
|
|
// could save FLADJ in case of Vaux power loss
|
2005-09-23 13:31:15 +08:00
|
|
|
// ... we'd only use it to handle clock skew
|
|
|
|
|
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
return rc;
|
2005-09-23 13:31:15 +08:00
|
|
|
}
|
|
|
|
|
|
Intel xhci: Support EHCI/xHCI port switching.
The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.
This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.
This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.
Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.
Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.
Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.
The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-23 01:57:15 +08:00
|
|
|
static bool usb_is_intel_switchable_ehci(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
return pdev->class == PCI_CLASS_SERIAL_USB_EHCI &&
|
|
|
|
|
pdev->vendor == PCI_VENDOR_ID_INTEL &&
|
2012-02-10 07:55:13 +08:00
|
|
|
(pdev->device == 0x1E26 ||
|
|
|
|
|
pdev->device == 0x8C2D ||
|
|
|
|
|
pdev->device == 0x8C26);
|
Intel xhci: Support EHCI/xHCI port switching.
The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.
This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.
This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.
Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.
Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.
Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.
The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-23 01:57:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void ehci_enable_xhci_companion(void)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *companion = NULL;
|
|
|
|
|
|
|
|
|
|
/* The xHCI and EHCI controllers are not on the same PCI slot */
|
|
|
|
|
for_each_pci_dev(companion) {
|
|
|
|
|
if (!usb_is_intel_switchable_xhci(companion))
|
|
|
|
|
continue;
|
|
|
|
|
usb_enable_xhci_ports(companion);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 01:33:41 +08:00
|
|
|
static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated)
|
2005-09-23 13:31:15 +08:00
|
|
|
{
|
2005-11-24 07:45:32 +08:00
|
|
|
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
|
2005-11-24 07:45:37 +08:00
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
Intel xhci: Support EHCI/xHCI port switching.
The Intel Panther Point chipsets contain an EHCI and xHCI host controller
that shares some number of skew-dependent ports. These ports can be
switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
that is controlled by registers in the xHCI PCI configuration space. The
USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
separately from the USB 2.0 data wires.
This switchover mechanism is there to support users who do a custom
install of certain non-Linux operating systems that don't have official
USB 3.0 support. By default, the ports are under EHCI, SuperSpeed
terminations are off, and USB 3.0 devices will show up under the EHCI
controller at reduced speeds. (This was more palatable for the marketing
folks than having completely dead USB 3.0 ports if no xHCI drivers are
available.) Users should be able to turn on xHCI by default through a
BIOS option, but users are happiest when they don't have to change random
BIOS settings.
This patch introduces a driver method to switchover the ports from EHCI to
xHCI before the EHCI driver finishes PCI enumeration. We want to switch
the ports over before the USB core has the chance to enumerate devices
under EHCI, or boot from USB mass storage will fail if the boot device
connects under EHCI first, and then gets disconnected when the port
switches over to xHCI.
Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The
PCI quirks code will run before any other PCI probe function is called, so
this avoids the issue with boot devices.
Another issue is with BIOS behavior during system resume from hibernate.
If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
allow use of the USB keyboard, mice, and mass storage devices. It's
supposed to remember the value of the port routing registers and switch
them back when the OS attempts to take control of the xHCI host controller,
but we all know not to trust BIOS writers.
Make both the xHCI driver and the EHCI driver attempt to switchover the
ports in their PCI resume functions. We can't guarantee which PCI device
will be resumed first, so this avoids any race conditions. Writing a '1'
to an already set port switchover bit or a '0' to a cleared port switchover
bit should have no effect.
The xHCI PCI configuration registers will be documented in the EDS-level
chipset spec, which is not public yet. I have permission from legal and
the Intel chipset group to release this patch early to allow good Linux
support at product launch. I've tried to document the registers as much
as possible, so please let me know if anything is unclear.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-23 01:57:15 +08:00
|
|
|
/* The BIOS on systems with the Intel Panther Point chipset may or may
|
|
|
|
|
* not support xHCI natively. That means that during system resume, it
|
|
|
|
|
* may switch the ports back to EHCI so that users can use their
|
|
|
|
|
* keyboard to select a kernel from GRUB after resume from hibernate.
|
|
|
|
|
*
|
|
|
|
|
* The BIOS is supposed to remember whether the OS had xHCI ports
|
|
|
|
|
* enabled before resume, and switch the ports back to xHCI when the
|
|
|
|
|
* BIOS/OS semaphore is written, but we all know we can't trust BIOS
|
|
|
|
|
* writers.
|
|
|
|
|
*
|
|
|
|
|
* Unconditionally switch the ports back to xHCI after a system resume.
|
|
|
|
|
* We can't tell whether the EHCI or xHCI controller will be resumed
|
|
|
|
|
* first, so we have to do the port switchover in both drivers. Writing
|
|
|
|
|
* a '1' to the port switchover registers should have no effect if the
|
|
|
|
|
* port was already switched over.
|
|
|
|
|
*/
|
|
|
|
|
if (usb_is_intel_switchable_ehci(pdev))
|
|
|
|
|
ehci_enable_xhci_companion();
|
|
|
|
|
|
2005-11-24 07:45:28 +08:00
|
|
|
// maybe restore FLADJ
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2005-11-24 07:45:32 +08:00
|
|
|
if (time_before(jiffies, ehci->next_statechange))
|
|
|
|
|
msleep(100);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
[PATCH] USB: Fix USB suspend/resume crasher (#2)
This patch closes the IRQ race and makes various other OHCI & EHCI code
path safer vs. suspend/resume.
I've been able to (finally !) successfully suspend and resume various
Mac models, with or without USB mouse plugged, or plugging while asleep,
or unplugging while asleep etc... all without a crash.
Alan, please verify the UHCI bit I did, I only verified that it builds.
It's very simple so I wouldn't expect any issue there. If you aren't
confident, then just drop the hunks that change uhci-hcd.c
I also made the patch a little bit more "safer" by making sure the store
to the interrupt register that disables interrupts is not posted before
I set the flag and drop the spinlock.
Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
I suspect PCs have some more sneaky issues too (they don't frankly crash
with machine checks because x86 tend to silently swallow PCI errors but
that won't last afaik, at least PCI Express will blow up in those
situations, but the USB code may still misbehave).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-25 06:59:46 +08:00
|
|
|
/* Mark hardware accessible again as we are out of D3 state by now */
|
|
|
|
|
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
|
|
|
|
|
|
2009-04-28 01:33:41 +08:00
|
|
|
/* If CF is still set and we aren't resuming from hibernation
|
|
|
|
|
* then we maintained PCI Vaux power.
|
2006-11-10 03:42:16 +08:00
|
|
|
* Just undo the effect of ehci_pci_suspend().
|
2005-09-23 13:31:15 +08:00
|
|
|
*/
|
2009-04-28 01:33:41 +08:00
|
|
|
if (ehci_readl(ehci, &ehci->regs->configured_flag) == FLAG_CF &&
|
|
|
|
|
!hibernated) {
|
2006-11-10 03:42:16 +08:00
|
|
|
int mask = INTR_MASK;
|
|
|
|
|
|
2010-05-13 06:21:35 +08:00
|
|
|
ehci_prepare_ports_for_controller_resume(ehci);
|
2008-04-15 00:17:10 +08:00
|
|
|
if (!hcd->self.root_hub->do_remote_wakeup)
|
2006-11-10 03:42:16 +08:00
|
|
|
mask &= ~STS_PCD;
|
2006-12-15 03:54:08 +08:00
|
|
|
ehci_writel(ehci, mask, &ehci->regs->intr_enable);
|
|
|
|
|
ehci_readl(ehci, &ehci->regs->intr_enable);
|
2006-11-10 03:42:16 +08:00
|
|
|
return 0;
|
2005-11-24 07:45:28 +08:00
|
|
|
}
|
|
|
|
|
|
2005-11-15 00:45:38 +08:00
|
|
|
usb_root_hub_lost_power(hcd->self.root_hub);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
|
|
|
|
/* Else reset, to cope with power loss or flush-to-storage
|
2005-11-24 07:45:28 +08:00
|
|
|
* style "resume" having let BIOS kick in during reboot.
|
2005-09-23 13:31:15 +08:00
|
|
|
*/
|
2005-11-24 07:45:32 +08:00
|
|
|
(void) ehci_halt(ehci);
|
|
|
|
|
(void) ehci_reset(ehci);
|
2005-11-24 07:45:37 +08:00
|
|
|
(void) ehci_pci_reinit(ehci, pdev);
|
2005-11-24 07:45:28 +08:00
|
|
|
|
|
|
|
|
/* emptying the schedule aborts any urbs */
|
2005-11-24 07:45:32 +08:00
|
|
|
spin_lock_irq(&ehci->lock);
|
2005-11-24 07:45:28 +08:00
|
|
|
if (ehci->reclaim)
|
2007-12-12 05:05:30 +08:00
|
|
|
end_unlink_async(ehci);
|
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 21:55:46 +08:00
|
|
|
ehci_work(ehci);
|
2005-11-24 07:45:32 +08:00
|
|
|
spin_unlock_irq(&ehci->lock);
|
2005-11-24 07:45:28 +08:00
|
|
|
|
2006-12-15 03:54:08 +08:00
|
|
|
ehci_writel(ehci, ehci->command, &ehci->regs->command);
|
|
|
|
|
ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
|
|
|
|
|
ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
|
2006-11-10 03:42:16 +08:00
|
|
|
|
2007-05-04 23:52:40 +08:00
|
|
|
/* here we "know" root ports should always stay powered */
|
|
|
|
|
ehci_port_power(ehci, 1);
|
|
|
|
|
|
2011-08-19 04:31:30 +08:00
|
|
|
ehci->rh_state = EHCI_RH_SUSPENDED;
|
2006-11-10 03:42:16 +08:00
|
|
|
return 0;
|
2005-09-23 13:31:15 +08:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-06-04 15:47:55 +08:00
|
|
|
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
|
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
if (!udev->parent) /* udev is root hub itself, impossible */
|
|
|
|
|
rc = -1;
|
|
|
|
|
/* we only support lpm device connected to root hub yet */
|
|
|
|
|
if (ehci->has_lpm && !udev->parent->parent) {
|
|
|
|
|
rc = ehci_lpm_set_da(ehci, udev->devnum, udev->portnum);
|
|
|
|
|
if (!rc)
|
|
|
|
|
rc = ehci_lpm_check(ehci, udev->portnum);
|
|
|
|
|
}
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-23 13:31:15 +08:00
|
|
|
static const struct hc_driver ehci_pci_hc_driver = {
|
|
|
|
|
.description = hcd_name,
|
|
|
|
|
.product_desc = "EHCI Host Controller",
|
|
|
|
|
.hcd_priv_size = sizeof(struct ehci_hcd),
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* generic hardware linkage
|
|
|
|
|
*/
|
|
|
|
|
.irq = ehci_irq,
|
|
|
|
|
.flags = HCD_MEMORY | HCD_USB2,
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* basic lifecycle operations
|
|
|
|
|
*/
|
2005-11-29 00:40:38 +08:00
|
|
|
.reset = ehci_pci_setup,
|
2005-11-24 07:45:37 +08:00
|
|
|
.start = ehci_run,
|
2005-09-23 13:31:15 +08:00
|
|
|
#ifdef CONFIG_PM
|
2008-04-04 06:03:06 +08:00
|
|
|
.pci_suspend = ehci_pci_suspend,
|
|
|
|
|
.pci_resume = ehci_pci_resume,
|
2005-09-23 13:31:15 +08:00
|
|
|
#endif
|
2005-11-24 07:45:37 +08:00
|
|
|
.stop = ehci_stop,
|
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
|
|
|
.shutdown = ehci_shutdown,
|
2005-09-23 13:31:15 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* managing i/o requests and associated device resources
|
|
|
|
|
*/
|
|
|
|
|
.urb_enqueue = ehci_urb_enqueue,
|
|
|
|
|
.urb_dequeue = ehci_urb_dequeue,
|
|
|
|
|
.endpoint_disable = ehci_endpoint_disable,
|
2009-05-28 06:21:56 +08:00
|
|
|
.endpoint_reset = ehci_endpoint_reset,
|
2005-09-23 13:31:15 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* scheduling support
|
|
|
|
|
*/
|
|
|
|
|
.get_frame_number = ehci_get_frame,
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* root hub support
|
|
|
|
|
*/
|
|
|
|
|
.hub_status_data = ehci_hub_status_data,
|
|
|
|
|
.hub_control = ehci_hub_control,
|
2005-10-14 05:08:02 +08:00
|
|
|
.bus_suspend = ehci_bus_suspend,
|
|
|
|
|
.bus_resume = ehci_bus_resume,
|
2008-05-21 04:58:11 +08:00
|
|
|
.relinquish_port = ehci_relinquish_port,
|
2008-05-21 04:58:29 +08:00
|
|
|
.port_handed_over = ehci_port_handed_over,
|
2009-06-29 22:47:30 +08:00
|
|
|
|
2010-06-04 15:47:55 +08:00
|
|
|
/*
|
|
|
|
|
* call back when device connected and addressed
|
|
|
|
|
*/
|
|
|
|
|
.update_device = ehci_update_device,
|
|
|
|
|
|
2009-06-29 22:47:30 +08:00
|
|
|
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
|
2005-09-23 13:31:15 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
/* PCI driver selection metadata; PCI hotplugging uses this */
|
|
|
|
|
static const struct pci_device_id pci_ids [] = { {
|
|
|
|
|
/* handle any USB 2.0 EHCI controller */
|
2006-04-10 02:07:35 +08:00
|
|
|
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_EHCI, ~0),
|
2005-09-23 13:31:15 +08:00
|
|
|
.driver_data = (unsigned long) &ehci_pci_hc_driver,
|
2012-01-06 20:33:28 +08:00
|
|
|
}, {
|
|
|
|
|
PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_USB_HOST),
|
|
|
|
|
.driver_data = (unsigned long) &ehci_pci_hc_driver,
|
2005-09-23 13:31:15 +08:00
|
|
|
},
|
|
|
|
|
{ /* end: all zeroes */ }
|
|
|
|
|
};
|
2005-11-24 07:45:32 +08:00
|
|
|
MODULE_DEVICE_TABLE(pci, pci_ids);
|
2005-09-23 13:31:15 +08:00
|
|
|
|
|
|
|
|
/* pci driver glue; this is a "new style" PCI driver module */
|
|
|
|
|
static struct pci_driver ehci_pci_driver = {
|
|
|
|
|
.name = (char *) hcd_name,
|
|
|
|
|
.id_table = pci_ids,
|
|
|
|
|
|
|
|
|
|
.probe = usb_hcd_pci_probe,
|
|
|
|
|
.remove = usb_hcd_pci_remove,
|
2009-04-28 01:33:24 +08:00
|
|
|
.shutdown = usb_hcd_pci_shutdown,
|
2005-09-23 13:31:15 +08:00
|
|
|
|
2009-04-28 01:33:24 +08:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
.driver = {
|
|
|
|
|
.pm = &usb_hcd_pci_pm_ops
|
|
|
|
|
},
|
2005-09-23 13:31:15 +08:00
|
|
|
#endif
|
|
|
|
|
};
|