From patchwork Wed May 10 12:30:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Piotr Gregor X-Patchwork-Id: 760578 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 3wNFtz0bRJz9s7C for ; Wed, 10 May 2017 22:30:19 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=rsyncme-org.20150623.gappssmtp.com header.i=@rsyncme-org.20150623.gappssmtp.com header.b="0dyfooT6"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752721AbdEJMaG (ORCPT ); Wed, 10 May 2017 08:30:06 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:35925 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249AbdEJMaF (ORCPT ); Wed, 10 May 2017 08:30:05 -0400 Received: by mail-wr0-f176.google.com with SMTP id l50so41863734wrc.3 for ; Wed, 10 May 2017 05:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rsyncme-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=0KVqluBD/2RIuJhlysuhelBAjFp0Bn5hPnXphz7uvDM=; b=0dyfooT68cFNhcRpRlso/2WYg6HPNl9jCtUzfHkjRfbhTmh2TzAk2Th/jbnqcUzL49 /Fa8INkw6e+dPq+IP3BFSUpx6N/ljBPRibJfoyYsOwG3hkAf5AtGNuxkra2C0yA7v2y6 v12OlZ/4MTjL9/UdnNyBqkHfMKAL7dFfQbUJT8WQQ7basmb76gomAgI7PCrQYpiEUXyP GzIerqLG2xjBnKZ0h/lhF+hh/CPkytNYiyL7cNFia+f4K87ppHYAD2r/xGBdrH9nTslc ApPSObmqINVRLHUUy6MDFAd9CXvekdtIGZYDPnd7elMd4/ckHnVhdK7VqDstbiKW9uvb zuTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=0KVqluBD/2RIuJhlysuhelBAjFp0Bn5hPnXphz7uvDM=; b=GHR1mKB986PVy/oGez7e1JtbHufogGzZIG8sOZ4qwaKiMds/mUd8uEitukhQONg5Ov q3E8wMD02UtonM+qTLzNOVK+3vK6To60Ynb8tmoz63YyMlkbU0i0Vzskr/BciNIWHlfz 6KbLcwdEzsC83k9KEPo9xbeJHWs4U7sMmxL4ui/NuosWuLjTEDnsD4+OefMgueo0cfXD p99vuzLTlXPtWSMNYDIEaN/3C9gI7Gk5tNNsGnXExOaMFW6KZFESfLLWHsec6u3Egn79 C6ZwyoOcODkr5n9M5JZuTOr0l3mx0l21ISEWqATaDKGgWW59UMv7BhwQsJv4MSL0vks5 vHwA== X-Gm-Message-State: AODbwcAUA6UXoqyDMsBgLb4/lQAwETGgnMBHp3MB+vqfZV+MpfCOwGII cyYRWWx2a2W7zA== X-Received: by 10.28.58.143 with SMTP id h137mr928316wma.72.1494419403831; Wed, 10 May 2017 05:30:03 -0700 (PDT) Received: from debian1.home ([185.63.83.17]) by smtp.gmail.com with ESMTPSA id y63sm4989719wme.31.2017.05.10.05.30.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 05:30:03 -0700 (PDT) Date: Wed, 10 May 2017 13:30:01 +0100 From: Piotr Gregor To: bhelgaas@google.com Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] pci: Handle the case when PCI_COMMAND register hasn't changed in INTx masking test Message-ID: <20170510122959.4uupohiz3ukzm4c4@debian1.home> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.6.2-neo (2016-06-11) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org The check for interrupt masking support is done by reading the PCI_COMMAND config word pci_read_config_word(dev, PCI_COMMAND, &orig); then flipping the PCI_COMMAND_INTX_DISABLE bit and writing result back pci_write_config_word(dev, PCI_COMMAND, orig ^ PCI_COMMAND_INTX_DISABLE); The expected result is that following read of the PCI_COMMAND pci_read_config_word(dev, PCI_COMMAND, &new); returns PCI_COMMAND with only PCI_COMMAND_INTX_DISABLE bit changed. There are two possible outcomes: 1. Command is the same (hasn't changed) 2. Commmand has changed And the second of them may be decoupled to: 2.1 Command changed only for PCI_COMMAND_INTX_DISABLE bit (hasn't changed for bits different than PCI_COMMAND_INTX_DISABLE) 2.2 Command changed for bit(s) different than PCI_COMMAND_INTX_DISABLE bit (and maybe for PCI_COMMAND_INTX_DISABLE too) The 2.1 is expected result and anything else is error. The 2.2 outcome is handled by pci_intx_mask_supported by printing appropriate message to the log, but outcome 1 is not handled. Log the message about command not being changed at all. Signed-off-by: Piotr Gregor --- drivers/pci/pci.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b01bd5b..67a611e 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3712,7 +3712,7 @@ EXPORT_SYMBOL_GPL(pci_intx); * pci_intx_mask_supported - probe for INTx masking support * @dev: the PCI device to operate on * - * Check if the device dev support INTx masking via the config space + * Check if the device dev supports INTx masking via the config space * command word. */ bool pci_intx_mask_supported(struct pci_dev *dev) @@ -3736,11 +3736,21 @@ bool pci_intx_mask_supported(struct pci_dev *dev) * go ahead and check it. */ if ((new ^ orig) & ~PCI_COMMAND_INTX_DISABLE) { + /* + * If anything else than PCI_COMMAND_INTX_DISABLE bit has + * changed (and maybe PCI_COMMAND_INTX_DISABLE too) + */ dev_err(&dev->dev, "Command register changed from 0x%x to 0x%x: driver or hardware bug?\n", orig, new); } else if ((new ^ orig) & PCI_COMMAND_INTX_DISABLE) { + /* + * OK. Only PCI_COMMAND_INTX_DISABLE bit has changed + */ mask_supported = true; pci_write_config_word(dev, PCI_COMMAND, orig); + } else { + dev_err(&dev->dev, "Command register hasn't changed when written from 0x%x to 0x%x: driver or hardware bug?\n", + orig, new); } pci_cfg_access_unlock(dev); @@ -3798,7 +3808,7 @@ static bool pci_check_and_set_intx_mask(struct pci_dev *dev, bool mask) * @dev: the PCI device to operate on * * Check if the device dev has its INTx line asserted, mask it and - * return true in that case. False is returned if not interrupt was + * return true in that case. False is returned if interrupt wasn't * pending. */ bool pci_check_and_mask_intx(struct pci_dev *dev)