[PATCH AUTOSEL 6.17-6.12] PCI: imx6: Enable the Vaux supply if available

[Sasha Levin]

From: Richard Zhu <hongxing.zhu at nxp.com>

[ Upstream commit c221cbf8dc547eb8489152ac62ef103fede99545 ]

When the 3.3Vaux supply is present, fetch it at the probe time and keep it
enabled for the entire PCIe controller lifecycle so that the link can enter
L2 state and the devices can signal wakeup using either Beacon or WAKE#
mechanisms.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
[mani: reworded the subject, description and error message]
Signed-off-by: Manivannan Sadhasivam <mani at kernel.org>
Reviewed-by: Frank Li <Frank.Li at nxp.com>
Link: https://patch.msgid.link/20250820022328.2143374-1-hongxing.zhu@nxp.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- The change enables an optional 3.3V auxiliary PCIe supply early in
  probe and keeps it on for the controller’s lifetime via devm, which
  directly addresses link low‑power (L2) entry and wake signaling
  reliability. The new call
  `devm_regulator_get_enable_optional(&pdev->dev, "vpcie3v3aux")` is
  added in `drivers/pci/controller/dwc/pci-imx6.c:1744`. Errors other
  than “not present” are surfaced using `dev_err_probe()`
  (`drivers/pci/controller/dwc/pci-imx6.c:1745`), ensuring a clear,
  fail‑fast behavior if hardware provides the supply but it cannot be
  enabled.

- The helper used is a standard devres API that both acquires and
  enables the regulator for the device lifetime, and automatically
  disables it on device teardown. See the declaration in
  `include/linux/regulator/consumer.h:166` and implementation in
  `drivers/regulator/devres.c:110`. This matches the commit’s intent to
  “keep it enabled for the entire PCIe controller lifecycle.”

- This is a contained, minimal change within the i.MX DesignWare PCIe
  host driver probe path. It does not alter broader PCIe core behavior,
  call flows, or add architectural changes. It only:
  - Enables `vpcie3v3aux` if present (`drivers/pci/controller/dwc/pci-
    imx6.c:1744`).
  - Leaves existing supply handling intact for `vpcie` and `vph`
    (`drivers/pci/controller/dwc/pci-imx6.c:1748` and
    `drivers/pci/controller/dwc/pci-imx6.c:1755`).
  - Keeps `vpcie` enable/disable at host init/exit unchanged
    (`drivers/pci/controller/dwc/pci-imx6.c:1205`,
    `drivers/pci/controller/dwc/pci-imx6.c:1280`,
    `drivers/pci/controller/dwc/pci-imx6.c:1297`).

- The functional impact is to enable proper L2 and wake signaling
  (Beacon or WAKE#) on boards that wire up 3.3Vaux. The driver already
  carries context that AUX power matters; for example, i.MX95 has an
  erratum requiring AUX power detect handling to exit L23 Ready
  (`drivers/pci/controller/dwc/pci-imx6.c:245` comment explains AUX
  power implications). Turning on AUX power when available is therefore
  a correctness fix, not a feature.

- Risk/regression assessment:
  - If the supply is not defined, nothing changes (uses “optional” API
    and ignores `-ENODEV`).
  - If the supply is defined but cannot be enabled, probe now fails
    loudly; this surfaces real hardware/regulator issues instead of
    running with broken low‑power/wake behavior.
  - The pattern matches existing PCIe controller drivers that enable
    optional PCIe supplies at probe with the same helper (e.g.,
    `drivers/pci/controller/pcie-rcar-host.c:954`), indicating
    established practice across subsystems.
  - Binding-wise, the i.MX PCIe common binding allows additional
    properties (`additionalProperties: true` in
    `Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-
    common.yaml:246`), so using `vpcie3v3aux-supply` is non‑disruptive
    for DT validation. DT updates are optional and can follow
    separately.

- Stable criteria fit:
  - Fixes a real user-visible issue (L2 entry and wake signaling fail
    without AUX).
  - Small and self-contained change in a single driver.
  - No architectural refactor or feature addition beyond enabling an
    optional, already-described hardware supply.
  - Uses existing, widely deployed APIs with minimal regression risk.

Given the clear bugfix nature, minimal scope, and alignment with
established patterns, this is a good candidate for stable backport.

 drivers/pci/controller/dwc/pci-imx6.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 80e48746bbaf6..db51e382a7cf3 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1745,6 +1745,10 @@ static int imx_pcie_probe(struct platform_device *pdev)
 	pci->max_link_speed = 1;
 	of_property_read_u32(node, "fsl,max-link-speed", &pci->max_link_speed);
 
+	ret = devm_regulator_get_enable_optional(&pdev->dev, "vpcie3v3aux");
+	if (ret < 0 && ret != -ENODEV)
+		return dev_err_probe(dev, ret, "failed to enable Vaux supply\n");
+
 	imx_pcie->vpcie = devm_regulator_get_optional(&pdev->dev, "vpcie");
 	if (IS_ERR(imx_pcie->vpcie)) {
 		if (PTR_ERR(imx_pcie->vpcie) != -ENODEV)
-- 
2.51.0