linux-stable.git/drivers/pci/controller, branch v4.19.53

PCI: xilinx: Check for __get_free_pages() failure

2019-06-15T09:54:10+00:00

[ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]

If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
dereference.

Signed-off-by: Kangjie Lu 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Steven Price 
Reviewed-by: Mukesh Ojha 
Signed-off-by: Sasha Levin

PCI: rcar: Fix 64bit MSI message address handling

2019-06-15T09:54:09+00:00

[ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]

The MSI message address in the RC address space can be 64 bit. The
R-Car PCIe RC supports such a 64bit MSI message address as well.
The code currently uses virt_to_phys(__get_free_pages()) to obtain
a reserved page for the MSI message address, and the return value
of which can be a 64 bit physical address on 64 bit system.

However, the driver only programs PCIEMSIALR register with the bottom
32 bits of the virt_to_phys(__get_free_pages()) return value and does
not program the top 32 bits into PCIEMSIAUR, but rather programs the
PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
SoCs, however may fail on new 64 bit R-Car SoCs.

Since from a PCIe controller perspective, an inbound MSI is a memory
write to a special address (in case of this controller, defined by
the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
never hits the DRAM _and_ because allocation of an MSI by a PCIe card
driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
cause memory corruption or other issues.

There is however the possibility that if virt_to_phys(__get_free_pages())
returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
to 0x0 _and_ if the system had physical RAM at the address matching the
value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
physical address matching the value of PCIEMSIALR and a remote write to
such a buffer by a PCIe card would trigger a spurious MSI.

Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
Signed-off-by: Marek Vasut 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
Cc: Geert Uytterhoeven 
Cc: Phil Edworthy 
Cc: Simon Horman 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Sasha Levin

PCI: rcar: Fix a potential NULL pointer dereference

2019-06-15T09:54:09+00:00

[ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]

In case __get_free_pages() fails and returns NULL, fix the return
value to -ENOMEM and release resources to avoid dereferencing a
NULL pointer.

Signed-off-by: Kangjie Lu 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Ulrich Hecht 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Signed-off-by: Sasha Levin

PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64

2019-06-15T09:54:08+00:00

[ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]

hook_fault_code() is an ARM32 specific API for hooking into data abort.

AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as
arch) rely on pci-keystone.c but on them the enumeration of a
non-present BDF does not trigger a bus error, so the fixup exception
provided by calling hook_fault_code() is not needed and can be guarded
with CONFIG_ARM.

Signed-off-by: Kishon Vijay Abraham I 
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

PCI: designware-ep: Use aligned ATU window for raising MSI interrupts

2019-06-15T09:54:06+00:00

[ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ]

Certain platforms like K2G reguires the outbound ATU window to be
aligned. The alignment size is already present in mem->page_size.
Use the alignment size present in mem->page_size to configure an
aligned ATU window. In order to raise an interrupt, CPU has to write
to address offset from the start of the window unlike before where
writes were always to the beginning of the ATU window.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi()

2019-06-15T09:54:05+00:00

[ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ]

To avoid a memory leak, free the page allocated for MSI IRQ in
dw_pcie_free_msi().

Signed-off-by: Jisheng Zhang 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Acked-by: Gustavo Pimentel 
Signed-off-by: Sasha Levin

PCI: dwc: Free MSI in dw_pcie_host_init() error path

2019-06-15T09:54:05+00:00

[ Upstream commit 9e2b5de5604a6ff2626c51e77014d92c9299722c ]

If we ever did MSI-related initializations, we need to call
dw_pcie_free_msi() in the error code path.

Remove the IS_ENABLED(CONFIG_PCI_MSI) check for MSI init because
pci_msi_enabled() already has a stub for !CONFIG_PCI_MSI.

Signed-off-by: Jisheng Zhang 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Acked-by: Gustavo Pimentel 
Signed-off-by: Sasha Levin

PCI: rcar: Add the initialization of PCIe link in resume_noirq()

2019-05-25T16:23:38+00:00

commit be20bbcb0a8cb5597cc62b3e28d275919f3431df upstream.

