From patchwork Fri Jan 17 18:22:31 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 312164 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id D13F52C0091 for ; Sat, 18 Jan 2014 05:22:37 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752887AbaAQSWg (ORCPT ); Fri, 17 Jan 2014 13:22:36 -0500 Received: from mail-ie0-f177.google.com ([209.85.223.177]:33738 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752823AbaAQSWf (ORCPT ); Fri, 17 Jan 2014 13:22:35 -0500 Received: by mail-ie0-f177.google.com with SMTP id at1so2851037iec.36 for ; Fri, 17 Jan 2014 10:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TFlTTn7qZCnwc68OuFE0p8/RbzkdUr3X475pJCzWNIs=; b=jbd9+C/K4PmNP5MYN7+MyeVDa310Jj2ixISp2Hjbv8XbeBPr7cmorCc4C40IW5dOFn 0da0gTOixvOjhujqTzoSefY6SlpScW/wFZd8Ke/ZCfJTgyKSVmKSW/oLDHeeJ6X69kf6 ne/f84HLsDK+JzR/4iVraq0OkWeInMoKBaqq3f31heuXC0tVlOcg4SMnk1ZjyL6CT5KR 03RFpM8MYuRLnXxCNeL5U1cV7grQoN8CW3RNaQ6NpZ34gCd8jS7NRCb2LyDOKnDdJEol isE8pRG69SMBGSAFIdmC51XAx6Mm4aHqOUhNE9MTR+q4Rd7hMfVcDoSDhKBh9nIG47le 7yuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=TFlTTn7qZCnwc68OuFE0p8/RbzkdUr3X475pJCzWNIs=; b=KIFPkda4+hZGGs0k8YMz5V7Cenb5jYutsT5TvdWBENLr+rhl79EFMwD/dh/25OWtr8 fzMuABCh4+/HTq1sQUW2kUQZNPNwM4pz8nq06aEirHOsAWGd5fhaZh8mppS1+fgydwLL c/hA3wazZRn1hLfonvCdu5GPDCQB1x+73+WLk3qrR5v9gpbx+ywQECrep1nvwu5b0Nn3 7/4vfp+LQZjYLmjxuipSE9npR5Sf8GN7Ps9D647lzWDEAEmUyahX/YtuJlMtifRCGr9r bB48+ooi/FCTWEpEekHvPTAFp6h0OlujnreyRl49w1ZtOnjWcv7N1HZnFc8idwuoAXYL nG1w== X-Gm-Message-State: ALoCoQmqJbQChCaD0cKy6X8DDvUxZ6xxPiBvRG4T+gtQTrIfUr/NIoPWpT5ezHAboAx3d6H9smNqzIjruNfsyfPYBXKg/WwBgu0bkblHPRZ44b3G+lDfm59giENCitdJCOz7Lle0ZVrkwDG/sArHQYeQHwz6+AIoT28LUfPd2WqAsIDl8c+NoVYsVQTFrKwwoM3bPVjsiL2ZCzxsSucH3FEBH7qLdIfs9w== X-Received: by 10.50.79.198 with SMTP id l6mr4133168igx.23.1389982954733; Fri, 17 Jan 2014 10:22:34 -0800 (PST) Received: from google.com ([172.16.49.147]) by mx.google.com with ESMTPSA id nl14sm534115igb.7.2014.01.17.10.22.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 10:22:33 -0800 (PST) Date: Fri, 17 Jan 2014 11:22:31 -0700 From: Bjorn Helgaas To: Alan Stern Cc: Sarah Sharp , USB list , "Chen, Jamie" , "Tsai, Gaggery" , "linux-pci@vger.kernel.org" Subject: Re: EHCI host broken -- interrupts disabled Message-ID: <20140117182231.GA18421@google.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Jan 16, 2014 at 02:40:35PM -0500, Alan Stern wrote: > On Thu, 16 Jan 2014, Bjorn Helgaas wrote: > > > I think dev->irq is supposed to be valid after pci_enable_device(), so > > it seems like it would make sense to clear PCI_COMMAND_INTX_DISABLE > > there. > > Okay. > > > I don't know why a BIOS would leave PCI_COMMAND_INTX_DISABLE set for > > the EHCI device. Does it support MSI, and the BIOS assumes the OS > > should use that? I don't see any MSI support in the EHCI code. In > > As far as I know, there aren't any EHCI designs that use MSI. And > there is no particular reason why a BIOS would leave INTX_DISABLE set, > although come to think of it, there doesn't seem to be any reason why a > BIOS should leave that bit clear either. > > > any case, this doesn't seem like something we need to depend on the > > BIOS to do for us. > > Could you post a patch for Gaggery or Jamie to try out? Can you try the patch below? This is against 6e2d98dc1af4, the tip of the PCI "next" branch, but it should apply easily to any recent kernel. Can you also collect the dmesg and "lspci -vv" output for reference, in case we need to tweak or rework this in the future? Please remove any non-public details from that information before posting it. Bjorn PCI: Enable INTx if BIOS left it disabled From: Bjorn Helgaas Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) -- 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 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b6d4afa8ba40..0b6a1119b818 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1181,6 +1181,8 @@ EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state); static int do_pci_enable_device(struct pci_dev *dev, int bars) { int err; + u16 cmd; + u8 pin; err = pci_set_power_state(dev, PCI_D0); if (err < 0 && err != -EIO) @@ -1190,6 +1192,14 @@ static int do_pci_enable_device(struct pci_dev *dev, int bars) return err; pci_fixup_device(pci_fixup_enable, dev); + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); + if (pin) { + pci_read_config_word(dev, PCI_COMMAND, &cmd); + if (cmd & PCI_COMMAND_INTX_DISABLE) + pci_write_config_word(dev, PCI_COMMAND, + cmd & ~PCI_COMMAND_INTX_DISABLE); + } + return 0; }