iomem_is_exclusive() requires a CPU physical address, but on some arches we
supplied a PCI bus address instead.

On most arches, pci_resource_to_user(res) returns "res->start", which is a
CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
returns the PCI bus address corresponding to "res->start".

The result is that pci_mmap_resource() may fail when it shouldn't (if the
bus address happens to match an existing resource), or it may succeed when
it should fail (if the resource is exclusive but the bus address doesn't
match it).

Call iomem_is_exclusive() with "res->start", which is always a CPU physical
address, not the result of pci_resource_to_user().

Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers")
Suggested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arjan van de Ven <arjan@linux.intel.com>

The PCI config access checked the file capabilities correctly, but used
the itnernal security capability check rather than the helper function
that is actually meant for that.

The security_capable() has unusual return values and is not meant to be
used elsewhere (the only other use is in the capability checking
functions that we actually intend people to use, and this odd PCI usage
really stood out when looking around the capability code.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Return error immediately to simplify the control flow in pci_create_attr().
No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If sysfs_create_bin_file() fails, pci_create_attr() leaks the struct
bin_attribute it allocated previously.

Free the struct bin_attribute if pci_create_attr() fails.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute.  Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When pci_create_sysfs_dev_files() created the "rom" sysfs file, it set the
sysfs file size to the actual size of a ROM BAR, or if there was no ROM BAR
but the platform provided a shadow copy in RAM, to 0x20000.  0x20000 is an
arch-specific length that should not be baked into the PCI core.

Every place that sets IORESOURCE_ROM_SHADOW also sets the size of the
PCI_ROM_RESOURCE, so use the resource length always.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCI-2.2 VPD entries have a maximum size of 32k, but might actually be
smaller than that.  To figure out the actual size one has to read the VPD
area until the 'end marker' is reached.

Per spec, reading outside of the VPD space is "not allowed."  In practice,
it may cause simple read errors or even crash the card.  To make matters
worse not every PCI card implements this properly, leaving us with no 'end'
marker or even completely invalid data.

Try to determine the size of the VPD data when it's first accessed.  If no
valid data can be read an I/O error will be returned when reading or
writing the sysfs attribute.

As the amount of VPD data is unknown initially the size of the sysfs
attribute will always be set to '0'.

[bhelgaas: changelog, use 0/1 (not false/true) for bitfield, tweak
pci_vpd_pci22_read() error checking]
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>

It is not always possible to determine the actual size of the VPD
data, so allow access to them if the size is set to '0'.
Tested-by: NShane Seymour <shane.seymour@hpe.com>
Tested-by: NBabu Moger <babu.moger@oracle.com>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>

Use kobj_to_dev() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If a device quirk modifies the pci_dev->cfg_size to be less than
PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256),
the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE.

Allow sysfs access to config space up to cfg_size, even if the device
doesn't support the entire 4096-byte PCIe config space.

