Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 20 May 2020 08:57:08 -0500
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Paul Burton <paulburton@kernel.org>
Cc:     Krzysztof Wilczynski <kw@linux.com>, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: piix4-poweroff.c I/O BAR usage
Message-ID: <20200520135708.GA1086370@bjorn-Precision-5520>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Paul,

This looks like it might be a bug:

  static const int piix4_pm_io_region = PCI_BRIDGE_RESOURCES;

  static int piix4_poweroff_probe(struct pci_dev *dev,
                                  const struct pci_device_id *id)
  {
          ...
          /* Request access to the PIIX4 PM IO registers */
          res = pci_request_region(dev, piix4_pm_io_region,
                                   "PIIX4 PM IO registers");

pci_request_region() takes a BAR number (0-5), but here we're passing
PCI_BRIDGE_RESOURCES (13 if CONFIG_PCI_IOV, or 7 otherwise), which is
the bridge I/O window.

I don't think this device ([8086:7113]) is a bridge, so that resource
should be empty.

Based on this spec:
https://www.intel.com/Assets/PDF/datasheet/290562.pdf,
it looks like it should be the PIIX4 power management function at
function 3, which has no standard PCI BARs but does have a PMBA (Power
Management Base Address) at 0x40 and an SMBBA (SMBus Base Address) at
0x90 in config space.

I suppose on an ACPI system the regions described by PMBA and SMBBA
might be described via ACPI, since they're not discoverable by
standard PCI enumeration?  Pretty sure you don't have ACPI on MIPS
though.

Maybe the driver should read PMBA and SMBBA and reserve those regions
by hand with request_region()?

Bjorn