linux.git/drivers/pci, branch v4.14.34

PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L

2018-03-28T16:24:32+00:00

commit 1903be8222b7c278ca897c129ce477c1dd6403a8 upstream.

The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
other Marvel controllers this needs a function 1 DMA alias quirk.

Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
already is listed with a function 1 DMA alias quirk.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede 
Acked-by: Bjorn Helgaas 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures

2018-03-24T10:01:26+00:00

[ Upstream commit 83c75ddd816e979802bd244ad494139f28152921 ]

rcar_pcie_parse_request_of_pci_ranges() can fail and return an error
code, but this is not checked nor handled.

Fix this by adding the missing error handling.

Fixes: 5d2917d469faab72 ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: endpoint: Fix find_first_zero_bit() usage

2018-03-24T10:01:26+00:00

[ Upstream commit 35ad61921f495ee14915d185de79478c1737b4da ]

find_first_zero_bit()'s parameter 'size' is defined in bits,
not in bytes.

Calling find_first_zero_bit() with the wrong size unit
will lead to insidious bugs.

Fix this by calling find_first_zero_bit() with size BITS_PER_LONG,
rather than sizeof() and add missing find_first_zero_bit() return
handling.

Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions")
Signed-off-by: Niklas Cassel 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit

2018-03-24T10:01:26+00:00

[ Upstream commit a134a457ed985dca8cce7ac4ea66129ea70eba73 ]

->get_msi() now checks MSI_EN bit in the MSI CAPABILITY register to
find whether the host supports MSI instead of using the
MSI ADDRESS in the MSI CAPABILITY register.

This fixes the issue with the following sequence
  'modprobe pci_endpoint_test' enables MSI
  'rmmod pci_endpoint_test' disables MSI but MSI address (in EP's
	capability register) has a valid value
  'modprobe pci_endpoint_test no_msi=1' - Since MSI address (in EP's
	capability register) has a valid value (set during the previous
	insertion of the module), EP thinks host supports MSI.

Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: dwc: Fix enumeration end when reaching root subordinate

2018-03-15T09:54:32+00:00

commit fc110ebdd014dd1368c98e7685b47789c31fab42 upstream.

The subordinate value indicates the highest bus number which can be
reached downstream though a certain device.

Commit a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent") ensures that downstream devices cannot assign busnumbers higher
than the upstream device subordinate number, which was indeed illogical.

By default, dw_pcie_setup_rc() inits the Root Complex subordinate to a
value of 0x01.

Due to this combined with above commit, enumeration stops digging deeper
downstream as soon as bus num 0x01 has been assigned, which is always the
case for a bridge device.

This results in all devices behind a bridge bus remaining undetected, as
these would be connected to bus 0x02 or higher.

Fix this by initializing the RC to a subordinate value of 0xff, which is
not altering hardware behaviour in any way, but informs probing function
pci_scan_bridge() later on which reads this value back from register.

The following nasty errors during boot are also fixed by this:

  pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01])
  ...
  pci_bus 0000:03: [bus 03] partially hidden behind bridge 0000:01 [bus 01]
  ...
  pci_bus 0000:04: [bus 04] partially hidden behind bridge 0000:01 [bus 01]
  ...
  pci_bus 0000:05: [bus 05] partially hidden behind bridge 0000:01 [bus 01]
  pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
  pci_bus 0000:02: busn_res: can not insert [bus 02-05] under [bus 01] (conflicts with (null) [bus 01])
  pci_bus 0000:02: [bus 02-05] partially hidden behind bridge 0000:01 [bus 01]

Fixes: a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent")
Tested-by: Niklas Cassel 
Tested-by: Fabio Estevam 
Tested-by: Sebastian Reichel 
Signed-off-by: Koen Vandeputte 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Mika Westerberg 
Acked-by: Lucas Stach 
Cc: stable@vger.kernel.org	# v4.15+
Cc: Binghui Wang 
Cc: Jesper Nilsson 
Cc: Jianguo Sun 
Cc: Jingoo Han 
Cc: Kishon Vijay Abraham I 
Cc: Lucas Stach 
Cc: Mika Westerberg 
Cc: Minghuan Lian 
Cc: Mingkai Hu 
Cc: Murali Karicheri 
Cc: Pratyush Anand 
Cc: Richard Zhu 
Cc: Roy Zang 
Cc: Shawn Guo 
Cc: Stanimir Varbanov 
Cc: Thomas Petazzoni 
Cc: Xiaowei Song 
Cc: Zhou Wang 
Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Deal with missing root ports in link state handling

2018-03-09T06:41:25+00:00

commit ee8bdfb6568d86bb93f55f8d99c4c643e77304ee upstream.

Even though it is unconventional, some PCIe host implementations omit the
root ports entirely, and simply consist of a host bridge (which is not
modeled as a device in the PCI hierarchy) and a link.

When the downstream device is an endpoint, our current code does not seem
to mind this unusual configuration. However, when PCIe switches are
involved, the ASPM code assumes that any downstream switch port has a
parent, and blindly dereferences the bus->parent->self field of the pci_dev
struct to chain the downstream link state to the link state of the root
port. Given that the root port is missing, the link is not modeled at all,
and nor is the link state, and attempting to access it results in a NULL
pointer dereference and a crash.

Avoid this by allowing the link state chain to terminate at the downstream
port if no root port exists.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI/cxgb4: Extend T3 PCI quirk to T4+ devices

2018-02-28T09:19:41+00:00

commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.

We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help.  The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.

The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.

The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor.  Thus PF4 can
be exported to a Virtual Machine and everything should work.

Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc:   # v4.9+
Signed-off-by: Casey Leedom 
Signed-off-by: Arjun Vynipadath 
Signed-off-by: Ganesh Goudar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

PCI: rcar: Fix use-after-free in probe error path

2018-02-25T10:08:03+00:00

[ Upstream commit 0c31f1d7be1b5c4858b1d714dcefa25f41428cab ]

If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
during probe on r8a7791/koelsch:

  rcar-pcie fe000000.pcie: PCIe link down
  Unable to handle kernel paging request at virtual address 6b6b6b6b

(seeing this message requires earlycon and keep_bootcon).

Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
embedded rcar_pcie object, so pci_free_resource_list() must not be called
afterwards.

To fix this, move the call to pci_free_resource_list() up, and update the
label name accordingly.

Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is inserted")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Bjorn Helgaas 
Acked-by: Simon Horman 
Acked-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: keystone: Fix interrupt-controller-node lookup

2018-02-22T14:42:27+00:00

commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.

Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.

To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.

Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable      # 3.18
Acked-by: Murali Karicheri 
Signed-off-by: Johan Hovold 
[lorenzo.pieralisi@arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Greg Kroah-Hartman

PCI: iproc: Fix NULL pointer dereference for BCMA

2018-02-22T14:42:27+00:00

commit 3b65ca50d24ce33cb92d88840e289135c92b40ed upstream.

With the inbound DMA mapping supported added, the iProc PCIe driver
parses DT property "dma-ranges" through call to
"of_pci_dma_range_parser_init()". In the case of BCMA, this results in a
NULL pointer deference due to a missing of_node.

Fix this by adding a guard in pcie-iproc-platform.c to only enable the
inbound DMA mapping logic when DT property "dma-ranges" is present.

Fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support")
Reported-by: Rafał Miłecki 
Signed-off-by: Ray Jui 
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi 
Tested-by: Rafał Miłecki 
cc:  # 4.10+
Signed-off-by: Greg Kroah-Hartman