From patchwork Sat Mar 25 16:18:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sumit Semwal X-Patchwork-Id: 95984 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp532148qgd; Sat, 25 Mar 2017 09:19:18 -0700 (PDT) X-Received: by 10.84.238.207 with SMTP id l15mr18269990pln.90.1490458757971; Sat, 25 Mar 2017 09:19:17 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si6723034pli.62.2017.03.25.09.19.17; Sat, 25 Mar 2017 09:19:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751340AbdCYQTS (ORCPT + 5 others); Sat, 25 Mar 2017 12:19:18 -0400 Received: from mail-pg0-f49.google.com ([74.125.83.49]:33376 "EHLO mail-pg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751309AbdCYQTR (ORCPT ); Sat, 25 Mar 2017 12:19:17 -0400 Received: by mail-pg0-f49.google.com with SMTP id n5so1546472pgh.0 for ; Sat, 25 Mar 2017 09:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=j3ms49jibrKmty+yBxTcO8/vx6pxhMSjywAq45SEIdI=; b=BWw9AincOK/BaIFakp4I8JpzMRD/o7xdvlToeuuOywymLki6xQf42niHpzPDPSx7Mv WRt6kKVtA0qFxJOqpVXX3jpCJcAqHL62ATQrozYgcwGNIlq6nO3VwpgjglqLb7Tr6EYG kjq4/XOekl/rj7D2LV1RN+ZScpnZ05pEW+Fx0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=j3ms49jibrKmty+yBxTcO8/vx6pxhMSjywAq45SEIdI=; b=INC612+qutV/MpaLfUHUDyHMkqZ1dJnhwaxO1mLnTA/j//6s4LFhRu1ZooYy0MXe/0 6hmpllZ5+EGT+c1a/loH6FoL+Mt8Q7gEjwBJdcyl5gtJ4MO04VUzmYobyH7EpIbsvOc2 Dm5MMnMZYMQGCVGsnBFBfnfDnrAyH59wVvXY9ZeFN5zanWO2d/jSvls/yvaZEmXz1Cy+ bjGn9qC+OPeiqxmMYYG3Vy65tefPZRHI2rTJr9PONIq+QPwjTf8VC0QpCiQGQXUZ+7Xq J2q+vZd9X5kxhrP/6Xq5Q/GfykaLsFt+/U9oYM4Z08Au0StfSIgTaALVNN4yqvxFELqT UtSA== X-Gm-Message-State: AFeK/H3w5Pj8cJWYlBdkqkahHwDDhzyQcBzJEZijd+1X/0mSd6xLvJeupl/mRFzZQWXrmENj X-Received: by 10.98.107.194 with SMTP id g185mr16043136pfc.22.1490458755899; Sat, 25 Mar 2017 09:19:15 -0700 (PDT) Received: from phantom.lan ([106.51.225.38]) by smtp.gmail.com with ESMTPSA id q194sm11469541pfq.43.2017.03.25.09.19.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Mar 2017 09:19:14 -0700 (PDT) From: Sumit Semwal To: stable@vger.kernel.org Cc: Bjorn Helgaas , Sasha Levin , Greg Kroah-Hartman , Sumit Semwal Subject: [PATCH for-4.4 07/19] PCI: Add comments about ROM BAR updating Date: Sat, 25 Mar 2017 21:48:07 +0530 Message-Id: <1490458699-24484-8-git-send-email-sumit.semwal@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1490458699-24484-1-git-send-email-sumit.semwal@linaro.org> References: <1490458699-24484-1-git-send-email-sumit.semwal@linaro.org> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Bjorn Helgaas [ Upstream commit 0b457dde3cf8b7c76a60f8e960f21bbd4abdc416 ] pci_update_resource() updates a hardware BAR so its address matches the kernel's struct resource UNLESS it's a disabled ROM BAR. We only update those when we enable the ROM. It's not obvious from the code why ROM BARs should be handled specially. Apparently there are Matrox devices with defective ROM BARs that read as zero when disabled. That means that if pci_enable_rom() reads the disabled BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and writes it back, it would enable the ROM at address zero. Add comments and references to explain why we can't make the code look more rational. The code changes are from 755528c860b0 ("Ignore disabled ROM resources at setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping"). Link: https://lkml.org/lkml/2005/8/30/138 Signed-off-by: Bjorn Helgaas Reviewed-by: Gavin Shan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman [sumits: minor fixup in rom.c for 4.4.y] Signed-off-by: Sumit Semwal --- drivers/pci/rom.c | 5 +++++ drivers/pci/setup-res.c | 6 ++++++ 2 files changed, 11 insertions(+) -- 2.7.4 diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index eb0ad53..3eea7fc 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -31,6 +31,11 @@ int pci_enable_rom(struct pci_dev *pdev) if (!res->flags) return -1; + /* + * Ideally pci_update_resource() would update the ROM BAR address, + * and we would only set the enable bit here. But apparently some + * devices have buggy ROM BARs that read as zero when disabled. + */ pcibios_resource_to_bus(pdev->bus, ®ion, res); pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr); rom_addr &= ~PCI_ROM_ADDRESS_MASK; diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 674e76c..d1ba5e0 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -68,6 +68,12 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno) if (resno < PCI_ROM_RESOURCE) { reg = PCI_BASE_ADDRESS_0 + 4 * resno; } else if (resno == PCI_ROM_RESOURCE) { + + /* + * Apparently some Matrox devices have ROM BARs that read + * as zero when disabled, so don't update ROM BARs unless + * they're enabled. See https://lkml.org/lkml/2005/8/30/138. + */ if (!(res->flags & IORESOURCE_ROM_ENABLE)) return;