Reestablish the PCIe link very early in the resume process in case it
went down to prevent PCI accesses from hanging the bus. Such accesses
can happen early in the PCI resume process, as early as the
SUSPEND_RESUME_NOIRQ step, thus the link must be reestablished in the
driver resume_noirq() callback.

Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
Signed-off-by: Kazufumi Ikeda 
Signed-off-by: Gaku Inami 
Signed-off-by: Marek Vasut 
[lorenzo.pieralisi@arm.com: reformatted commit log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Wolfram Sang 
Cc: stable@vger.kernel.org
Cc: Geert Uytterhoeven 
Cc: Phil Edworthy 
Cc: Simon Horman 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

2019-05-16T17:41:32+00:00

commit 340d455699400f2c2c0f9b3f703ade3085cdb501 upstream.

When we hot-remove a device, usually the host sends us a PCI_EJECT message,
and a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.

When we execute the quick hot-add/hot-remove test, the host may not send
us the PCI_EJECT message if the guest has not fully finished the
initialization by sending the PCI_RESOURCES_ASSIGNED* message to the
host, so it's potentially unsafe to only depend on the
pci_destroy_slot() in hv_eject_device_work() because the code path

create_root_hv_pci_bus()
 -> hv_pci_assign_slots()

is not called in this case. Note: in this case, the host still sends the
guest a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.

In the quick hot-add/hot-remove test, we can have such a race before
the code path

pci_devices_present_work()
 -> new_pcichild_device()

adds the new device into the hbus->children list, we may have already
received the PCI_EJECT message, and since the tasklet handler

hv_pci_onchannelcallback()

may fail to find the "hpdev" by calling

get_pcichild_wslot(hbus, dev_message->wslot.slot)

hv_pci_eject_device() is not called; Later, by continuing execution

create_root_hv_pci_bus()
 -> hv_pci_assign_slots()

creates the slot and the PCI_BUS_RELATIONS message with
bus_rel->device_count == 0 removes the device from hbus->children, and
we end up being unable to remove the slot in

hv_pci_remove()
 -> hv_pci_remove_slots()

Remove the slot in pci_devices_present_work() when the device
is removed to address this race.

pci_devices_present_work() and hv_eject_device_work() run in the
singled-threaded hbus->wq, so there is not a double-remove issue for the
slot.

We cannot offload hv_pci_eject_device() from hv_pci_onchannelcallback()
to the workqueue, because we need the hv_pci_onchannelcallback()
synchronously call hv_pci_eject_device() to poll the channel
ringbuffer to work around the "hangs in hv_compose_msi_msg()" issue
fixed in commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in
hv_compose_msi_msg()")

Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Dexuan Cui 
[lorenzo.pieralisi@arm.com: rewritten commit log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Stephen Hemminger 
Reviewed-by:  Michael Kelley 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Add hv_pci_remove_slots() when we unload the driver

2019-05-16T17:41:31+00:00

commit 15becc2b56c6eda3d9bf5ae993bafd5661c1fad1 upstream.

When we unload the pci-hyperv host controller driver, the host does not
send us a PCI_EJECT message.

In this case we also need to make sure the sysfs PCI slot directory is
removed, otherwise a command on a slot file eg:

"cat /sys/bus/pci/slots/2/address"

will trigger a

"BUG: unable to handle kernel paging request"

and, if we unload/reload the driver several times we would end up with
stale slot entries in PCI slot directories in /sys/bus/pci/slots/

root@localhost:~# ls -rtl  /sys/bus/pci/slots/
total 0
drwxr-xr-x 2 root root 0 Feb  7 10:49 2
drwxr-xr-x 2 root root 0 Feb  7 10:49 2-1
drwxr-xr-x 2 root root 0 Feb  7 10:51 2-2

Add the missing code to remove the PCI slot and fix the current
behaviour.

Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Dexuan Cui 
[lorenzo.pieralisi@arm.com: reformatted the log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Stephen Hemminger 
Reviewed-by: Michael Kelley 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman