| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git
# Conflicts:
# Documentation/devicetree/bindings/usb/am33xx-usb.txt
# Documentation/devicetree/bindings/usb/da8xx-usb.txt
|
|
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
|
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
|
|
A guest can wait indefinitely in wait_for_response() for the host to
send either a rescind message or a packet completion. If the
host does not send either, the guest can remain blocked with no
diagnostic indicating a reason.
This was observed during a guest kernel upgrade in which the
host-side application handling the PCI channel faulted, causing the
guest to never receive the completion request.
Add a warning in wait_for_response() when the wait exceeds
a timeout so that such a hang is visible in the guest's kernel log
and can be correlated with host-side state.
Suggested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
Signed-off-by: Sahil Chandna <sahilchandna@linux.microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
|
On Hyper-V guests each virtual PCI bus is enumerated by its own
hv_pci_probe() call. The probe performs several synchronous host
request/response exchanges while negotiating the protocol, querying bus
relations, entering D0, and reporting allocated resources. These waits
are latency-bound rather than CPU-bound.
hv_pci registers as an ordinary VMBus driver, so driver_register() walks
matching vPCI buses and probes them sequentially while the driver's
initcall runs. On guests that expose several devices, each through its
own vPCI bus, this serialization adds the host round-trip latencies to
device initialization.
Each bus is described by its own struct hv_pcibus_device, so
independent buses can be probed concurrently. Request asynchronous
probing via PROBE_PREFER_ASYNCHRONOUS, causing the driver core to
schedule matching buses for asynchronous probe work.
On an Azure Standard_L32s_v3 guest with five vPCI targets (four NVMe
controllers and one Mellanox VF), Linux 7.2.3 was tested with one warm-up
and three measured boots per variant. The median interval from the first
hv_pci_probe() entry to the last return decreased from 2847.968 ms to
2786.709 ms, a 61.259 ms (2.15%) improvement.
Co-developed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
Reviewed-by: Sahil Chandna <sahilchandna@linux.microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
|
- TBD
* pci/controller/xilinx-cpm:
PCI: xilinx-cpm: Add support for PCIe RP PERST# signal
dt-bindings: PCI: xilinx-versal-cpm: Add PERST# and reset support
|
|
- Use devm for clocks so they're automatically disabled, unprepared, and
released if errors happen during probe (Yuho Choi)
* pci/controller/xgene:
PCI: xgene: Use managed clock for PCIe controller
|
|
- Flush initiator posted writes before calling IRQ handler to work around a
Meteor Lake erratum, where a DMA completion MSI can arrive before the
completion queue in memory has been updated, resulting in an nvme 30
second stall before a QID timeout and possibly other similar problems
(Rickey Bartlett)
* pci/controller/vmd:
PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake
|
|
- Disable refclk on probe failure (Lad Prabhakar)
- Propagate platform_get_irq_byname() errors so probe deferral works
correctly (Lad Prabhakar)
- Tear down INTx handlers if subsequent initialization fails (Lad
Prabhakar)
- Add RZ/G3L (R9A08G046) DT and driver support (Biju Das)
* pci/controller/rzg3s-host:
PCI: rzg3s-host: Add support for RZ/G3L SoC
dt-bindings: PCI: renesas,r9a08g045s33-pcie: Document RZ/G3L SoC
PCI: rzg3s: Fix IRQ domain initialization error handling
PCI: rzg3s: Propagate platform_get_irq_byname() errors
PCI: rzg3s: Disable refclk on probe failure
|
|
- Fix a 64-bit type truncation in mtk_pcie_set_trans_table() to avoid
issues with windows above or larger than 4GB (Sreeraj S Kurup)
* pci/controller/mediatek-gen3:
PCI: mediatek-gen3: Fix 64-bit type truncation in mtk_pcie_set_trans_table()
|
|
- Find INTx DT property by 'interrupt-controller' name instead of assuming
it's the first child node (Zhengping Zhang)
* pci/controller/mediatek:
PCI: mediatek: Find INTx controller by property
|
|
- Limit Max_Read_Request_Size to 256 to avoid hardware erratum (Marek
Vasut)
- Add a .post_deinit() callback to handle dw_pcie_ep_init() failures (Marek
Vasut)
* pci/controller/dwc-rcar-gen4:
PCI: rcar-gen4: Use .post_deinit() to handle dw_pcie_ep_init() failures
PCI: dwc: Add dw_pcie_ep_ops->post_deinit() callback
PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes
|
|
- Only collect reset GPIOs from PCI bridge DT nodes to avoid stealing
resets used by downstream devices like USB controllers (Christopher
Obbard)
- Block accesses to downstream devices on link down to reduce a storm of
Completion Timeout AER interrupts (Qiang Yu)
- Skip system suspend/resume for firmware-managed PCIe, where firmware
manages clocks, regulators, resets, etc (Mrinmay Sarkar)
- Honor IOMMU provider's #iommu-cells in qcom_pcie_config_sid_1_9_0()
(Manivannan Sadhasivam)
* pci/controller/dwc-qcom:
PCI: qcom: Honor IOMMU provider's #iommu-cells in qcom_pcie_config_sid_1_9_0()
PCI: qcom: Skip system suspend/resume for firmware-managed PCIe
PCI: qcom: Block accesses to downstream devices on link down
PCI: qcom: Only check bridge nodes for PERST# GPIOs
|
|
- Remove device links to PHY, which are redundant because the PHY core
itself adds them (Vladimir Oltean)
* pci/controller/dwc-keystone:
PCI: keystone: Remove device links to PHY
|
|
- Fix pwrctrl device leak when .probe() PM runtime setup fail (hanzhijian)
- Improve i.MX95 Gen3 link stability by changing MPLLB_BANDWIDTH from
default 120 to 140 (Richard Zhu)
* pci/controller/dwc-imx6:
PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability
PCI: imx6: Fix pwrctrl device leak on PM runtime setup failure
|
|
- Remove device links to PHY, which are redundant because the PHY core
itself adds them (Vladimir Oltean)
- Fix optional clock leak when .probe() fails by using
devm_clk_get_optional_enabled() (Felix Gu)
* pci/controller/dwc-dra7xx:
PCI: dra7xx: Fix clock enable leak on probe failure
PCI: dra7xx: Remove device links to PHY
|
|
- Fix enum type mismatch warning in LTSSM debugfs (Hans Zhang)
- Remove device links to PHY, which are redundant because the PHY core
itself adds them (Vladimir Oltean)
- Return error (not success) from cdns_plat_pcie_probe() if
pm_runtime_get_sync() or cdns_pcie_ep_setup() failed (Vladimir Oltean)
* pci/controller/cadence:
PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()
PCI: cadence: Remove device links to PHY
PCI: cadence: Fix enum type mismatch warning in LTSSM debugfs
|
|
- Fix clk and PHY leaks in aspeed_pcie_port_init() error paths (Liu
Zhenlong)
* pci/controller/aspeed:
PCI: aspeed: Fix clk and PHY leak in aspeed_pcie_port_init() error paths
|
|
- Add missing headers transitively included by <linux/phy/phy.h> so these
can be removed from linux/phy/phy.h itself (Vladimir Oltean)
* pci/controller/misc:
PCI: Add missing headers transitively included by <linux/phy/phy.h>
|
|
The tegra as well as a few dwc PCI controller drivers uses PM runtime
operations without including the required <linux/pm_runtime.h> header.
Similarly, pcie-rockchip-host, pcie-starfive as well as a few dwc PCI
controllers use the regulator consumer API without including
<linux/regulator/consumer.h>.
pcie-spacemit-k1.c uses of_get_next_available_child() and of_node_put()
without including <linux/of.h>.
It seems these function prototypes were indirectly provided by
<linux/phy/phy.h>, mostly by mistake (none of the functions it exports
need it).
Before the PHY header can drop the unnecessary includes, make sure the
PCI controller drivers include what they use.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260810124315.433448-3-vladimir.oltean@nxp.com
|
|
The blamed commit functionally changed the error path of
cdns_pcie_host_probe(), now cdns_plat_pcie_probe().
When the old code path executed "goto err_get_sync", the PCIe controller
probe function propagated the pm_runtime_get_sync() error code. The new
code doesn't, and returns 0.
Similarly for the "goto err_init" previously triggered by
cdns_pcie_host_init() errors, and now triggered by
cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not
propagated and will result in probing success, which is incorrect.
Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260810124315.433448-2-vladimir.oltean@nxp.com
|
|
dra7xx_pcie_probe() enables the optional clock but never disables it
when probing fails afterwards.
Switch to devm_clk_get_optional_enabled(), which disables the clock
automatically on failure.
Fixes: 5af9405397bf ("PCI: dra7xx: Get an optional clock")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260822-dra7xx-v1-1-23e204d5548b@gmail.com
|
|
This is a full revert of commit 7a4db656a635 ("PCI: dra7xx: Create
functional dependency between PCIe and PHY").
The trouble with this is that a PHY consumer driver dereferences fields
from struct phy, which will become no longer possible.
Since commit 987351e1ea77 ("phy: core: Add consumer device link support")
from 2019, the PHY core also adds a device link to order PHY provider and
consumer suspend/resume operations. The reverted functionality is from 2017
and is redundant with the PHY core now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260912161440.1032188-3-vladimir.oltean@nxp.com
|
|
This is a partial revert of the device link pieces from commit
dfb80534692d ("PCI: cadence: Add generic PHY support to host and EP
drivers").
The trouble with this is that a PHY consumer driver dereferences fields
from struct phy, which will become no longer possible.
Since commit 987351e1ea77 ("phy: core: Add consumer device link support")
from 2019, the PHY core also adds a device link to order PHY provider and
consumer suspend/resume operations. The reverted functionality is from
2018 and is redundant with the PHY core now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260912161440.1032188-2-vladimir.oltean@nxp.com
|
|
This is a partial revert of the device link pieces from commit
49229238ab47 ("PCI: keystone: Cleanup PHY handling").
The trouble with this is that a PHY consumer driver dereferences fields
from struct phy, which will become no longer possible.
Since commit 987351e1ea77 ("phy: core: Add consumer device link support")
from 2019, the PHY core also adds a device link to order PHY provider and
consumer suspend/resume operations. The reverted functionality is from
2018 and is redundant with the PHY core now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260912161440.1032188-4-vladimir.oltean@nxp.com
|
|
Poor bandwidth margins are observed during i.MX95 Gen3 PCIe tests with the
default MPLLB_BANDWIDTH value (120). The margins worsened across voltage
and temperature (VT) variations and different test matrices, potentially
causing link stability issues.
Testing with MPLLB_BANDWIDTH value of 140 (0x8c) shows significant
improvement in bandwidth margins across all VT conditions and test
scenarios.
Implement PHY register write helper function and configure:
- MPLLB_BW_OVRD_IN = 140 (0x8c) for improved bandwidth margin
- MPLLB_BW_OVRD_EN to enable the override
This ensures robust PCIe Gen3 performance across all operating conditions.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
[mani: added regmap_read() to flush IMX95_PCIE_PHY_CR_PARA_SEL update]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260803034319.992323-1-hongxing.zhu@oss.nxp.com
|
|
Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
inadvertently moved clock enablement before core reset assertion, breaking
PCI device initialization on i.MX6Q Apalis platforms with
ASM1061/ASM1062 SATA controllers connected:
imx6q-pcie 1ffc000.pcie: host bridge /soc/pcie@1ffc000 ranges:
imx6q-pcie 1ffc000.pcie: IO 0x0001f80000..0x0001f8ffff -> 0x0000000000
imx6q-pcie 1ffc000.pcie: MEM 0x0001000000..0x0001efffff -> 0x0001000000
imx6q-pcie 1ffc000.pcie: config reg[1] 0x01f00000 == cpu 0x01f00000
imx6q-pcie 1ffc000.pcie: iATU: unroll F, 4 ob, 4 ib, align 64K, limit 4G
imx6q-pcie 1ffc000.pcie: Link: Only Gen1 is enabled
imx6q-pcie 1ffc000.pcie: Link failed to come up. LTSSM: POLL_CONFIG
imx6q-pcie 1ffc000.pcie: probe with driver imx6q-pcie failed with error -110
NOTE: It is not 100% clear if the issue is specific to the ASM1061/ASM1062
device or on the specific power-up sequence (reset vs cold-power-on).
To fix this regression, restore the original sequence where clocks are
enabled after asserting core reset and configuring the controller type.
Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling regulators")
Reported-by: Leonardo Costa <leoreis.costa@gmail.com>
Closes: https://lore.kernel.org/all/bl7i3obu2clzsgeoct2a4mtfhv6typcjdqmgneropf3hpgwve6@n2m5uhlduw57/T/#u
Reported-by: Franz Schnyder <fra.schnyder@gmail.com>
Closes: https://lore.kernel.org/all/t65y5d54axtksbfs7r4olcefqhwm6m4dz3njgnrnf7fcotj74i@o7avoznlafbj/
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: move to pci/for-linus for v7.3]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # 7.2+
Link: https://patch.msgid.link/20260813095003.356062-1-hongxing.zhu@oss.nxp.com
|
|
qcom_pcie_config_sid_1_9_0() reads the "iommu-map" property as an array
of fixed four-word {rid-base, phandle, sid, rid-len} entries to program
the BDF to SID translation table. But that layout only holds for an
IOMMU with '#iommu-cells = <1>'. The PCIe SMMUs on these SoCs use
'#iommu-cells = <2>' (SID and mask), so per the pci-iommu binding each
entry is really five cells long.
This used to work only because the DTs were themselves broken. They
described iommu-map with four-cell entries that omitted the SID mask,
which of_map_id() tolerated via its of_check_bad_map() fallback, and the
four-word parsing coincidentally matched that malformed shape.
Since commit ccb2fd725d41 ("of: Respect #{iommu,msi}-cells in maps") the
OF core parses such maps correctly, so the device trees were converted
to proper five-cell entries, e.g. commit c41749e9554d ("arm64: dts:
qcom: sm8250: Fix the PCIe iommu-map entries"). With five-cell entries
the fixed four-word stride slips by one cell for each entry after the
first, so qcom_pcie_config_sid_1_9_0() reads the endpoint mapping's RID
from the preceding entry's length cell and its SID from the phandle cell.
As the RID is the hash key, the endpoint's real RID is never programmed
into the BDF to SID table. Its DMA then hashes to an unprogrammed slot,
gets tagged with SID 0 and the SMMU faults like below on QCS8300:
arm-smmu 15200000.iommu: Unhandled context fault: fsr=0x402, iova=0xffa00000, cbfrsynra=0x0, cb=1
To fix this, walk the map with a stride of 3 + '#iommu-cells' of the
referenced IOMMU and take the SID from the first specifier cell, which is
all the BDF to SID table needs. Validate the layout instead of trusting
the array size. Also, preserve the legacy behavior of the old DTs by
detecting the same pattern that of_check_bad_map() recognizes and
falling back to a stride of four.
Fixes: 4c9398822106 ("PCI: qcom: Add support for configuring BDF to SID mapping for SM8250")
Reported-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK
Link: https://patch.msgid.link/20260907143349.317495-1-mani@kernel.org
|
|
HDMA supports configurable DMA channel register space
separation which ranges from 256B to 32KB. Current implementation
supports 256B as default for DMA channel register space.
CPM6 supports the selection of channel register space via VSEC.
The default value for channel register space for CPM6 is 512B.
Updated the functions and methods to calculate the DMA channel
registers base address as per the selected channel separation
available as part of 'ch_space_sz'. Removed the unused function
__dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs.
Signed-off-by: Devendra K Verma <devverma@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260907101213.1917064-3-devverma@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
states
Per PCIe spec r6.0, sec 5.5.4:
If setting either or both of the enable bits for PCI-PM L1 PM Substates,
both ports must be configured as described in this section while in D0.
Currently, the callers of pci_enable_link_state_locked() (vmd, pcie-qcom)
transition the device to D0 themselves before enabling the link state. But
this is easy to get wrong and has to be duplicated by every caller.
Move the D0 transition into the shared __pci_enable_link_state() helper so
that all three APIs pci_enable_link_state(), pci_enable_link_state_locked()
and pci_force_enable_link_state() perform it, and only when the PCI-PM L1
PM Substates are getting enabled.
Now that the helper handles the transition, drop the redundant D0
transition from the vmd and pcie-qcom callers.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260708-pci-aspm-fix-v3-3-6bd72451746e@kernel.org
|
|
Add SoC-specific data for the RZ/G3L (R9A08G046) PCIe controller and
register its "renesas,r9a08g046-pcie" compatible string. RZ/G3L reuses
the RZ/G3E config init/deinit callbacks and power resets, with its own
L1-allow syscon offset and mask.
Also increase the timeout in rzg3s_pcie_set_max_link_speed() to fix
the "Failed to set max link speed" message seen on RZ/G3L.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260903133320.144245-3-biju.das.jz@bp.renesas.com
|
|
rzg3s_pcie_init_irqdomain() installs chained handlers for the INTx
parent interrupts before creating the INTx irqdomain and initializing
MSI support.
If any subsequent step fails, such as obtaining an INTx IRQ,
creating the irqdomain, or initializing MSI, the error path returns
without removing any chained handlers that were already installed.
This leaves stale handler and data pointers attached to the parent
interrupts.
Add a helper to tear down the INTx IRQ setup, including removing the IRQ
domain and clearing the chained handlers. Use it to unwind partially
completed initialization and from the normal IRQ domain teardown path.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-4-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
platform_get_irq_byname() may return specific error codes such as
-EPROBE_DEFER, but rzg3s_pcie_init_irqdomain() replaces all failures
with -EINVAL.
This breaks probe deferral by preventing the driver core from retrying
probe once the interrupt provider becomes available.
Propagate the original error code instead.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-3-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
rzg3s_pcie_host_init_port() enables the PCIe reference clock using
clk_prepare_enable(), but if rzg3s_pcie_probe() subsequently fails, for
example because pci_host_probe() returns an error, the probe error path
only releases the clock handle with clk_put().
Balance clk_prepare_enable() by calling clk_disable_unprepare() in the
probe cleanup path before releasing the clock, ensuring the reference
clock is properly disabled on probe failure.
Fixes: 7ef502fb35b28 ("PCI: Add Renesas RZ/G3S host controller driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811200013.185956-2-prabhakar.mahadev-lad.rj@bp.renesas.com
|
|
All existing DTS users already name the INTx child node
"interrupt-controller". Use of_get_child_by_name() to find it instead
of assuming it is the first child node.
Signed-off-by: Zhengping Zhang <aquapinn@qq.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/tencent_5E7D6E7FB25B4CD732F08547C11F5DA24808@qq.com
|
|
xgene_pcie_init_port() obtains and enables the controller clock manually.
When xgene_pcie_setup() or pci_host_probe() fails, probe returns without
disabling, unpreparing, or releasing the clock. A failed enable also leaves
the clk_get() reference unreleased.
Use devm_clk_get_enabled() so the clock is unwound automatically on probe
failure and device removal.
Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260802221146.573233-1-dbgh9129@gmail.com
|
|
The variables cpu_addr, pci_addr, and remaining in
mtk_pcie_set_trans_table() are of type resource_size_t, which is 64-bit
on 64-bit architectures.
Using 32-bit helpers fls(), ffs(), and BIT() causes 64-bit integer
truncation when computing window sizes and address alignments above 4GB.
Fix this by switching to fls64(), __ffs64(), and BIT_ULL(). Note that
__ffs64() uses 0-based indexing, so the '- 1' offset is removed.
Additionally, return -ENOMEM when translation tables are exhausted to
prevent silent failure.
Signed-off-by: Sreeraj S Kurup <sreekuttan2156239@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728122810.3475-1-sreekuttan2156239@gmail.com
|
|
Implement .post_deinit() callback in R-Car Gen4 'struct dw_pcie_ep_ops'
which asserts reset and stops the clock. This undoes start of clock and
deassert of reset performed in .pre_init(), in case dw_pcie_ep_init() fails
after successful call of .pre_init() callback.
The use of .post_deinit() callback correctly handles the clock and reset
unwind, unlike the call of rcar_gen4_pcie_ep_deinit() in dw_pcie_ep_init()
which could not discern at which point the dw_pcie_ep_init() failed and can
attempt to stop clock and assert reset twice.
Since dw_pcie_ep_deinit() also invokes the .post_deinit() callback, drop
calls to rcar_gen4_pcie_ep_deinit() in both rcar_gen4_add_dw_pcie_ep() and
dw_pcie_ep_init_registers() fail paths and rcar_gen4_remove_dw_pcie_ep() to
avoid duplicate stop of clock and assert of reset, and drop no longer used
rcar_gen4_pcie_ep_deinit() entirely.
Initialize PCIEDMAINTSTSEN early in rcar_gen4_pcie_ep_pre_init() to 0, to
make sure that edma_int bits will never be left set in case of failure of
dw_pcie_ep_init(), and will only be set in case dw_pcie_ep_init() succeeds.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-2-marek.vasut+renesas@mailbox.org
|
|
If .pre_init() succeeds but subsequent initialization fails, it is
mandatory to correctly undo the hardware configuration which the
.pre_init() callback did. Introduce a .post_deinit() callback to do exactly
that, undo what the .pre_init() callback did. Usually, that means stop the
clock, assert reset, and possibly program some registers to quiesce the
hardware. Invoke the .post_deinit() callback in dw_pcie_ep_deinit() to
retain functional symmetry.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Koichiro Den <den@valinux.co.jp>
Link: https://patch.msgid.link/20260821122808.238248-1-marek.vasut+renesas@mailbox.org
|
|
R-Car Gen4 PCIe controller has a hardware limitation of 256 Bytes
Max_Payload_Size (MPS). PCIe specification indicates that the MPS must not
exceed minimum MPS of any element along the packet path. The PCI core
already enforces this, but add a check to warn if MPS is ever set larger
than 256.
R-Car Gen4 Reference Manual, chapter 104.4.8 Usage notes for MRRS (Max Read
Request Size) states:
Please set "Max Read Request Size" to 128 bytes or 256 bytes.
If "Max Read Request Size" is set to anything other than the
above, the transferred data will not match the expected value.
This limitation also seems to apply to devices doing DMA reads, i.e.,
issuing MRd TLPs. This limitation can be triggered by using non-HMB NVMe
SSD with Max_Read_Request_Size 512 Bytes, for example Crucial P5 Plus. Any
write to the SSD (MRd TLP issued by the SSD controller) longer than 256
Bytes wraps around at the 256 Byte boundary, and the same data are written
to the SSD starting at offset 0 and at 256 Bytes.
Limit Max_Read_Request_Size to at most 256 Bytes for each device connected
to this PCIe controller to avoid this behavior.
A non-HMB (Host Memory Buffer) NVMe SSD can be identified using the
following command. Affected SSD reports 'hmpre' field as 0:
$ nvme id-ctrl /dev/nvme0 | grep hmpre
hmpre : 0
The symptom is a read from the SSD which wraps around at 256 Byte boundary.
The test for this symptom can be implemented by writing 512 Byte of random
data into the SSD and reading the data back. If the read back data repeat
after 256 Bytes, the device is affected.
$ dd if=/dev/urandom of=/tmp/data.bin bs=256 count=2 ; \
dd if=/tmp/data.bin of=/dev/nvme0n1 bs=256 count=2 ; \
dd if=/dev/nvme0n1 bs=256 count=2 of=/tmp/readback.bin
Expected data:
$ hexdump -vC /tmp/data.bin
00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca
00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b
...
00000100 7a ce 3c b2 e1 d5 d9 11 88 63 10 59 76 3c dc 32 <-- random
00000110 72 32 2a 7d a3 e1 aa 13 7c da 58 a1 7b 21 11 50 <-- data
Faulty readback, collected without this change in place:
$ hexdump -vC /tmp/readback.bin
00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <---.
00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-. |
... | |
00000100 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <-:-+- repeated
00000110 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-+--- data
^^^
|
'--- Repeat starts at offset 0x100 = 256 Bytes
Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260821020636.111719-1-marek.vasut+renesas@mailbox.org
|
|
For firmware-managed PCIe controllers, all resources, including clocks,
regulators, resets, PHYs and link state, are owned and managed by
firmware. The host driver must not attempt to manage these resources
during system suspend or resume. Firmware will properly transition the
devices/controller into relevant low power modes.
Skip the suspend and resume operations for firmware-managed controllers.
The associated power domain transitions are handled independently by the
genpd framework through its own system suspend/resume callbacks, so no
explicit action is required by the PCIe controller driver.
Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260831-skip_suspend-v1-1-ba2d877e22b1@oss.qualcomm.com
|
|
Lake
Meteor Lake VMD (8086:7d0b) is affected by erratum MTL016: the VMD can
signal its MSI before the posted writes carrying a child device's DMA
data have landed in memory. vmd_irq() then demuxes to the child handler
while the child's completion queue is not yet coherent, so the handler
observes no completion and returns without consuming it. The I/O is
only recovered when the block layer timeout expires and polls the queue:
nvme nvme0: I/O tag 253 (50fd) QID 1 timeout, completion polled
The practical effect is therefore not a lost I/O but a 30 second stall
of the entire storage stack, repeated under any sustained read load.
This was originally diagnosed and fixed by Kai-Heng Feng in September
2024 [1]. That patch used udelay(4); Keith Busch objected that the delay
is merely a side effect of the read, and that flushing the pending
device-to-host writes is what the erratum actually requires. Kai-Heng
agreed to respin with a dummy register read. The thread then stalled on
an open question from Manivannan Sadhasivam [2]: whether the read must
target the child device (the "MSI initiator" named by the erratum)
rather than the VMD, and whether the workaround belongs in the NVMe
driver instead. No revision followed, and the erratum has remained
unmitigated in mainline since.
This implements the flush read Keith asked for, and answers the open
question empirically: the read MUST complete at the initiating child
device. A read of the VMD's own config BAR was tried first and does not
help - it terminates at the VMD and never traverses the downstream
link, so it does not order against the child's posted writes (measured:
timeout rate unchanged). Reading the initiator's config space does
order correctly: per PCIe ordering rules the read completion cannot
pass the device's earlier posted writes, so returning from the read
guarantees the completion queue entry is visible.
The initiator's config address is captured per-IRQ at MSI allocation
time from the requesting device, so the hot path adds one config read
only on affected parts, and only for vectors owned by a child device.
The read is serialized with cfg_lock like all other VMD config access.
No NVMe driver change is needed.
Measured on a Dell Pro Max 14 MC14250 (Meteor Lake, VMD 8086:7d0b,
KIOXIA BG6 512GB, 7.0.0-30-generic). The drive is healthy (46C, 0 media
errors, 2% used) and ASPM is disabled on the link with all L1 substates
off, so neither ASPM nor APST is involved.
Dropping caches and reading 3000 shared libraries, measuring
/proc/pressure/io "full" (every task on the system blocked on I/O),
with nvme_core.io_timeout=5:
unpatched: round 1 wall 37.4s full I/O stall 32.6s timeouts 0
round 2 wall 30.6s full I/O stall 28.7s timeouts 1
round 3 wall 30.3s full I/O stall 27.4s timeouts 1
VMD-BAR read: round 1 wall 44.8s full I/O stall 38.6s timeouts 8
(insufficient) round 2 wall 234.8s full I/O stall 207.9s timeouts 37
round 3 wall 3.6s full I/O stall 0.8s timeouts 0
this patch: round 1 wall 3.6s full I/O stall 1.3s timeouts 0
round 2 wall 3.6s full I/O stall 1.3s timeouts 0
round 3 wall 3.6s full I/O stall 1.4s timeouts 0
Before any workaround, 208 seconds of total-system I/O stall
accumulated in the first 13 minutes of uptime, roughly 27% of wall
clock. Userspace experiences this as GUI applications taking 30-60+
seconds to start while throughput between stalls looks entirely normal
(1.9 GB/s QD1) - which is what makes the fault easy to misattribute to
ASPM or to the drive.
[1] https://lore.kernel.org/all/20240909082657.19660-1-kai.heng.feng@canonical.com/
[2] https://lkml.iu.edu/hypermail/linux/kernel/2409.1/08047.html
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Suggested-by: Keith Busch <kbusch@kernel.org>
Assisted-by: LLM
Signed-off-by: Rickey Bartlett <subtexel@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20240909082657.19660-1-kai.heng.feng@canonical.com/
Link: https://lkml.iu.edu/hypermail/linux/kernel/2409.1/08047.html
Link: https://patch.msgid.link/20260825043220.9047-1-subtexel@gmail.com
|
|
aspeed_pcie_port_init() calls clk_prepare_enable() to enable the port
clock, but if phy_init() or phy_set_mode_ext() fails afterwards, the
function returns without calling clk_disable_unprepare(), leaking the
clock reference on every probe failure. Additionally, when
phy_set_mode_ext() fails, phy_init() has already succeeded, so
phy_exit() is also missing, leaking the PHY reference.
Add the matching clk_disable_unprepare() to both error paths, and
phy_exit() to the phy_set_mode_ext() failure path, mirroring the
cleanup pattern in pci-aardvark.
Compile-tested with gcc on arm64 defconfig using COMPILE_TEST.
Fixes: 9aa0cb68fcc1 ("PCI: aspeed: Add ASPEED PCIe RC driver")
Signed-off-by: Liu Zhenlong <dragonliu2018@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260816171633.15025-1-dragonliu2018@gmail.com
|
|
In imx_pcie_probe(), after pci_pwrctrl_create_devices() creates the
pwrctrl devices, the error paths for imx_add_pcie_ep() and
dw_pcie_host_init() both jump to err_pwrctrl_destroy to tear them down.
However, the error path for devm_pm_runtime_set_active_enabled() returns
directly, leaking the pwrctrl devices.
Jump to err_pwrctrl_destroy instead so the pwrctrl devices are cleaned
up on this error path too.
Signed-off-by: hanzhijian <hanzhijian1991@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260822012205.2459806-1-hanzhijian1991@gmail.com
|
|
Fix Clang -Wenum-compare-conditional warning by using a single u32
variable to hold the LTSSM status value, replacing two separate enum
variables of different types.
Fixes: d70e964dc099 ("PCI: cadence: Add LGA IP debugfs for LTSSM status")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608201933.w2579mwx-lkp@intel.com/
Signed-off-by: Hans Zhang <18255117159@163.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260820232305.80596-1-18255117159@163.com
|
|
After a PCIe link goes down, software may still access the BAR (MMIO)
space or configuration space of devices behind that link before recovery
has run. As the link is down, these accesses never complete, resulting in
a storm of Completion Timeout AERs.
Use the controller's ECAM blocker to drop these accesses to the PCIe
address space as soon as the link-down interrupt fires, so that Completion
Timeout AERs are reduced. The blocked range covers the entire address
space (base 0x0, all-ones limit), since the Root Port's own DBI/iATU
register space remains accessible regardless.
The range is programmed once in the host init path, since the range
registers are wiped by BCR reset. This leaves only the ECAM_BLOCKER_EN
bit to be flipped from the link-down IRQ handler, so the blocker can be
armed with a single fast register write for immediate effect.
The subsequent Root Port reset re-initialises the controller, which clears
the enable bit and re-programs the range for the fresh link.
Some IP revisions implement the ECAM blocker registers but do not wire
up the "global" interrupt used to deliver the link-down event that arms
the blocker, so there is no way to enable the blocker on those platforms.
Restrict blocker initialization to the post_init hooks of the IP
revisions that do have a global IRQ wired up
(qcom_pcie_post_init_2_3_3(), qcom_pcie_post_init_2_7_0() and
qcom_pcie_post_init_2_9_0()), instead of unconditionally programming it
from the common host_init path.
The link-down IRQ thread's blocker-enable write to PARF_SYS_CTRL can race
with a Root Port reset triggered independently through AER, which
reprograms PARF_SYS_CTRL as part of reinitializing the controller.
Serialize these with a per-controller mutex.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
[mani: renamed hw_lock to reset_lock and used guard(mutex)]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD + ASUS PA27AC
Link: https://patch.msgid.link/20260819-ecam_blocker-v2-1-e7a8fdc1c5cb@oss.qualcomm.com
|
|
qcom_pcie_parse_perst() walks the PCIe hierarchy described in the device
tree below its Root Port and collects the PERST# GPIOs from each bridge
node so all PERST# lines can be driven in unison during controller
bring-up, reset and power sequencing.
However, the recursive device tree walk currently visits every available
child node without checking that it is a PCI bridge. This allows the walk
to leave the PCI hierarchy and collect reset lines from children of PCI
Endpoint nodes, where those reset lines belong to other drivers.
This is reproducible on the Qualcomm RB3Gen2, where a Renesas uPD720201
USB host controller sits behind a PCIe switch downstream port. A Genesys
GL3590 USB hub connected to that controller is described as a child of
the PCI endpoint:
pcie@2,0 {
device_type = "pci";
usb-controller@0,0 {
compatible = "pci1912,0014";
hub@1 {
compatible = "usb5e3,610";
reset-gpios = <&tlmm 162 GPIO_ACTIVE_HIGH>;
};
};
};
The USB controller is a PCI Endpoint, and not a bridge, but the PERST#
walk descends through it and incorrectly claims the hub's reset GPIO:
$ gpioinfo
line 162: unnamed output consumer=PERST#
As a result, the onboard-usb-dev driver cannot acquire its reset GPIO
during probe:
onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \
error -EBUSY: failed to get reset GPIO
onboard-usb-dev 1c08000.pcie:...:usb-controller@0,0:hub@1: \
probe with driver onboard-usb-dev failed with error -16
The GPIO is also added to the root port's PERST# list and is asserted
and deasserted as part of PCIe reset sequencing. On the RB3Gen2 this
causes the USB hub to repeatedly re-enumerate:
[ 116.479598] hub 2-1:1.0: USB hub found
[ 116.488601] hub 2-1:1.0: USB hub found
[ 116.496971] hub 2-1:1.0: USB hub found
...
This disrupts the hub and devices connected to it.
Restrict the recursive walk to children with device_type "pci", so
PERST# GPIOs are collected only from PCI bridge nodes and the walk
does not descend through endpoints.
qocm_pcie_parse_ports() has made the same distinction since
commit 45df22935bdc ("PCI: qcom: Restrict port parsing only to PCIe
bridge child nodes"), but the PERST# walk added later did not carry over
that check.
This bug is distinct from commit 3edb3a038d42 ("PCI: qcom: Skip PERST#
GPIOs provided by downstream PCIe devices"), which filters PERST# GPIOs
based on their provider. Here the GPIO is provided by the SoC TLMM; the
bug is that reset-gpios is consumed from a non-bridge node at all.
Fixes: 2fd60a2edb83 ("PCI: qcom: Parse PERST# from all PCIe bridge nodes")
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260829-wip-obbardc-drivers-pcie-qcom-rb3gen2-usb-fix-v1-1-337821131a99@oss.qualcomm.com
|
|
Add support for the PCIe Root Port PERST# signal using the GPIO
framework, along with the PCIe IP reset. This reset is managed
by the driver and occurs after the Initial Power Up sequence
(PCIe CEM r6.0, 2.2.1) is handled in hardware before the driver's
probe function is called.
This is useful in warm reset scenarios where the power rails stay stable
and only PERST# is toggled. Applying both the IP reset and PERST# resets
the Root Port controller and Endpoint synchronously, improving
reliability and avoiding lane errors.
Both the reset GPIO and the reset controller are optional to keep
backward compatibility with existing DTBs. Also add a PCIE_T_PERST_US
(100 us) macro in pci.h for the PERST# active time (PCIe CEM r6.0,
sec 2.11.2, "T_PERST").
As part of this, update the interrupt controller node parsing to use
of_get_child_by_name() instead of of_get_next_child(), since the PCIe
host bridge node now has multiple children. This ensures the correct
node is selected during initialization.
Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260818153755.3801111-3-sai.krishna.musham@amd.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux
Pull hyperv updates from Wei Liu:
- Decrypt netvsc buffer on contiguous direct-map addresses (Kameron
Carr)
- Drop WS2012/2012R2 & Win8/8.1 Hyper-V support (Michael Kelley)
- Use more meaningful errnos for hypercall status code (Hardik Garg)
- Fix lost interrupts on CPU hot-unplug for Hyper-V PCI/MSI (Naman
Jain)
- Reserve more MSHV vectors for Linux root partition (Wei Liu)
* tag 'hyperv-next-signed-20260826' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
clocksource: hyper-v: Remove support for stimer interrupts in message mode
scsi: storvsc: Remove support for storvsc protocol of old Hyper-V hosts
hv_netvsc: Remove GPADL teardown special case for old Hyper-V hosts
hv_sock: Remove check for old Hyper-V hosts
Drivers: hv: Remove support for WS2012/2012R2 & Win8/8.1 version of Hyper-V
hv_netvsc: Allocate send/receive buffers using vmbus_alloc_buffer()
Drivers: hv: vmbus: Add vmbus_alloc_buffer()/vmbus_free_buffer() for CoCo VMs
Drivers: hv: vmbus: add vmbus_establish_gpadl_caller_decrypted()
Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition
x86/hyperv: reserve more vectors
PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip
Drivers: hv: Use meaningful errnos for hypercall status codes
|
|
The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback.
On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
the outgoing CPU to a new target. If an interrupt still has its pending bit
set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
new target through the irqchip's irq_retrigger() callback. As the Hyper-V
PCI/MSI chip does not provide that callback, the pending interrupt is
silently dropped, which can result in lost interrupts, stalls and "No irq
handler for vector" messages during CPU hotplug.
Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its
new target CPU via the parent x86 vector domain.
Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Cc: stable@vger.kernel.org
Suggested-by: Long Li <longli@microsoft.com>
Suggested-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Aditya Garg <gargaditya@linux.microsoft.com>
Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
|
