PCI: Introduce pci_dev_for_each_resource()

Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious u

PCI: Introduce pci_dev_for_each_resource()

Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.

While at it drop doubled empty line before pdev_sort_resources().

No functional changes intended.

Suggested-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Krzysztof Wilczyński <[email protected]>

show more ...

ARM/PCI: Remove unused fields from struct hw_pci

The msi_ctrl, io_optional and align_resource fields in struct hw_pci are
currently unused by arm/mach PCI host controller drivers and we won't
be add

ARM/PCI: Remove unused fields from struct hw_pci

The msi_ctrl, io_optional and align_resource fields in struct hw_pci are
currently unused by arm/mach PCI host controller drivers and we won't
be adding any new users.

Remove them and related code.

Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Russell King <[email protected]>

show more ...

ARM: 8993/1: remove it8152 PCI controller driver

The it8152 PCI host controller was only used by cm-x2xx platforms.
Since these platforms were removed, there is no point to keep it8152
driver.

Acke

ARM: 8993/1: remove it8152 PCI controller driver

The it8152 PCI host controller was only used by cm-x2xx platforms.
Since these platforms were removed, there is no point to keep it8152
driver.

Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64

On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
which helps decide whether to reconfigure bridge bus numbers. It ha

PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64

On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
which helps decide whether to reconfigure bridge bus numbers. It has
nothing to do with BAR assignments. On arm64 and powerpc,
pcibios_assign_all_busses() tests PCI_REASSIGN_ALL_BUS, which makes more
sense.

Align arm with arm64 and powerpc, so they all use PCI_REASSIGN_ALL_BUS for
pcibios_assign_all_busses().

Remove PCI_REASSIGN_ALL_RSRC from the generic, Tegra, Versatile, and
R-Car drivers. These drivers are used only on arm or arm64, where
PCI_REASSIGN_ALL_RSRC is not used after this change, so removing it
should have no effect.

No functional change intended.

Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Manikanta Maddireddy <[email protected]>
Reviewed-by: Lorenzo Pieralisi <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM/PCI: Fix pcibios_init_resource() struct pci_host_bridge leak