Note that pci_read_config() and pci_write_config() limit access to
dev->cfg_size even though pcie_config_attr contains 4096 (the maximum
size).
Signed-off-by: NJason S. McMullan <jason.mcmullan@netronome.com>
[simon: edited changelog]
Signed-off-by: NSimon Horman <simon.horman@netronome.com>
[bhelgaas: more changelog edits]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit 12669631 ("PCI: Prevent out of bounds access in numa_node
override") missed that the user-provided node could also be negative.
Handle this case as well to avoid out-of-bounds accesses to the
node_states[] array.  However, allow the special value -1, i.e.
NUMA_NO_NODE, to be able to set the 'no specific node' configuration.

Fixes: 12669631 ("PCI: Prevent out of bounds access in numa_node override")
Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Sasha Levin <sasha.levin@oracle.com>
CC: Prarit Bhargava <prarit@redhat.com>
CC: stable@vger.kernel.org	# v3.19+

63692df1 ("PCI: Allow numa_node override via sysfs") didn't check that
the numa node provided by userspace is valid.  Passing a node number too
high would attempt to access invalid memory and trigger a kernel panic.

Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.19+

When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.

Fixes: 782a985d ("PCI: Introduce new device binding path using pci_dev.driver_override")
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
CC: stable@vger.kernel.org	# v3.16+
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Alexander Graf <agraf@suse.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PCI core code.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Many sysfs *_show function use cpu{list,mask}_scnprintf to copy cpumap
to the buffer aligned to PAGE_SIZE, append '\n' and '\0' to return null
terminated buffer with newline.

This patch creates a new helper function cpumap_print_to_pagebuf in
cpumask.h using newly added bitmap_print_to_pagebuf and consolidates
most of those sysfs functions using the new helper function.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Suggested-by: NStephen Boyd <sboyd@codeaurora.org>
Tested-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: N"Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: x86@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

NUMA systems with ACPI normally describe the physical topology via _PXM
methods.  But many BIOSes don't implement _PXM, which leaves the kernel
with no way to discover the device topology, which reduces performance
because we can't put memory and processes close to the device.

The NUMA node of a PCI device is already exported in the sysfs "numa_node"
file.  Make that file writable so users can workaround the lack of _PXM
methods in the BIOS.  For example:

  echo 3 > /sys/devices/pci0000:ff/0000:03:1f.3/numa_node

sets the node for PCI device 0000:03:1f.3.

Writing the file emits a FW_BUG warning to encourage users to request
firmware updates.  It also taints the kernel with TAINT_FIRMWARE_WORKAROUND
because overriding the node incorrectly can cause performance issues.

[bhelgaas: changelog, documentation text]
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Myron Stowe <mstowe@redhat.com>
CC: Alexander Ducyk <alexander.h.duyck@redhat.com>
CC: Jiang Liu <jiang.liu@linux.intel.com>

Back in commit 5136b2da ("PCI: convert bus code to use dev_groups"),
I misstyped the 'enable' sysfs filename as 'enabled', which broke the
userspace API.  This patch fixes that issue by renaming the file back.

Fixes: 5136b2da ("PCI: convert bus code to use dev_groups")
Reported-by: NJeff Epler <jepler@unpythonic.net>
Tested-by: Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# 3.13

The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
future driver requests for MSI or MSI-X.  Previously, the sysfs file
existed for endpoints but did nothing.

Add "msi_bus" support for endpoints, so an administrator can prevent the
use of MSI and MSI-X for individual devices.

Note that as for bridges, these changes only affect future driver requests
for MSI or MSI-X, so drivers may need to be reloaded.

Add documentation for the "msi_bus" sysfs file.

[bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
rework bus_flags setting, make bus_flags printk unconditional]
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.

The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D.  Most interface types defined in the spec do not use
alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
20h, etc. are unaffected.

Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.

[bhelgaas: changelog]
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: stable@vger.kernel.org

Merge quoted strings that are broken across lines into a single entity.
The compiler merges them anyway, but checkpatch complains about it, and
merging them makes it easier to grep for strings.

No functional change.

[bhelgaas: changelog, do the same for everything under drivers/pci]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: NRyan Desfosses <ryan@desfo.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device.  This shortcuts the existing process of looking up the vendor and
device ID, adding them to the driver new_id, binding the device, then
removing the ID, but it also provides a couple advantages.

First, the above existing process allows the driver to bind to any device
matching the new_id for the window where it's enabled.  This is often not
desired, such as the case of trying to bind a single device to a meta
driver like pci-stub or vfio-pci.  Using driver_override we can do this
deterministically using:

  echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Previously we could not invoke drivers_probe after adding a device to
new_id for a driver as we get non-deterministic behavior whether the driver
we intend or the standard driver will claim the device.  Now it becomes a
deterministic process, only the driver matching driver_override will probe
the device.

To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:

  echo > /sys/bus/pci/devices/0000:03:00.0/driver_override
  echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
  echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

Another advantage to this approach is that we can specify a driver override
to force a specific binding or prevent any binding.  For instance when an
IOMMU group is exposed to userspace through VFIO we require that all
devices within that group are owned by VFIO.  However, devices can be
hot-added into an IOMMU group, in which case we want to prevent the device
from binding to any driver (override driver = "none") or perhaps have it
automatically bind to vfio-pci.  With driver_override it's a simple matter
for this field to be set internally when the device is first discovered to
prevent driver matches.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove pcibios_add_platform_entries().  Architecture-specific attributes
can be achieved by setting pdev->dev.groups.

Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettSigned-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the devspec OF attribute to PCI common code's set of device attributes
since it's not architecture dependent.  As a side effect microblaze and
powerpc no longer need to use pcibios_add_platform_entries().

[bhelgaas: fold in #include for compile error]
Link: https://lkml.kernel.org/r/alpine.LFD.2.11.1404141101500.1529@denkbrettSigned-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal.  Use it
instead of device_schedule_callback().  This makes "remove" behave
synchronously.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are multiple PCI device addition and removal code paths that may be
run concurrently with the generic PCI bus rescan and device removal that
can be triggered via sysfs.  If that happens, it may lead to multiple
different, potentially dangerous race conditions.

The most straightforward way to address those problems is to run
the code in question under the same lock that is used by the
generic rescan/remove code in pci-sysfs.c.  To prepare for those
changes, move the definition of the global PCI remove/rescan lock
to probe.c and provide global wrappers, pci_lock_rescan_remove()
and pci_unlock_rescan_remove(), allowing drivers to manipulate
that lock.  Also provide pci_stop_and_remove_bus_device_locked()
for the callers of pci_stop_and_remove_bus_device() who only need
to hold the rescan/remove lock around it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This reverts commit 6716d289.

Tejun writes:
        I'm sorry but can you please revert the whole series?
        get_active() waiting while a node is deactivated has potential
        to lead to deadlock and that deactivate/reactivate interface is
        something fundamentally flawed and that cgroup will have to work
        with the remove_self() like everybody else.  IOW, I think the
        first posting was correct.

Cc: Tejun Heo <tj@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal.  Use it
instead of device_schedule_callback().  This makes "remove" behave
synchronously.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix whitespace, capitalization, and spelling errors.  No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus())
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

local_cpus_show() and local_cpulist_show() are almost the same.
This adds a new helper function, pci_dev_show_local_cpu(), to simplify
code.

The same strategy is already used by cpuaffinity_show() and
cpulistaffinity_show().
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Local variables used only in this file are made static.

[bhelgaas: also make pci_dev_attrs[] static (from Fengguang)]
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the PCI bus code to use the
correct field.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dev_attrs field of struct class is going away soon, dev_groups
should be used instead.  This converts the PCI class code to use the
correct field.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

PCI devices for SR-IOV virtual functions should only be created/
destroyed by pci_enable_sriov()/pci_disable_sriov() because special
data structures are associated with SR-IOV virtual functions.
So hide hotplug related sysfs interfaces "remove" and "rescan" for
SR-IOV virtual functions, otherwise it may cause memory leakage
and other issues.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Donald Dutile <ddutile@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Ram Pai <linuxram@us.ibm.com>

The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete.  Thus, kstrtoul() should be
used.

[bhelgaas: "#define strict_strtoul  kstrtoul", so no functional change]
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

(*->vm_end - *->vm_start) >> PAGE_SHIFT operation is implemented
as an inline funcion vma_pages() in linux/mm.h, so use it.
Signed-off-by: NLibin <huawei.libin@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

If we request "num_vfs" and the driver's sriov_configure() method enables
exactly that number ("num_vfs_enabled"), we complain "Invalid value for
number of VFs to enable" and return an error.  We should silently return
success instead.

Also, use kstrtou16() since numVFs is defined to be a 16-bit field and
rework to simplify control flow.
Reported-by: NGreg Rose <gregory.v.rose@intel.com>
Reference: http://lkml.kernel.org/r/20121214101911.00002f59@unknownSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
Tested-by: NDonald Dutile <ddutile@redhat.com>

Remove conditional code based on CONFIG_HOTPLUG being false.  It's
always on now in preparation of it going away as an option.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>