USB: pci-quirks: Skip usb_early_handoff for Renesas PCI USB#1426
Open
akakum-qualcomm wants to merge 27 commits into
Open
USB: pci-quirks: Skip usb_early_handoff for Renesas PCI USB#1426akakum-qualcomm wants to merge 27 commits into
akakum-qualcomm wants to merge 27 commits into
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>
Skip usb_early_handoff for the Renesas PCI USB controller due to the firmware not being loaded beforehand, which impacts the bootup time. Links: https://lore.kernel.org/all/20240521074635.17938-1-quic_akakum@quicinc.com/ Signed-off-by: Akash Kumar <quic_akakum@quicinc.com>
akakum-qualcomm
force-pushed
the
for-usb-pci
branch
from
9d5f3cf to
2deb140
Compare
vvreddy-qualcomm
approved these changes
Jun 29, 2026
qcomlnxci
requested review from
a team,
krishnachaitanya-linux and
Matthew Leung (meleung)
and removed request for
a team
PR #1426 — validate-patchPR: #1426
Final Summary
|
PR #1426 — checker-log-analyzerPR: #1426
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
7 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.
Skip usb_early_handoff for the Renesas PCI USB controller due to the firmware not being loaded beforehand, which impacts the bootup time.
Links: https://lore.kernel.org/all/20240521074635.17938-1-quic_akakum@quicinc.com/
CRs-Fixed: 4440584