Yeah, if it's a PCI device pci_enable_wake should do the right thing (use ACPI or other platform code if needed, otherwise fall back to banging on the PM cap bits, etc.). The call can fail if the device or platform can't wake up the system, is that what you're looking for? Jesse On Monday, December 15, 2008 5:57 pm JosephChan@xxxxxxxxxx wrote: > The reason we set this bit here is that we found the bit wasn't set when > doing S1 or S3. It caused the system can not be resumed by USB KB/MS. It's > weird. > > Thanks for the feedback. We will check this from PCI core. > > BRs, > Joseph Chan > > -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, December 16, 2008 12:18 AM > To: Joseph Chan; Jesse Barnes > Cc: USB list; linux-pci@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] HOST: Fix the USB KB/MS wakeup issue from S1/S3 with > VIA USB HOST controllers. > > On Mon, 15 Dec 2008 JosephChan@xxxxxxxxxx wrote: > > This patch fixes the issue which system cannot resume from S1/S3 with > > VIA USB HOST controllers by using USB KB/MS. > > > > > > Signed-off-by: Joseph Chan <JosephChan@xxxxxxxxxx> > > > > --- a/drivers/usb/host/uhci-hcd.c 2008-12-13 00:37:43.000000000 +0800 > > +++ b/drivers/usb/host/uhci-hcd.c 2008-12-13 01:38:50.000000000 +0800 > > @@ -514,11 +514,14 @@ > > static int uhci_init(struct usb_hcd *hcd) { > > struct uhci_hcd *uhci = hcd_to_uhci(hcd); > > + struct pci_dev *pdev = to_pci_dev(hcd->self.controller); > > unsigned io_size = (unsigned) hcd->rsrc_len; > > int port; > > > > uhci->io_addr = (unsigned long) hcd->rsrc_start; > > > > + device_init_wakeup(&pdev->dev, 1); > > + > > /* The UHCI spec says devices must have 2 ports, and goes on to say > > * they may have more but gives no way to determine how many there > > * are. However according to the UHCI spec, Bit 7 of the port > > This patch is wrong. What if the device doesn't support PCI PM? We > wouldn't want to set the can_wakeup flag then. > > In fact, the whole idea of doing device_init_wakeup() here is a bad one. > It should be taken care of by the PCI core, based on the PCI capabilities > and possibly on ACPI settings. > > Jesse, any reason why it isn't done this way already? > > Alan Stern -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
