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

Revert "PCI: qcom: Disable write access to read only registers for IP v2.3.3"

2023-10-10T19:45:00+00:00

This reverts commit 3a4ecf4c9d793d0ecd07fc49cd76a2e24652d3b7 which is
commit a33d700e8eea76c62120cb3dbf5e01328f18319a upstream.

It was applied to the incorrect function as the original function the
commit changed is not in this kernel branch.

Reported-by: Ben Hutchings 
Link: https://lore.kernel.org/r/f23affddab4d8b3cc07508f2d8735d88d823821d.camel@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Use u32 variable to access 32-bit registers

2023-08-11T09:45:21+00:00

commit 8962b2cb39119cbda4fc69a1f83957824f102f81 upstream.

Previously u16 variables were used to access 32-bit registers, this
resulted in not all of the data being read from the registers. Also
the left shift of more than 16-bits would result in moving data out
of the variable. Use u32 variables to access 32-bit registers

Link: https://lore.kernel.org/r/20230418074700.1083505-10-rick.wertenbroek@gmail.com
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Tested-by: Damien Le Moal 
Signed-off-by: Rick Wertenbroek 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Damien Le Moal 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Fix legacy IRQ generation for RK3399 PCIe endpoint core

2023-08-11T09:45:21+00:00

commit 166e89d99dd85a856343cca51eee781b793801f2 upstream.

Fix legacy IRQ generation for RK3399 PCIe endpoint core according to
the technical reference manual (TRM). Assert and deassert legacy
interrupt (INTx) through the legacy interrupt control register
("PCIE_CLIENT_LEGACY_INT_CTRL") instead of manually generating a PCIe
message. The generation of the legacy interrupt was tested and validated
with the PCIe endpoint test driver.

Link: https://lore.kernel.org/r/20230418074700.1083505-8-rick.wertenbroek@gmail.com
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Tested-by: Damien Le Moal 
Signed-off-by: Rick Wertenbroek 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Damien Le Moal 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Add poll and timeout to wait for PHY PLLs to be locked

2023-08-11T09:45:21+00:00

commit 9dd3c7c4c8c3f7f010d9cdb7c3f42506d93c9527 upstream.

The RK3399 PCIe controller should wait until the PHY PLLs are locked.
Add poll and timeout to wait for PHY PLLs to be locked. If they cannot
be locked generate error message and jump to error handler. Accessing
registers in the PHY clock domain when PLLs are not locked causes hang
The PHY PLLs status is checked through a side channel register.
This is documented in the TRM section 17.5.8.1 "PCIe Initialization
Sequence".

Link: https://lore.kernel.org/r/20230418074700.1083505-5-rick.wertenbroek@gmail.com
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Tested-by: Damien Le Moal 
Signed-off-by: Rick Wertenbroek 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Damien Le Moal 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Write PCI Device ID to correct register

2023-08-11T09:45:21+00:00

commit 1f1c42ece18de365c976a060f3c8eb481b038e3a upstream.

Write PCI Device ID (DID) to the correct register. The Device ID was not
updated through the correct register. Device ID was written to a read-only
register and therefore did not work. The Device ID is now set through the
correct register. This is documented in the RK3399 TRM section 17.6.6.1.1

Link: https://lore.kernel.org/r/20230418074700.1083505-3-rick.wertenbroek@gmail.com
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Tested-by: Damien Le Moal 
Signed-off-by: Rick Wertenbroek 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Damien Le Moal 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Assert PCI Configuration Enable bit after probe

2023-08-11T09:45:21+00:00

commit f397fd4ac1fa3afcabd8cee030f953ccaed2a364 upstream.

Assert PCI Configuration Enable bit after probe. When this bit is left to
0 in the endpoint mode, the RK3399 PCIe endpoint core will generate
configuration request retry status (CRS) messages back to the root complex.
Assert this bit after probe to allow the RK3399 PCIe endpoint core to reply
to configuration requests from the root complex.
This is documented in section 17.5.8.1.2 of the RK3399 TRM.

