PCI: Add support for PCIe WAKE# interrupt#1438
Open
ziyuezhang-123 wants to merge 28 commits into
Open
Conversation
Previously, the driver skipped putting the link into L2/device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the host bridge may enter D3cold. So, replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_can_enter_d3cold() helper to decide whether the DesignWare host bridge can safely transition to D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-2-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…host bridges Add a common helper, pci_host_common_can_enter_d3cold(), to determine whether a PCI host bridge can safely transition to D3cold. The helper walks all devices on the bridge's bus and only allows the host bridge to enter D3cold if all PCIe endpoints are already in PCI_D3hot. For devices that may wake the system, it additionally requires that the device supports PME wakeup from D3cold(with WAKE#). Devices without wakeup enabled are not restricted by this check and can be allowed to keep device in D3cold. Link: https://lore.kernel.org/r/20260128-d3cold-v1-1-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Add pme_turn_off() support and use DWC common suspend resume methods for device D3cold entry & exit. If the device is not kept in D3cold use existing methods like keeping icc votes, opp votes etc.. intact. In qcom_pcie_deinit_2_7_0(), explicitly disable PCIe clocks and resets in the controller. Remove suspended flag from qcom_pcie structure as it is no longer needed. Link: https://lore.kernel.org/r/20260128-d3cold-v1-3-dd8f3f0ce824@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Currently, the driver expects the devices to remain in D0 across system suspend, but the genpd framework may still power down the associated GDSC during suspend. When that happens, the PCIe link goes down and cannot be recovered on resume. Prevent genpd from turning off the PCIe GDSC by using dev_pm_genpd_rpm_always_on() so that the power domain stays on while the controller is suspended. This preserves the link state across suspend/resume and avoids unrecoverable link failures. Fixes: 82a8238 ("PCI: qcom: Add Qualcomm PCIe controller driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260128-genpd_fix-v1-1-cd45a249d12f@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm(), which retrieves the LTSSM state from the PARF_LTSSM register instead. Link: https://lore.kernel.org/r/20260217-d3cold-v2-3-89b322864043@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…vice context during suspend Currently, the PCI endpoint drivers like NVMe checks whether the device context will be retained or not during system suspend, with the help of pm_suspend_via_firmware() API. But it is possible that the device context might be lost due to some platform limitation as well. Having those checks in the endpoint drivers will not scale and will cause a lot of code duplication. So introduce an API that acts as a sole point of truth that the endpoint drivers can rely on to check whether they can expect the device context to be retained or not. If the API returns 'false', then the client drivers need to prepare for context loss by performing actions such as resetting the device, saving the context, shutting it down etc... If it returns 'true', then the drivers do not need to perform any special action and can leave the device in active state. Right now, this API only incorporates the pm_suspend_via_firmware() check. But will be extended in the future commits. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-1-adbb4555b5ab@oss.qualcomm.com
…sume from system suspend The PCIe spec v7.0, sec 5.5.3.3.1, states that for exiting L1.2 due to an endpoint asserting CLKREQ# signal, the refclk must be turned on no earlier than TL10_REFCLK_ON, and within the latency advertised in the LTR message. This same behavior applies to L1.1 as well. On some platforms like Qcom, these requirements are satisfied during OS runtime, but not while resuming from the system suspend. This happens because the PCIe RC driver may remove all resource votes and turns off the PHY during suspend to maximize power savings while keeping the link in L1ss. Consequently, when the endpoint asserts CLKREQ# to wake up, the OS must first resume and the RC driver must restore the PHY and enable the refclk. This recovery process exceeds the L1ss exit latency time. And this latency violation results in an L1ss exit timeout, followed by Link Down (LDn). If the endpoint device is used to host the RootFS, it will result in an OS crash. For other endpoints, it may result in a complete device reset/recovery. So to indicate this platform limitation to the client drivers, introduce a new flag 'pci_host_bridge::broken_l1ss_resume' and check it in the pci_dev_suspend_retention_supported() API. If the flag is set by the RC driver, the API will return 'false' indicating the client drivers that the device context may not be retained and the drivers must be prepared for context loss. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-2-adbb4555b5ab@oss.qualcomm.com
…tem suspend Qcom PCIe RCs can successfully exit from L1ss during OS runtime. However, during system suspend, the Qcom PCIe RC driver may remove all resource votes and turns off the PHY to maximize power savings. Consequently, when the host is in system suspend with the link in L1ss and the endpoint asserts CLKREQ#, the OS must first wake up and the RC driver must restore the PHY and enable the refclk. This recovery process causes the strict L1ss exit latency time to be exceeded. (If the RC driver were to retain all votes during suspend, L1ss exit would succeed without issue, but at the expense of higher power consumption). This latency violation leads to an L1ss exit timeout, followed by a Link Down (LDn) condition during resume. This LDn can crash the OS if the endpoint hosts the RootFS, and for other types of devices, it may result in a full device reset/recovery. So to ensure that the client drivers can properly handle this scenario, let them know about this platform limitation by setting the 'pci_host_bridge::broken_l1ss_resume' flag. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-3-adbb4555b5ab@oss.qualcomm.com
…ing suspend The pci_dev_suspend_retention_supported() API lets PCI client drivers know if the platform can retain the device context during suspend. This is decided based on several factors like: 1. Firmware involvement at the end of suspend 2. Any platform limitation in waking from low power state (L1ss) And this API might also get extended in the future to cover other platform specific issues impacting the device low power mode during system suspend. So use this API instead of checks like pm_suspend_via_firmware(). When this API returns false, then assume that the platform cannot retain the context and shutdown the controller. If it returns true, then assume that the context will be retained and keep the device in low power mode. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260414-l1ss-fix-v1-4-adbb4555b5ab@oss.qualcomm.com
…d eligibility Add a common helper, pci_host_common_d3cold_possible(), to determine whether PCIe devices under host bridge can safely transition to D3cold. This helper is intended to be used by PCI host controller drivers to decide whether they may safely put the host bridge into D3cold based on the power state and wakeup capabilities of downstream endpoints. The helper walks all devices on the all bridge buses and only allows the devices to enter D3cold if all PCIe endpoints are already in PCI_D3hot. This ensures that we do not power off the host bridge while any active endpoint still requires the link to remain powered. For devices that may wake the system, the helper additionally requires that the device supports PME wake from D3cold (via WAKE#). Devices that do not have wakeup enabled are not restricted by this check and do not block the devices under host bridge from entering D3cold. Devices without a bound driver and with PCI not enabled via sysfs are treated as inactive and therefore do not prevent the devices under host bridge from entering D3cold. This allows controllers to power down more aggressively when there are no actively managed endpoints. Some devices (e.g. M.2 without auxiliary power) lose PME detection when main power is removed. Even if such devices advertise PME-from-D3cold capability, entering D3cold may break wakeup. So, return PME-from-D3cold capability via an output parameter so PCIe controller drivers can apply platform-specific handling to preserve wakeup functionality. Link: https://lore.kernel.org/r/20260429-d3cold-v5-1-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
For older targets like sc7280, we see reading DBI after sending PME turn off message is causing NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm() to retrieve the LTSSM state. For newer platforms, the LTSSM state is read from the PARF_LTSSM register, while older platforms continue to retrieve it from ELBI_SYS_STTS. This helper is used in place of direct DBI-based link state checks in the D3cold path after sending PME turn-off message, ensuring the LTSSM state can be queried safely even after DBI access is no longer valid. Link: https://lore.kernel.org/r/20260429-d3cold-v5-2-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…g rails/clocks Some Qcom PCIe controller variants bring the PHY out of test power-down (PHY_TEST_PWR_DOWN) during init. When the link is later transitioned towards D3cold and the driver disables PCIe clocks and/or regulators without explicitly re-asserting PHY_TEST_PWR_DOWN, the PHY can remain partially powered, leading to avoidable power leakage. Update the init-path comments to reflect that PARF_PHY_CTRL is used to power the PHY on. Also, for controller revisions that enable PHY power in init (2.3.2, 2.3.3, 2.4.0, 2.7.0 and 2.9.0), explicitly power the PHY down via PARF_PHY_CTRL in the deinit path before disabling clocks or regulators. This ensures the PHY is put into a defined low-power state prior to removing its supplies, preventing leakage when entering D3cold. Link: https://lore.kernel.org/r/20260429-d3cold-v5-3-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Previously, the driver skipped putting the link into L2/device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the devices under host bridge may enter D3cold. So, replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_d3cold_possible() helper to decide whether the devices under host bridge can safely transition to D3cold. In addition, propagate PME-from-D3cold capability information from the helper and record it in skip_pwrctrl_off. Some devices (e.g. M.2 cards without auxiliary power) may lose PME detection when main power is removed, even if they advertise PME-from-D3cold support. This allows controller power-off to be skipped when required to preserve wakeup functionality. Update the suspended flag in dw_pcie_resume_noirq() only after the PCIe link resumes successfully, to avoid marking the controller active when link resume fails. Link: https://lore.kernel.org/r/20260429-d3cold-v5-4-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Add support for transitioning PCIe endpoints under host bridge into D3cold by integrating with the DWC core suspend/resume helpers. Implement PME_TurnOff message generation via ELBI_SYS_CTRL and hook it into the DWC host operations so the controller follows the standard PME_TurnOff-based power-down sequence before entering D3cold. When the device is suspended into D3cold, fully tear down interconnect bandwidth, OPP votes. If D3cold is not entered, retain existing behavior by keeping the required interconnect and OPP votes. Use dw_pcie::skip_pwrctrl_off to avoid powering off devices during suspend to preserve wakeup capability of the devices and also not to power on the devices in the init path. Drop the qcom_pcie::suspended flag and rely on the existing dw_pcie::suspended state, which now drives both the power-management flow and the interconnect/OPP handling. Link: https://lore.kernel.org/r/20260429-d3cold-v5-5-89e9735b9df6@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Before accessing DBI registers during resume, the OPP (Operating Performance Point) must be set to maximum to ensure the required voltage corner is available. Without this, DBI access may fail on some platforms. Refactor the open-coded max OPP selection in probe() into a helper qcom_pcie_set_max_opp(), and call it during resume before re-enabling the CPU-PCIe interconnect. Link: https://lore.kernel.org/r/20260416-setmaxopp-v1-1-6a74e2d945a0@oss.qualcomm.com Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…need pwrctrl
pci_pwrctrl_is_required() is used to detect whether a device really
needs the PCI pwrctrl support or not. It is currently used in
pci_pwrctrl_create_device(), but not in pci_pwrctrl_power_{on/off}_device()
APIs. This leads to pwrctrl core trying to power on/off the incompatible
devices like USB hub downstream ports defined in DT.
Hence, add this check to prevent pwrctrl core from poking at wrong
devices. For this purpose, move the pci_pwrctrl_is_required() helper
definition to the top.
Link: https://lore.kernel.org/r/20260421104102.12322-1-manivannan.sadhasivam@oss.qualcomm.com
Fixes: b35cf3b ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices")
Reported-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
PCIe-to-USB bridge UPD720201 does not advertise D3cold support until firmware is loaded post pci enumeration. This results in upd blocking D3cold entry during system suspend and causing overall failure to enter XO shutdown. Hence, add a quirk to advertise D3cold PME capability since the HW actually supports and advertises it post firmware loading. Link: https://lore.kernel.org/all/20260430-d3cold_support-v1-1-6734f280c481@oss.qualcomm.com/ Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
All functions in this driver follow 'pwrseq_pcie_m2' prefix except a few. Fix them to avoid inconsistency. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-1-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…ple PCI devices Current code makes it possible to create serdev for only one PCI device. But for scaling this driver, it is necessary to allow creating serdev for multiple PCI devices. Hence, add provision for it by creating 'struct pwrseq_pci_dev' for each PCI device that requires serdev and add them to 'pwrseq_pcie_m2_ctx::pci_devices' list. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-2-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Instead of hardcoding the PCI device check, use pci_match_id() to check for the known IDs using the pwrseq_m2_pci_ids[] array. This makes adding support for new devices easier. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-3-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…resent before probe So far, the driver is registering a notifier to create serdev for the PCI devices that are going to be attached after probe. But it doesn't handle the devices present before probe. Due to this, serdev is not getting created for those existing devices. Hence, create serdev for PCI devices available before probe as well. Note that the serdev for available devices are created before registering the notifier. There is a small window where a device could appear after pwrseq_pcie_m2_create_serdev(), before notifier registration. But since M.2 cards are fixed to a slot, they are mostly added either before booting the host or after using hotplug. So this window is mostly theoretical. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-4-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…_device_id[] table Currently, pwrseq_pcie_m2_create_bt_node() hardcodes the BT compatible for creating the devicetree node. But to allow adding support for more devices in the future, create the BT node based on the pci_device_id[] table. The BT compatible is passed using 'driver_data'. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-5-b39dc2ae3966@oss.qualcomm.com Co-developed-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
… 'dev' pointer The consumer drivers can make use of the pwrseq device's 'dev' pointer to query the pwrseq provider's DT node to check for existence of specific properties. Hence, add an API to return the pwrseq device's 'dev' pointer to consumers. Note that since pwrseq_get() would've increased the pwrseq refcount, there is no need to increase the refcount in this API again. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-6-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…pwrseq Power supply to the M.2 Bluetooth device attached to the host using M.2 connector is controlled using the 'uart' pwrseq device. So add support for getting the pwrseq device if the OF graph link is present. Once obtained, the existing pwrseq APIs can be used to control the power supplies of the M.2 card. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-7-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…vailable' 'power_ctrl_enabled' flag is used to indicate the availability of the BT_EN GPIO in devicetree. But the naming causes confusion with the new pwrctrl framework. So rename it to 'bt_en_available' to make it clear and explicit. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-8-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
…E2# presence in M.2 connector Check if the M.2 connector supports the W_DISABLE2# property or not by querying the pwrseq provider's DT node. If not available, then set 'bt_en_available' flag to 'false'. This flag is used to set the HCI_QUIRK_NON_PERSISTENT_SETUP HCI quirk, which informs the HCI layer whether the shutdown() callback for the device can be triggered or not. Link: https://lore.kernel.org/r/20260519-pwrseq-m2-bt-v3-9-b39dc2ae3966@oss.qualcomm.com Tested-by: Wei Deng <wei.deng@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Add fwnode_gpiod_get() as a convenience wrapper around fwnode_gpiod_get_index() for the common case where only the first GPIO is required. This mirrors existing gpiod_get() and devm_gpiod_get() helpers and avoids open-coding index 0 at call sites. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260511-wakeirq_support-v10-1-c10af9c9eb8c@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2), two link wakeup mechanisms are defined: Beacon and WAKE#. Beacon is a hardware-only mechanism and is invisible to software (PCIe r7.0, Section 4.2.7.8.1). This change adds support for the WAKE# mechanism in the PCI core. According to the PCIe specification, multiple WAKE# signals can exist in a system or each component in the hierarchy could share a single WAKE# signal. In configurations involving a PCIe switch, each downstream port (DSP) of the switch may be connected to a separate WAKE# line, allowing each endpoint to signal WAKE# independently. From figure 5.4 in sec 5.3.3.2, WAKE# can also be terminated at the switch itself. Such topologies are typically not described in Device Tree, therefore it is out of scope for this series. To support this, the WAKE# should be described in the device tree node of the endpoint/bridge. If all endpoints share a single WAKE# line, then each endpoint node shall describe the same WAKE# signal or a single WAKE# in the Root Port node. In pci_device_add(), PCI framework will search for the WAKE# in device node. Once found, register for the wake IRQ through dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with a device and requests it, but the PM core keeps the IRQ disabled by default. The IRQ is enabled by the PM core, only when the device is permitted to wake the system, i.e. during system suspend and after runtime suspend, and only when device wakeup is enabled. If the same WAKE# GPIO is described in multiple device tree nodes, only the first device that successfully registers the wake IRQ will succeed, while subsequent registrations may fail. This limitation does not affect functional correctness, since WAKE# is only used to bring the link to D0, and endpoint-specific wakeup handling is resolved later through PME detection (PME_EN is set in suspend path by PCI core by default). When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume() to bring the device back to an active power state, such as transitioning from D3cold to D0. Once the device is active and the link is usable, the endpoint may generate a PME, which is then handled by the PCI core through PME polling or the PCIe PME service driver to complete the wakeup of the endpoint. WAKE# is added in dts schema and merged based on below links. Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/ Link: devicetree-org/dt-schema#170 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20260511-wakeirq_support-v10-2-c10af9c9eb8c@oss.qualcomm.com Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
qcomlnxci
requested review from
krishnachaitanya-linux and
Matthew Leung (meleung)
ziyuezhang-123
force-pushed
the
for-bus-pci-all
branch
from
4cbaae3 to
9f7acd3
Compare
PR #1438 — validate-patchPR: #1438
Final Summary
|
PR #1438 — checker-log-analyzerPR: #1438
Detailed report: Full report
|
krishnachaitanya-linux
force-pushed
the
tech/bus/pci/all
branch
from
7650854 to
ebd808f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series adds support for PCIe WAKE# interrupt handling.
Patch 1/2: gpio: Add fwnode_gpiod_get() helper
Patch 2/2: PCI: Add support for PCIe WAKE# interrupt
Link: https://lore.kernel.org/all/20260511-wakeirq_support-v10-1-c10af9c9eb8c@oss.qualcomm.com/