Since commit 97ad2bdcbe85 ("ARM/PCI: Convert PCI scan API to
pci_scan_root_bus_bridge()") the space for struct pci_sys_data is alloca

ARM/PCI: Fix pcibios_init_resource() struct pci_host_bridge leak

Since commit 97ad2bdcbe85 ("ARM/PCI: Convert PCI scan API to
pci_scan_root_bus_bridge()") the space for struct pci_sys_data is allocated
by pci_alloc_host_bridge() as part of the struct pci_host_bridge.

Therefore, failure paths must deallocate the entire pci_host_bridge by
using pci_free_host_bridge().

Fixes: 97ad2bdcbe85 ("ARM/PCI: Convert PCI scan API to pci_scan_root_bus_bridge()")
Signed-off-by: Lorenzo Pieralisi <[email protected]>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>

show more ...

ARM/PCI: Remove pci_fixup_irqs() call for bios32 host controllers

Legacy PCI host controllers (ie host controllers that set-up the PCI bus
through the ARM pci_common_init() API) are currently relyin

ARM/PCI: Remove pci_fixup_irqs() call for bios32 host controllers

Legacy PCI host controllers (ie host controllers that set-up the PCI bus
through the ARM pci_common_init() API) are currently relying on
pci_fixup_irqs() to assign legacy PCI irqs to devices. This is not ideal
in that pci_fixup_irqs() assigns IRQs for all PCI devices present in a given
system some of which may well be enabled by the time pci_fixup_irqs() is
called (ie a system with multiple host controllers). With the introduction
of struct pci_host_bridge.(*map_irq) pointer it is possible to assign IRQs
for all devices originating from a PCI host bridge at probe time; this is
implemented through pci_assign_irq() that relies on the struct
pci_host_bridge.map_irq pointer to map IRQ for a given device.

The benefits this brings are twofold:

- the IRQ for a device is assigned once at probe time
- the IRQ assignment works also for hotplugged devices

Remove pci_fixup_irqs() call from bios32 code and rely on pci_assign_irq()
to carry out the IRQ mapping at device probe time.

The map_irq() and swizzle_irq() struct pci_host_bridge callbacks are set-up
in the struct pci_host_bridge created in the bios32 pcibios_init_hw()
function and mach-* code paths (for PCI mach implementations that require a
specific struct hw_pci.(*scan) function callback).

Signed-off-by: Lorenzo Pieralisi <[email protected]>
[bhelgaas: folded in fixes from Lorenzo:
http://lkml.kernel.org/r/20170701140629.GC8977@red-moon]
Signed-off-by: Bjorn Helgaas <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>

show more ...

ARM/PCI: Convert PCI scan API to pci_scan_root_bus_bridge()

The introduction of pci_scan_root_bus_bridge() provides a PCI core API to
scan a PCI root bus backed by an already initialized struct pci_

ARM/PCI: Convert PCI scan API to pci_scan_root_bus_bridge()

The introduction of pci_scan_root_bus_bridge() provides a PCI core API to
scan a PCI root bus backed by an already initialized struct pci_host_bridge
object, which simplifies the bus scan interface and makes the PCI scan root
bus interface easier to generalize as members are added to the struct
pci_host_bridge.

Convert ARM bios32 code to pci_scan_root_bus_bridge() to improve the PCI
root bus scanning interface.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
[bhelgaas: fold in warning fix from Arnd Bergmann <[email protected]>:
http://lkml.kernel.org/r/[email protected]]
[bhelgaas: set bridge->ops for mv78xx0]
[bhelgaas: fold in fixes from Lorenzo Pieralisi <[email protected]>:
http://lkml.kernel.org/r/20170701135457.GB8977@red-moon]
Signed-off-by: Bjorn Helgaas <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Cc: Andrew Lunn <[email protected]>

show more ...

ARM/PCI: Use generic pci_mmap_resource_range()

Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

PCI: Add BAR index argument to pci_mmap_page_range()

In all cases we know which BAR it is. Passing it in means that arch code
(or generic code; watch this space) won't have to go looking for it aga

PCI: Add BAR index argument to pci_mmap_page_range()

In all cases we know which BAR it is. Passing it in means that arch code
(or generic code; watch this space) won't have to go looking for it again.

Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

ARM/PCI: Remove arch-specific pcibios_enable_device()

On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from
firmware. Previously we did not insert those resources into the resource
tr

ARM/PCI: Remove arch-specific pcibios_enable_device()

On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from
firmware. Previously we did not insert those resources into the resource
tree, so we had to skip pci_enable_resources() because it fails if
resources are not in the resource tree.

Now that we *do* insert resources even when PCI_PROBE_ONLY is set, we no
longer need the ARM-specific pcibios_enable_device(). Remove it so we
use the generic version.

[bhelgaas: changelog]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Will Deacon <[email protected]>
CC: Arnd Bergmann <[email protected]>
CC: Russell King <[email protected]>

show more ...

ARM/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
but when PCI_PROBE_ONLY is set, we treat those resources as immutab

ARM/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups

We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
but when PCI_PROBE_ONLY is set, we treat those resources as immutable and
don't call pci_bus_assign_resources(), so the resources aren't put in the
resource tree.

When the resources aren't in the tree, they don't show up in /proc/iomem,
we can't detect conflicts, and we need special cases elsewhere for
PCI_PROBE_ONLY or resources without a parent pointer.

Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.

If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix
the conflicts. Previously we didn't notice the conflicts, but now we will,
which may expose new failures.

[bhelgaas: changelog, add resource comment, remove size/assign comments]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Russell King <[email protected]>

show more ...

ARM: Make PCI I/O space optional

For callers of pci_common_init_dev(), we previously always required a PCI
I/O port resource. If the caller's ->setup() function had added an I/O
resource, we used t

ARM: Make PCI I/O space optional

For callers of pci_common_init_dev(), we previously always required a PCI
I/O port resource. If the caller's ->setup() function had added an I/O
resource, we used that; otherwise, we added a default 64K I/O port space
for it.

There are PCI host bridges that do not support I/O port space, and we
should not add fictitious spaces for them.

If a caller sets struct hw_pci.io_optional, assume it is responsible for
adding any I/O port resource it desires, and do not add any default I/O
port space.

Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

ARM: 8554/1: kernel: pci: remove pci=firmware command line parameter handling

According to kernel documentation, the pci=firmware command line
parameter is only meant to be used on IXP2000 ARM platf

ARM: 8554/1: kernel: pci: remove pci=firmware command line parameter handling

According to kernel documentation, the pci=firmware command line
parameter is only meant to be used on IXP2000 ARM platforms to prevent
the kernel from assigning PCI resources configured by the bootloader.

Since the IXP2000 ARM platforms support has been removed from the
kernel in commit:

commit c65f2abf54a6 ("ARM: remove ixp23xx and ixp2000 platforms")

its platforms specific kernel parameters should be removed
too from the kernel documentation along with the kernel code
currently handling them in that they have just become obsolete.

This patch removes the pci=firmware command line parameter handling
from ARM code and the related kernel parameters documentation
section.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Acked-by: Lennert Buytenhek <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Lennert Buytenhek <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM/PCI: Move align_resource function pointer to pci_host_bridge structure

Commit b3a72384fe29 ("ARM/PCI: Replace pci_sys_data->align_resource with
global function pointer") introduced an ARM-specif

ARM/PCI: Move align_resource function pointer to pci_host_bridge structure

Commit b3a72384fe29 ("ARM/PCI: Replace pci_sys_data->align_resource with
global function pointer") introduced an ARM-specific align_resource()
function pointer. This is not portable to other arches and doesn't work
for platforms with two different PCIe host bridge controllers.

Move the function pointer to the pci_host_bridge structure so each host
bridge driver can specify its own align_resource() function.

Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>

show more ...

ARM/PCI: Replace pci_sys_data->align_resource with global function pointer

dw_pcie_host_init() creates the PCI host bridge with pci_common_init_dev(),
an ARM-specific function that supplies the ARM-

ARM/PCI: Replace pci_sys_data->align_resource with global function pointer

dw_pcie_host_init() creates the PCI host bridge with pci_common_init_dev(),
an ARM-specific function that supplies the ARM-specific pci_sys_data
structure as the PCI "sysdata". To use dw_pcie_host_init() on other
architectures, we will copy the internals of pci_common_init_dev() into
pcie-designware.c instead of calling it, and dw_pcie_host_init() will
supply the DesignWare pcie_port structure as "sysdata".

Most ARM "sysdata" users are specific to non-DesignWare host bridges;
they'll be unaffected because those bridges will continue to have the ARM
pci_sys_data. Most of the rest are ARM-generic functions called by
pci_common_init_dev(); these will be unaffected because dw_pcie_host_init()
will no longer call pci_common_init().

But the ARM pcibios_align_resource() can be called by the PCI core for any
bridge, so it can't depend on sysdata since it may be either pci_sys_data
or pcie_port.

Remove the pcibios_align_resource() dependency on sysdata by replacing the
pci_sys_data->align_resource pointer with a global function pointer.

This is less general (we can no longer have per-host bridge
align_resource() methods), but the pci_sys_data->align_resource pointer was
used only by Marvell (see mvebu_pcie_enable()), so this would only be a
problem if we had a system with a combination of Marvell and other host
bridges

[bhelgaas: changelog]
Signed-off-by: Gabriele Paoloni <[email protected]>
Signed-off-by: Zhou Wang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Pratyush Anand <[email protected]>

show more ...

ARM/PCI: Remove msi_controller from struct pci_sys_data

ARM now uses pci_bus->msi to store the msi_controller pointer, so we don't
need to save it in struct pci_sys_data, and we don't need to implem

ARM/PCI: Remove msi_controller from struct pci_sys_data

ARM now uses pci_bus->msi to store the msi_controller pointer, so we don't
need to save it in struct pci_sys_data, and we don't need to implement
pcibios_msi_controller() to get it out of pci_sys_data.

Remove msi_controller from struct pci_sys_data and
pcibios_msi_controller().

[bhelgaas: changelog, split into separate patch]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Jingoo Han <[email protected]>

show more ...

ARM/PCI, designware, xilinx: Use pci_scan_root_bus_msi()

ARM previously stored the msi_controller pointer in its sysdata, struct
pci_sys_data, and implemented pcibios_msi_controller() to retrieve it

ARM/PCI, designware, xilinx: Use pci_scan_root_bus_msi()

ARM previously stored the msi_controller pointer in its sysdata, struct
pci_sys_data, and implemented pcibios_msi_controller() to retrieve it.
That made PCI host controller drivers specific to ARM because they had to
put the msi_controller pointer in the ARM-specific pci_sys_data.

There is now a generic mechanism, pci_scan_root_bus_msi(), for giving the
msi_controller pointer to the PCI core. Use this for all ARM systems and
for the DesignWare and Xilinx PCI host controller drivers.

This removes an ARM dependency from the DesignWare, DRA7xx, EXYNOS, i.MX6,
Keystone, Layerscape, SPEAr13xx, and Xilinx drivers.

[bhelgaas: changelog, split into separate patch]
Suggested-by: Russell King <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Jingoo Han <[email protected]>
CC: Pratyush Anand <[email protected]>
CC: Arnd Bergmann <[email protected]>
CC: Simon Horman <[email protected]>
CC: Russell King <[email protected]>
CC: Thomas Petazzoni <[email protected]>
CC: Thierry Reding <[email protected]>
CC: Michal Simek <[email protected]>
CC: Marc Zyngier <[email protected]>

show more ...

ARM/PCI: Replace panic with WARN messages on failures

In the ARM PCI bios32 layer, failures to dynamically allocate pci_sys_data
for a PCI bus, or a PCI bus scan failure have to be considered seriou

ARM/PCI: Replace panic with WARN messages on failures

In the ARM PCI bios32 layer, failures to dynamically allocate pci_sys_data
for a PCI bus, or a PCI bus scan failure have to be considered serious
warnings but they should not trigger a system panic so that at least the
system is given a chance to be debugged.

This patch replaces the panic statements with WARN() messages to improve
error reporting in the ARM PCI bios32 layer.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Jingoo Han <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
CC: Russell King <[email protected]>
CC: Marc Zyngier <[email protected]>

show more ...

ARM/PCI: Set MPS before pci_bus_add_devices()

The MPS configuration should be done *before* pci_bus_add_devices(). After
pci_bus_add_devices(), drivers may be bound to devices, and the PCI core
sho

ARM/PCI: Set MPS before pci_bus_add_devices()

The MPS configuration should be done *before* pci_bus_add_devices(). After
pci_bus_add_devices(), drivers may be bound to devices, and the PCI core
shouldn't touch device configuration while a driver owns the device.

[bhelgaas: remove check for bus being non-NULL]
Reported-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Murali Karicheri <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

ARM: 8293/1: kernel: fix pci_mmap_page_range() offset calculation

The pci_mmap_page_range() API should be written to expect offset
values representing PCI memory resource addresses as seen by user
s

ARM: 8293/1: kernel: fix pci_mmap_page_range() offset calculation

The pci_mmap_page_range() API should be written to expect offset
values representing PCI memory resource addresses as seen by user
space, through the pci_resource_to_user() API.

ARM relies on the standard implementation of pci_resource_to_user()
which actually is an identity map and exports to user space
PCI memory resources as they are stored in PCI devices resources
structures, which represent CPU physical addresses (fixed-up using
BUS to CPU address conversions) not PCI bus addresses.

Therefore, on ARM platforms where the mapping between CPU and BUS
address is not a 1:1 the current pci_mmap_page_range() implementation is
erroneous, in that an additional shift is applied to an already fixed-up
offset passed from userspace.

Hence, this patch removes the mem_offset from the pgoff calculation
since the offset as passed from user space already represents the CPU
physical address corresponding to the resource to be mapped, ie no
additional offset should be applied.

Cc: Arnd Bergmann <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

PCI: Use common resource list management code instead of private implementation

Use common resource list management data structure and interfaces
instead of private implementation.

Signed-off-by: J

PCI: Use common resource list management code instead of private implementation

Use common resource list management data structure and interfaces
instead of private implementation.

Signed-off-by: Jiang Liu <[email protected]>
Acked-by: Will Deacon <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ARM/PCI: Move to generic PCI domains

Most if not all ARM PCI host controller device drivers either ignore the
domain field in the pci_sys_data structure or just increment it every time
a host contro

ARM/PCI: Move to generic PCI domains

Most if not all ARM PCI host controller device drivers either ignore the
domain field in the pci_sys_data structure or just increment it every time
a host controller is probed, using it as a domain counter.

Therefore, instead of relying on pci_sys_data to stash the domain number in
a standard location, ARM pcibios code can be moved to the newly introduced
generic PCI domains code, implemented in commits:

41e5c0f81d3e ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()")
670ba0c8883b ("PCI: Add generic domain handling")

ARM code is made to select PCI_DOMAINS_GENERIC by default, which builds
core PCI code that assigns the domain number through the generic function:

void pci_bus_assign_domain_nr(...)

that relies on a DT property to define the domain number or falls back to a
counter according to a predefined logic; its usage replaces the current
domain assignment code in PCI host controllers present in the kernel.

Tested-by: Lucas Stach <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Yijing Wang <[email protected]>
Reviewed-By: Jason Gunthorpe <[email protected]> # mvebu
Acked-by: Russell King <[email protected]>
Acked-by: Lucas Stach <[email protected]>
Acked-by: Jingoo Han <[email protected]>
Acked-by: Phil Edworthy <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
CC: Mohit Kumar <[email protected]>

show more ...

ARM/PCI: Remove unused pcibios_add_bus() and pcibios_remove_bus()

There are no users of the struct hw_pci.add_bus() or .remove_bus() methods,
so remove the pointers from hw_pci. That makes pcibios_

ARM/PCI: Remove unused pcibios_add_bus() and pcibios_remove_bus()

There are no users of the struct hw_pci.add_bus() or .remove_bus() methods,
so remove the pointers from hw_pci. That makes pcibios_add_bus() and
pcibios_remove_bus() themselves superfluous, so remove them as well.

[bhelgaas: changelog]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

ARM/PCI: Save MSI controller in pci_sys_data

Currently ARM associates an MSI controller with a PCI bus by defining
pcibios_add_bus() and using it to call a struct hw_pci.add_bus() method.
That metho

ARM/PCI: Save MSI controller in pci_sys_data

Currently ARM associates an MSI controller with a PCI bus by defining
pcibios_add_bus() and using it to call a struct hw_pci.add_bus() method.
That method sets the struct pci_bus "msi" member. That's unwieldy and
unnecessarily couples MSI with the PCI enumeration code.

On ARM, all devices under the same PCI host bridge share an MSI controller,
so add an msi_controller pointer to the struct pci_sys_data and implement
pcibios_msi_controller() to retrieve it.

This is a step toward moving the msi_controller pointer into the generic
struct pci_host_bridge.

[bhelgaas: changelog, take pci_dev instead of pci_bus]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...