Link: https://lore.kernel.org/r/20230418074700.1083505-4-rick.wertenbroek@gmail.com
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Tested-by: Damien Le Moal 
Signed-off-by: Rick Wertenbroek 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Damien Le Moal 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: qcom: Disable write access to read only registers for IP v2.3.3

2023-08-11T09:45:21+00:00

commit a33d700e8eea76c62120cb3dbf5e01328f18319a upstream.

In the post init sequence of v2.9.0, write access to read only registers
are not disabled after updating the registers. Fix it by disabling the
access after register update.

Link: https://lore.kernel.org/r/20230619150408.8468-2-manivannan.sadhasivam@linaro.org
Fixes: 5d76117f070d ("PCI: qcom: Add support for IPQ8074 PCIe controller")
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Lorenzo Pieralisi 
Cc: 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Fix a race condition bug in hv_pci_query_relations()

2023-06-28T08:15:28+00:00

commit 440b5e3663271b0ffbd4908115044a6a51fb938b upstream.

Since day 1 of the driver, there has been a race between
hv_pci_query_relations() and survey_child_resources(): during fast
device hotplug, hv_pci_query_relations() may error out due to
device-remove and the stack variable 'comp' is no longer valid;
however, pci_devices_present_work() -> survey_child_resources() ->
complete() may be running on another CPU and accessing the no-longer-valid
'comp'. Fix the race by flushing the workqueue before we exit from
hv_pci_query_relations().

Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Signed-off-by: Dexuan Cui 
Reviewed-by: Michael Kelley 
Acked-by: Lorenzo Pieralisi 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230615044451.5580-2-decui@microsoft.com
Signed-off-by: Wei Liu 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Fix interrupt mapping for multi-MSI

2022-07-29T15:10:38+00:00

commit a2bad844a67b1c7740bda63e87453baf63c3a7f7 upstream.

According to Dexuan, the hypervisor folks beleive that multi-msi
allocations are not correct.  compose_msi_msg() will allocate multi-msi
one by one.  However, multi-msi is a block of related MSIs, with alignment
requirements.  In order for the hypervisor to allocate properly aligned
and consecutive entries in the IOMMU Interrupt Remapping Table, there
should be a single mapping request that requests all of the multi-msi
vectors in one shot.

Dexuan suggests detecting the multi-msi case and composing a single
request related to the first MSI.  Then for the other MSIs in the same
block, use the cached information.  This appears to be viable, so do it.

4.19 backport - add hv_msi_get_int_vector helper function. Fixed merge
conflict due to delivery_mode name change (APIC_DELIVERY_MODE_FIXED
is the value given to dest_Fixed). Removed unused variable in
hv_compose_msi_msg. Fixed reference to msi_desc->pci to point to
the same is_msix variable. Removed changes to compose_msi_req_v3 since
it doesn't exist yet.

Suggested-by: Dexuan Cui 
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Dexuan Cui 
Tested-by: Michael Kelley 
Link: https://lore.kernel.org/r/1652282599-21643-1-git-send-email-quic_jhugo@quicinc.com
Signed-off-by: Wei Liu 
Signed-off-by: Carl Vanderlip 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()

2022-07-29T15:10:38+00:00

commit b4b77778ecc5bfbd4e77de1b2fd5c1dd3c655f1f upstream.

Currently if compose_msi_msg() is called multiple times, it will free any
previous IRTE allocation, and generate a new allocation.  While nothing
prevents this from occurring, it is extraneous when Linux could just reuse
the existing allocation and avoid a bunch of overhead.

However, when future IRTE allocations operate on blocks of MSIs instead of
a single line, freeing the allocation will impact all of the lines.  This
could cause an issue where an allocation of N MSIs occurs, then some of
the lines are retargeted, and finally the allocation is freed/reallocated.
The freeing of the allocation removes all of the configuration for the
entire block, which requires all the lines to be retargeted, which might
not happen since some lines might already be unmasked/active.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Dexuan Cui 
Tested-by: Dexuan Cui 
Tested-by: Michael Kelley 
Link: https://lore.kernel.org/r/1652282582-21595-1-git-send-email-quic_jhugo@quicinc.com
Signed-off-by: Wei Liu 
Signed-off-by: Carl Vanderlip 
Signed-off-by: Greg Kroah-Hartman