From patchwork Wed Jul 4 18:47:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Stern X-Patchwork-Id: 1157161 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id BD245DFF0F for ; Wed, 4 Jul 2012 18:47:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932153Ab2GDSrJ (ORCPT ); Wed, 4 Jul 2012 14:47:09 -0400 Received: from netrider.rowland.org ([192.131.102.5]:41387 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755689Ab2GDSrI (ORCPT ); Wed, 4 Jul 2012 14:47:08 -0400 Received: (qmail 16826 invoked by uid 500); 4 Jul 2012 14:47:08 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jul 2012 14:47:08 -0400 Date: Wed, 4 Jul 2012 14:47:08 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: AceLan Kao cc: Bjorn Helgaas , , "Rafael J. Wysocki" , =?Big5?B?rHgoQWxleCmtWq/R?= Subject: Re: [PATCH] PCI: Quirk for ASUS S3 issue In-Reply-To: Message-ID: MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, 4 Jul 2012, AceLan Kao wrote: > We contacted the ASUS' BIOS engineer and try to verify this issue, for > it happened > on many ASUS' machines. Then they found that the system hangs in their > BIOS code. > The code will try to disable the USB if they found the PCI COMMAND > register is not zero. > > That's not a correct behavior that BIOS should do, the PCI COMMAND > register is not > represent if the USB is disabled or not, It's a workaround they tried to fix > another issue in windows long time ago, but ASUS' BIOS engineer refuse to remove > that part of code. But windows will clear the PCI COMMAND register if > windows is already > disabled the USB. > So, I try to write this quirk. > > Is there any reason not to clear the PCI COMMAND register of every PCI > > USB host controller when entering S3? > Quote from ASUS, they only mentioned EHCI > --------- > BIOS will check EHCI command register PCI regiter offset 04h to see if > USB is disabled or not. > Because regiter offset 04h is not cleared, BIOS think USB is not disabled. > Then BIOS will try to disabled USB, but the USB is disabled by Ubuntu > already. This conflict will cause system hang. > ASUS think since Ubuntu will disable USB, it also need to clear the > register too. > --------- How about this patch instead? (I haven't tested it yet...) Rafael, does this seem okay with no special quirk flag? Or should the command register be cleared as part of the USB code? Alan Stern --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: usb-3.5/drivers/pci/pci-driver.c =================================================================== --- usb-3.5.orig/drivers/pci/pci-driver.c +++ usb-3.5/drivers/pci/pci-driver.c @@ -748,6 +748,18 @@ static int pci_pm_suspend_noirq(struct d pci_pm_set_unknown_state(pci_dev); + /* + * Some BIOSes from ASUS have a bug: If a USB EHCI host controller's + * PCI COMMAND register isn't 0, the BIOS assumes that the controller + * hasn't been quiesced and tries to turn it off. If the controller + * is already in D3, this can hang or cause memory corruption. + * + * Since the value of the COMMAND register doesn't matter once the + * device has been suspended, we can safely set it to 0 here. + */ + if (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI) + pci_write_config_word(pci_dev, PCI_COMMAND, 0); + return 0; }