* [PATCH v4 0/2] phy: qcom: qmp-pcie: Add PCIe PHY no_csr reset support @ 2025-02-20 10:22 Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support Wenbin Yao 0 siblings, 2 replies; 14+ messages in thread From: Wenbin Yao @ 2025-02-20 10:22 UTC (permalink / raw) To: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, manivannan.sadhasivam, quic_devipriy, konrad.dybcio, linux-arm-msm, linux-phy, linux-kernel Cc: quic_wenbyao The series aims to skip phy register programming and drive PCIe PHY with register setting programmed in bootloader by simply toggling no_csr reset, which once togglled, PHY hardware will be reset while PHY registers are retained. First, determine whether PHY setting can be skipped by checking QPHY_START_CTRL register and the existence of nocsr reset. If it is programmed and no_csr reset is supported, do no_csr reset and skip BCR reset which will reset entire PHY. This series also remove has_nocsr_reset flag in qmp_phy_cfg structure and decide whether the PHY supports nocsr reset by checking the existence of nocsr reset in device tree. The series are tested on X1E80100-QCP and HDK8550. The commit messages of this patchset have been modified based on comments and suggestions. Changes in v4: - Add Philipp's Reviewed-by tag to Patch 1/2. - Use PHY instead of phy in comments in Patch 2/2. - Use "if (qmp->nocsr_reset)" instead of "if (!qmp->nocsr_reset)" in function qmp_pcie_exit for readability in Patch 2/2. - Use goto statements in function qmp_pcie_power_on and qmp_pcie_power_off for readability in Patch 2/2. - Refine the comment of why not checking qmp->skip_init when reset PHY in function qmp_pcie_power_off in Patch 2/2. - Link to v3: https://lore.kernel.org/all/20250214104539.281846-1-quic_wenbyao@quicinc.com/ Changes in v3: - Replace devm_reset_control_get_exclusive with devm_reset_control_get_optional_exclusive when get phy_nocsr reset control in Patch 1/2. - Do not ignore -EINVAL when get phy_nocsr reset control in Patch 1/2. - Replace phy_initialized with skip_init in struct qmp_pcie in Patch 2/2. - Add a comment to why not check qmp->skip_init in function qmp_pcie_power_off in Patch 2/2. - Link to v2: https://lore.kernel.org/all/20250211094231.1813558-1-quic_wenbyao@quicinc.com/ Changes in v2: - Add Abel's and Manivannan's Reviewed-by tag to Patch 1/2. - Refine commit msg of Patch 2/2. - Link to v1: https://lore.kernel.org/all/20250121094140.4006801-1-quic_wenbyao@quicinc.com/ Konrad Dybcio (1): phy: qcom: pcie: Determine has_nocsr_reset dynamically Qiang Yu (1): phy: qcom: qmp-pcie: Add PHY register retention support drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 77 ++++++++++++++++-------- 1 file changed, 53 insertions(+), 24 deletions(-) base-commit: bcf2acd8f64b0a5783deeeb5fd70c6163ec5acd7 -- 2.34.1 -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v4 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically 2025-02-20 10:22 [PATCH v4 0/2] phy: qcom: qmp-pcie: Add PCIe PHY no_csr reset support Wenbin Yao @ 2025-02-20 10:22 ` Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support Wenbin Yao 1 sibling, 0 replies; 14+ messages in thread From: Wenbin Yao @ 2025-02-20 10:22 UTC (permalink / raw) To: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, manivannan.sadhasivam, quic_devipriy, konrad.dybcio, linux-arm-msm, linux-phy, linux-kernel Cc: quic_wenbyao From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Decide the in-driver logic based on whether the nocsr reset is present and defer checking the appropriateness of that to dt-bindings to save on boilerplate. Reset controller APIs are fine consuming a nullptr, so no additional checks are necessary there. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> --- drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c index 873f2f9844c6..219266125cf2 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c @@ -2793,8 +2793,6 @@ struct qmp_phy_cfg { bool skip_start_delay; - bool has_nocsr_reset; - /* QMP PHY pipe clock interface rate */ unsigned long pipe_clock_rate; @@ -3685,7 +3683,6 @@ static const struct qmp_phy_cfg sm8550_qmp_gen4x2_pciephy_cfg = { .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, .phy_status = PHYSTATUS_4_20, - .has_nocsr_reset = true, /* 20MHz PHY AUX Clock */ .aux_clock_rate = 20000000, @@ -3718,7 +3715,6 @@ static const struct qmp_phy_cfg sm8650_qmp_gen4x2_pciephy_cfg = { .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, .phy_status = PHYSTATUS_4_20, - .has_nocsr_reset = true, /* 20MHz PHY AUX Clock */ .aux_clock_rate = 20000000, @@ -3836,7 +3832,6 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = { .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, .phy_status = PHYSTATUS_4_20, - .has_nocsr_reset = true, }; static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = { @@ -3870,7 +3865,6 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = { .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, .phy_status = PHYSTATUS_4_20, - .has_nocsr_reset = true, }; static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = { @@ -3902,7 +3896,6 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = { .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, .phy_status = PHYSTATUS_4_20, - .has_nocsr_reset = true, }; static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls) @@ -4203,12 +4196,10 @@ static int qmp_pcie_reset_init(struct qmp_pcie *qmp) if (ret) return dev_err_probe(dev, ret, "failed to get resets\n"); - if (cfg->has_nocsr_reset) { - qmp->nocsr_reset = devm_reset_control_get_exclusive(dev, "phy_nocsr"); - if (IS_ERR(qmp->nocsr_reset)) - return dev_err_probe(dev, PTR_ERR(qmp->nocsr_reset), - "failed to get no-csr reset\n"); - } + qmp->nocsr_reset = devm_reset_control_get_optional_exclusive(dev, "phy_nocsr"); + if (IS_ERR(qmp->nocsr_reset)) + return dev_err_probe(dev, PTR_ERR(qmp->nocsr_reset), + "failed to get no-csr reset\n"); return 0; } -- 2.34.1 -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-20 10:22 [PATCH v4 0/2] phy: qcom: qmp-pcie: Add PCIe PHY no_csr reset support Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically Wenbin Yao @ 2025-02-20 10:22 ` Wenbin Yao 2025-02-24 7:33 ` Manivannan Sadhasivam 1 sibling, 1 reply; 14+ messages in thread From: Wenbin Yao @ 2025-02-20 10:22 UTC (permalink / raw) To: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, manivannan.sadhasivam, quic_devipriy, konrad.dybcio, linux-arm-msm, linux-phy, linux-kernel Cc: quic_wenbyao From: Qiang Yu <quic_qianyu@quicinc.com> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the whole PHY (hardware and register), no_csr reset only resets PHY hardware but retains register values, which means PHY setting can be skipped during PHY init if PCIe link is enabled in booltloader and only no_csr is toggled after that. Hence, determine whether the PHY has been enabled in bootloader by verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is available, skip BCR reset and PHY register setting to establish the PCIe link with bootloader - programmed PHY settings. Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> --- drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 60 +++++++++++++++++++----- 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c index 219266125cf2..6938b72df7fa 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c @@ -2805,6 +2805,7 @@ struct qmp_pcie { const struct qmp_phy_cfg *cfg; bool tcsr_4ln_config; + bool skip_init; void __iomem *serdes; void __iomem *pcs; @@ -3976,7 +3977,9 @@ static int qmp_pcie_init(struct phy *phy) { struct qmp_pcie *qmp = phy_get_drvdata(phy); const struct qmp_phy_cfg *cfg = qmp->cfg; + void __iomem *pcs = qmp->pcs; int ret; + bool phy_initialized; ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs); if (ret) { @@ -3984,10 +3987,18 @@ static int qmp_pcie_init(struct phy *phy) return ret; } - ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); - if (ret) { - dev_err(qmp->dev, "reset assert failed\n"); - goto err_disable_regulators; + phy_initialized = !!(readl(pcs + cfg->regs[QPHY_START_CTRL])); + qmp->skip_init = qmp->nocsr_reset && phy_initialized; + /* + * Toggle BCR reset for PHY that doesn't support no_csr + * reset or has not been initialized + */ + if (!qmp->skip_init) { + ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); + if (ret) { + dev_err(qmp->dev, "reset assert failed\n"); + goto err_disable_regulators; + } } ret = reset_control_assert(qmp->nocsr_reset); @@ -3998,10 +4009,12 @@ static int qmp_pcie_init(struct phy *phy) usleep_range(200, 300); - ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); - if (ret) { - dev_err(qmp->dev, "reset deassert failed\n"); - goto err_assert_reset; + if (!qmp->skip_init) { + ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); + if (ret) { + dev_err(qmp->dev, "reset deassert failed\n"); + goto err_assert_reset; + } } ret = clk_bulk_prepare_enable(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); @@ -4011,7 +4024,8 @@ static int qmp_pcie_init(struct phy *phy) return 0; err_assert_reset: - reset_control_bulk_assert(cfg->num_resets, qmp->resets); + if (!qmp->skip_init) + reset_control_bulk_assert(cfg->num_resets, qmp->resets); err_disable_regulators: regulator_bulk_disable(cfg->num_vregs, qmp->vregs); @@ -4023,7 +4037,10 @@ static int qmp_pcie_exit(struct phy *phy) struct qmp_pcie *qmp = phy_get_drvdata(phy); const struct qmp_phy_cfg *cfg = qmp->cfg; - reset_control_bulk_assert(cfg->num_resets, qmp->resets); + if (qmp->nocsr_reset) + reset_control_assert(qmp->nocsr_reset); + else + reset_control_bulk_assert(cfg->num_resets, qmp->resets); clk_bulk_disable_unprepare(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); @@ -4042,6 +4059,13 @@ static int qmp_pcie_power_on(struct phy *phy) unsigned int mask, val; int ret; + /* + * Write CSR register for PHY that doesn't support no_csr + * reset or has not been initialized + */ + if (qmp->skip_init) + goto skip_tbls_init; + qphy_setbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl); @@ -4053,6 +4077,7 @@ static int qmp_pcie_power_on(struct phy *phy) qmp_pcie_init_registers(qmp, &cfg->tbls); qmp_pcie_init_registers(qmp, mode_tbls); +skip_tbls_init: ret = clk_bulk_prepare_enable(qmp->num_pipe_clks, qmp->pipe_clks); if (ret) return ret; @@ -4063,6 +4088,9 @@ static int qmp_pcie_power_on(struct phy *phy) goto err_disable_pipe_clk; } + if (qmp->skip_init) + goto skip_serdes_start; + /* Pull PHY out of reset state */ qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET); @@ -4072,6 +4100,7 @@ static int qmp_pcie_power_on(struct phy *phy) if (!cfg->skip_start_delay) usleep_range(1000, 1200); +skip_serdes_start: status = pcs + cfg->regs[QPHY_PCS_STATUS]; mask = cfg->phy_status; ret = readl_poll_timeout(status, val, !(val & mask), 200, @@ -4096,7 +4125,15 @@ static int qmp_pcie_power_off(struct phy *phy) clk_bulk_disable_unprepare(qmp->num_pipe_clks, qmp->pipe_clks); - /* PHY reset */ + /* When PHY is powered off, only qmp->nocsr_reset needs to be checked. + * In this way, no matter whether the PHY settings were initially + * programmed by bootloader or PHY driver itself, we can reuse them + * when PHY is powered on next time. + */ + if (qmp->nocsr_reset) + goto skip_phy_deinit; + + /* PHY reset */ qphy_setbits(qmp->pcs, cfg->regs[QPHY_SW_RESET], SW_RESET); /* stop SerDes and Phy-Coding-Sublayer */ @@ -4107,6 +4144,7 @@ static int qmp_pcie_power_off(struct phy *phy) qphy_clrbits(qmp->pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl); +skip_phy_deinit: return 0; } -- 2.34.1 -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-20 10:22 ` [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support Wenbin Yao @ 2025-02-24 7:33 ` Manivannan Sadhasivam 2025-02-24 8:46 ` Wenbin Yao (Consultant) 0 siblings, 1 reply; 14+ messages in thread From: Manivannan Sadhasivam @ 2025-02-24 7:33 UTC (permalink / raw) To: Wenbin Yao Cc: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, konrad.dybcio, linux-arm-msm, linux-phy, linux-kernel On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > From: Qiang Yu <quic_qianyu@quicinc.com> > > Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > whole PHY (hardware and register), no_csr reset only resets PHY hardware > but retains register values, which means PHY setting can be skipped during > PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > after that. > > Hence, determine whether the PHY has been enabled in bootloader by > verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > available, skip BCR reset and PHY register setting to establish the PCIe > link with bootloader - programmed PHY settings. > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> Some nitpicks below. > --- > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 60 +++++++++++++++++++----- > 1 file changed, 49 insertions(+), 11 deletions(-) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > index 219266125cf2..6938b72df7fa 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > @@ -2805,6 +2805,7 @@ struct qmp_pcie { > > const struct qmp_phy_cfg *cfg; > bool tcsr_4ln_config; > + bool skip_init; > > void __iomem *serdes; > void __iomem *pcs; > @@ -3976,7 +3977,9 @@ static int qmp_pcie_init(struct phy *phy) > { > struct qmp_pcie *qmp = phy_get_drvdata(phy); > const struct qmp_phy_cfg *cfg = qmp->cfg; > + void __iomem *pcs = qmp->pcs; > int ret; > + bool phy_initialized; > > ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs); > if (ret) { > @@ -3984,10 +3987,18 @@ static int qmp_pcie_init(struct phy *phy) > return ret; > } > > - ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); > - if (ret) { > - dev_err(qmp->dev, "reset assert failed\n"); > - goto err_disable_regulators; > + phy_initialized = !!(readl(pcs + cfg->regs[QPHY_START_CTRL])); > + qmp->skip_init = qmp->nocsr_reset && phy_initialized; > + /* > + * Toggle BCR reset for PHY that doesn't support no_csr > + * reset or has not been initialized Please make use of 80 column width. > + */ > + if (!qmp->skip_init) { > + ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); > + if (ret) { > + dev_err(qmp->dev, "reset assert failed\n"); > + goto err_disable_regulators; > + } > } > > ret = reset_control_assert(qmp->nocsr_reset); > @@ -3998,10 +4009,12 @@ static int qmp_pcie_init(struct phy *phy) > > usleep_range(200, 300); > > - ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); > - if (ret) { > - dev_err(qmp->dev, "reset deassert failed\n"); > - goto err_assert_reset; > + if (!qmp->skip_init) { > + ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); > + if (ret) { > + dev_err(qmp->dev, "reset deassert failed\n"); > + goto err_assert_reset; > + } > } > > ret = clk_bulk_prepare_enable(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); > @@ -4011,7 +4024,8 @@ static int qmp_pcie_init(struct phy *phy) > return 0; > > err_assert_reset: > - reset_control_bulk_assert(cfg->num_resets, qmp->resets); > + if (!qmp->skip_init) > + reset_control_bulk_assert(cfg->num_resets, qmp->resets); > err_disable_regulators: > regulator_bulk_disable(cfg->num_vregs, qmp->vregs); > > @@ -4023,7 +4037,10 @@ static int qmp_pcie_exit(struct phy *phy) > struct qmp_pcie *qmp = phy_get_drvdata(phy); > const struct qmp_phy_cfg *cfg = qmp->cfg; > > - reset_control_bulk_assert(cfg->num_resets, qmp->resets); > + if (qmp->nocsr_reset) > + reset_control_assert(qmp->nocsr_reset); > + else > + reset_control_bulk_assert(cfg->num_resets, qmp->resets); > > clk_bulk_disable_unprepare(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); > > @@ -4042,6 +4059,13 @@ static int qmp_pcie_power_on(struct phy *phy) > unsigned int mask, val; > int ret; > > + /* > + * Write CSR register for PHY that doesn't support no_csr > + * reset or has not been initialized Same here. > + */ > + if (qmp->skip_init) > + goto skip_tbls_init; > + > qphy_setbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], > cfg->pwrdn_ctrl); > > @@ -4053,6 +4077,7 @@ static int qmp_pcie_power_on(struct phy *phy) > qmp_pcie_init_registers(qmp, &cfg->tbls); > qmp_pcie_init_registers(qmp, mode_tbls); > > +skip_tbls_init: > ret = clk_bulk_prepare_enable(qmp->num_pipe_clks, qmp->pipe_clks); > if (ret) > return ret; > @@ -4063,6 +4088,9 @@ static int qmp_pcie_power_on(struct phy *phy) > goto err_disable_pipe_clk; > } > > + if (qmp->skip_init) > + goto skip_serdes_start; > + > /* Pull PHY out of reset state */ > qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET); > > @@ -4072,6 +4100,7 @@ static int qmp_pcie_power_on(struct phy *phy) > if (!cfg->skip_start_delay) > usleep_range(1000, 1200); > > +skip_serdes_start: > status = pcs + cfg->regs[QPHY_PCS_STATUS]; > mask = cfg->phy_status; > ret = readl_poll_timeout(status, val, !(val & mask), 200, > @@ -4096,7 +4125,15 @@ static int qmp_pcie_power_off(struct phy *phy) > > clk_bulk_disable_unprepare(qmp->num_pipe_clks, qmp->pipe_clks); > > - /* PHY reset */ > + /* When PHY is powered off, only qmp->nocsr_reset needs to be checked. s/'When PHY is powered off,'/'While powering off the PHY,' > + * In this way, no matter whether the PHY settings were initially > + * programmed by bootloader or PHY driver itself, we can reuse them It is really possible to have bootloader not programming the init sequence for no_csr reset platforms? The comment sounds like it is possible. But I heard the opposite. > + * when PHY is powered on next time. > + */ > + if (qmp->nocsr_reset) > + goto skip_phy_deinit; > + > + /* PHY reset */ Spurious tab before the start of the comment. - Mani -- மணிவண்ணன் சதாசிவம் -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-24 7:33 ` Manivannan Sadhasivam @ 2025-02-24 8:46 ` Wenbin Yao (Consultant) 2025-02-24 11:46 ` Konrad Dybcio 0 siblings, 1 reply; 14+ messages in thread From: Wenbin Yao (Consultant) @ 2025-02-24 8:46 UTC (permalink / raw) To: Manivannan Sadhasivam Cc: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, konrad.dybcio, linux-arm-msm, linux-phy, linux-kernel On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: >> From: Qiang Yu <quic_qianyu@quicinc.com> >> >> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the >> whole PHY (hardware and register), no_csr reset only resets PHY hardware >> but retains register values, which means PHY setting can be skipped during >> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled >> after that. >> >> Hence, determine whether the PHY has been enabled in bootloader by >> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is >> available, skip BCR reset and PHY register setting to establish the PCIe >> link with bootloader - programmed PHY settings. >> >> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > Some nitpicks below. > >> --- >> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 60 +++++++++++++++++++----- >> 1 file changed, 49 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c >> index 219266125cf2..6938b72df7fa 100644 >> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c >> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c >> @@ -2805,6 +2805,7 @@ struct qmp_pcie { >> >> const struct qmp_phy_cfg *cfg; >> bool tcsr_4ln_config; >> + bool skip_init; >> >> void __iomem *serdes; >> void __iomem *pcs; >> @@ -3976,7 +3977,9 @@ static int qmp_pcie_init(struct phy *phy) >> { >> struct qmp_pcie *qmp = phy_get_drvdata(phy); >> const struct qmp_phy_cfg *cfg = qmp->cfg; >> + void __iomem *pcs = qmp->pcs; >> int ret; >> + bool phy_initialized; >> >> ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs); >> if (ret) { >> @@ -3984,10 +3987,18 @@ static int qmp_pcie_init(struct phy *phy) >> return ret; >> } >> >> - ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> - if (ret) { >> - dev_err(qmp->dev, "reset assert failed\n"); >> - goto err_disable_regulators; >> + phy_initialized = !!(readl(pcs + cfg->regs[QPHY_START_CTRL])); >> + qmp->skip_init = qmp->nocsr_reset && phy_initialized; >> + /* >> + * Toggle BCR reset for PHY that doesn't support no_csr >> + * reset or has not been initialized > Please make use of 80 column width. Will fix it. > >> + */ >> + if (!qmp->skip_init) { >> + ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> + if (ret) { >> + dev_err(qmp->dev, "reset assert failed\n"); >> + goto err_disable_regulators; >> + } >> } >> >> ret = reset_control_assert(qmp->nocsr_reset); >> @@ -3998,10 +4009,12 @@ static int qmp_pcie_init(struct phy *phy) >> >> usleep_range(200, 300); >> >> - ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); >> - if (ret) { >> - dev_err(qmp->dev, "reset deassert failed\n"); >> - goto err_assert_reset; >> + if (!qmp->skip_init) { >> + ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); >> + if (ret) { >> + dev_err(qmp->dev, "reset deassert failed\n"); >> + goto err_assert_reset; >> + } >> } >> >> ret = clk_bulk_prepare_enable(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); >> @@ -4011,7 +4024,8 @@ static int qmp_pcie_init(struct phy *phy) >> return 0; >> >> err_assert_reset: >> - reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> + if (!qmp->skip_init) >> + reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> err_disable_regulators: >> regulator_bulk_disable(cfg->num_vregs, qmp->vregs); >> >> @@ -4023,7 +4037,10 @@ static int qmp_pcie_exit(struct phy *phy) >> struct qmp_pcie *qmp = phy_get_drvdata(phy); >> const struct qmp_phy_cfg *cfg = qmp->cfg; >> >> - reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> + if (qmp->nocsr_reset) >> + reset_control_assert(qmp->nocsr_reset); >> + else >> + reset_control_bulk_assert(cfg->num_resets, qmp->resets); >> >> clk_bulk_disable_unprepare(ARRAY_SIZE(qmp_pciephy_clk_l), qmp->clks); >> >> @@ -4042,6 +4059,13 @@ static int qmp_pcie_power_on(struct phy *phy) >> unsigned int mask, val; >> int ret; >> >> + /* >> + * Write CSR register for PHY that doesn't support no_csr >> + * reset or has not been initialized > Same here. Will fix it. > >> + */ >> + if (qmp->skip_init) >> + goto skip_tbls_init; >> + >> qphy_setbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], >> cfg->pwrdn_ctrl); >> >> @@ -4053,6 +4077,7 @@ static int qmp_pcie_power_on(struct phy *phy) >> qmp_pcie_init_registers(qmp, &cfg->tbls); >> qmp_pcie_init_registers(qmp, mode_tbls); >> >> +skip_tbls_init: >> ret = clk_bulk_prepare_enable(qmp->num_pipe_clks, qmp->pipe_clks); >> if (ret) >> return ret; >> @@ -4063,6 +4088,9 @@ static int qmp_pcie_power_on(struct phy *phy) >> goto err_disable_pipe_clk; >> } >> >> + if (qmp->skip_init) >> + goto skip_serdes_start; >> + >> /* Pull PHY out of reset state */ >> qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET); >> >> @@ -4072,6 +4100,7 @@ static int qmp_pcie_power_on(struct phy *phy) >> if (!cfg->skip_start_delay) >> usleep_range(1000, 1200); >> >> +skip_serdes_start: >> status = pcs + cfg->regs[QPHY_PCS_STATUS]; >> mask = cfg->phy_status; >> ret = readl_poll_timeout(status, val, !(val & mask), 200, >> @@ -4096,7 +4125,15 @@ static int qmp_pcie_power_off(struct phy *phy) >> >> clk_bulk_disable_unprepare(qmp->num_pipe_clks, qmp->pipe_clks); >> >> - /* PHY reset */ >> + /* When PHY is powered off, only qmp->nocsr_reset needs to be checked. > s/'When PHY is powered off,'/'While powering off the PHY,' Will fix it. > >> + * In this way, no matter whether the PHY settings were initially >> + * programmed by bootloader or PHY driver itself, we can reuse them > It is really possible to have bootloader not programming the init sequence for > no_csr reset platforms? The comment sounds like it is possible. But I heard the > opposite. PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it manually in UEFI shell if we want. > >> + * when PHY is powered on next time. >> + */ >> + if (qmp->nocsr_reset) >> + goto skip_phy_deinit; >> + >> + /* PHY reset */ > Spurious tab before the start of the comment. Will fix it. > > - Mani > -- With best wishes Wenbin -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-24 8:46 ` Wenbin Yao (Consultant) @ 2025-02-24 11:46 ` Konrad Dybcio 2025-02-24 12:24 ` Manivannan Sadhasivam 0 siblings, 1 reply; 14+ messages in thread From: Konrad Dybcio @ 2025-02-24 11:46 UTC (permalink / raw) To: Wenbin Yao (Consultant), Manivannan Sadhasivam Cc: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: >> On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: >>> From: Qiang Yu <quic_qianyu@quicinc.com> >>> >>> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the >>> whole PHY (hardware and register), no_csr reset only resets PHY hardware >>> but retains register values, which means PHY setting can be skipped during >>> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled >>> after that. >>> >>> Hence, determine whether the PHY has been enabled in bootloader by >>> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is >>> available, skip BCR reset and PHY register setting to establish the PCIe >>> link with bootloader - programmed PHY settings. >>> >>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> >> Some nitpicks below. >> >>> --- [...] >> >>> + * In this way, no matter whether the PHY settings were initially >>> + * programmed by bootloader or PHY driver itself, we can reuse them >> It is really possible to have bootloader not programming the init sequence for >> no_csr reset platforms? The comment sounds like it is possible. But I heard the >> opposite. > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > manually in UEFI shell if we want. IIUC this will not be a concern going forward, and this is a special case Konrad -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-24 11:46 ` Konrad Dybcio @ 2025-02-24 12:24 ` Manivannan Sadhasivam 2025-02-25 8:06 ` Wenbin Yao (Consultant) 0 siblings, 1 reply; 14+ messages in thread From: Manivannan Sadhasivam @ 2025-02-24 12:24 UTC (permalink / raw) To: Konrad Dybcio Cc: Wenbin Yao (Consultant), vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: > On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > >> On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > >>> From: Qiang Yu <quic_qianyu@quicinc.com> > >>> > >>> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > >>> whole PHY (hardware and register), no_csr reset only resets PHY hardware > >>> but retains register values, which means PHY setting can be skipped during > >>> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > >>> after that. > >>> > >>> Hence, determine whether the PHY has been enabled in bootloader by > >>> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > >>> available, skip BCR reset and PHY register setting to establish the PCIe > >>> link with bootloader - programmed PHY settings. > >>> > >>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > >>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > >> Some nitpicks below. > >> > >>> --- > > [...] > > >> > >>> + * In this way, no matter whether the PHY settings were initially > >>> + * programmed by bootloader or PHY driver itself, we can reuse them > >> It is really possible to have bootloader not programming the init sequence for > >> no_csr reset platforms? The comment sounds like it is possible. But I heard the > >> opposite. > > > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > > manually in UEFI shell if we want. > > IIUC this will not be a concern going forward, and this is a special case > I'm wondering how many *special* cases we may have to deal with going forward. Anyhow, I would propose to atleast throw an error and fail probe() if: * the platform has no_csr reset AND * bootloader has not initialized the PHY AND * there are no init sequences in the kernel - Mani -- மணிவண்ணன் சதாசிவம் -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-24 12:24 ` Manivannan Sadhasivam @ 2025-02-25 8:06 ` Wenbin Yao (Consultant) 2025-02-25 8:17 ` Manivannan Sadhasivam 0 siblings, 1 reply; 14+ messages in thread From: Wenbin Yao (Consultant) @ 2025-02-25 8:06 UTC (permalink / raw) To: Manivannan Sadhasivam, Konrad Dybcio Cc: vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: > On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: >> On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: >>> On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: >>>> On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: >>>>> From: Qiang Yu <quic_qianyu@quicinc.com> >>>>> >>>>> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the >>>>> whole PHY (hardware and register), no_csr reset only resets PHY hardware >>>>> but retains register values, which means PHY setting can be skipped during >>>>> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled >>>>> after that. >>>>> >>>>> Hence, determine whether the PHY has been enabled in bootloader by >>>>> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is >>>>> available, skip BCR reset and PHY register setting to establish the PCIe >>>>> link with bootloader - programmed PHY settings. >>>>> >>>>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >>>>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> >>>> Some nitpicks below. >>>> >>>>> --- >> [...] >> >>>>> + * In this way, no matter whether the PHY settings were initially >>>>> + * programmed by bootloader or PHY driver itself, we can reuse them >>>> It is really possible to have bootloader not programming the init sequence for >>>> no_csr reset platforms? The comment sounds like it is possible. But I heard the >>>> opposite. >>> PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it >>> manually in UEFI shell if we want. >> IIUC this will not be a concern going forward, and this is a special case >> > I'm wondering how many *special* cases we may have to deal with going forward. > Anyhow, I would propose to atleast throw an error and fail probe() if: > > * the platform has no_csr reset AND > * bootloader has not initialized the PHY AND > * there are no init sequences in the kernel > > - Mani Hmmm, regardless of whether it's a special case, we can't assume that UEFI will enable the PHY supporting no_csr reset on all platforms. It's a bit risky. If we make such an assumption, we also won't need to check whether the PHY is enabled by UEFI during powering on. We just need to check whether no_csr reset is available. But it makes sense to check the exsitence of PHY senquence. How about adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't initialized in UEFI and there is no cfg->tbls, return error and print some error log so that the PCIe controller will fail to probe. -- With best wishes Wenbin -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-25 8:06 ` Wenbin Yao (Consultant) @ 2025-02-25 8:17 ` Manivannan Sadhasivam 2025-02-25 10:08 ` Qiang Yu 0 siblings, 1 reply; 14+ messages in thread From: Manivannan Sadhasivam @ 2025-02-25 8:17 UTC (permalink / raw) To: Wenbin Yao (Consultant) Cc: Konrad Dybcio, vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, quic_qianyu, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: > On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: > > On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: > > > On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > > > > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > > > > > On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > > > > > > From: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > > > Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > > > > > > whole PHY (hardware and register), no_csr reset only resets PHY hardware > > > > > > but retains register values, which means PHY setting can be skipped during > > > > > > PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > > > > > > after that. > > > > > > > > > > > > Hence, determine whether the PHY has been enabled in bootloader by > > > > > > verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > > > > > > available, skip BCR reset and PHY register setting to establish the PCIe > > > > > > link with bootloader - programmed PHY settings. > > > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > > > > > Some nitpicks below. > > > > > > > > > > > --- > > > [...] > > > > > > > > > + * In this way, no matter whether the PHY settings were initially > > > > > > + * programmed by bootloader or PHY driver itself, we can reuse them > > > > > It is really possible to have bootloader not programming the init sequence for > > > > > no_csr reset platforms? The comment sounds like it is possible. But I heard the > > > > > opposite. > > > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > > > > manually in UEFI shell if we want. > > > IIUC this will not be a concern going forward, and this is a special case > > > > > I'm wondering how many *special* cases we may have to deal with going forward. > > Anyhow, I would propose to atleast throw an error and fail probe() if: > > > > * the platform has no_csr reset AND > > * bootloader has not initialized the PHY AND > > * there are no init sequences in the kernel > > > > - Mani > > Hmmm, regardless of whether it's a special case, we can't assume that UEFI > will enable the PHY supporting no_csr reset on all platforms. It's a bit > risky. If we make such an assumption, we also won't need to check whether > the PHY is enabled by UEFI during powering on. We just need to check > whether no_csr reset is available. > I am not supportive of this assumption to be clear. While I am OK with relying on no_csr reset and bootloader programming the PHY, we should also make sure to catch if the PHY doesn't initialize it. Otherwise, the driver would assume that the PHY is working, but the users won't see any PCIe devices. > But it makes sense to check the exsitence of PHY senquence. How about > adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't > initialized in UEFI and there is no cfg->tbls, return error and print some > error log so that the PCIe controller will fail to probe. > Sounds good to me. - Mani -- மணிவண்ணன் சதாசிவம் -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-25 8:17 ` Manivannan Sadhasivam @ 2025-02-25 10:08 ` Qiang Yu 2025-02-25 11:46 ` Dmitry Baryshkov 0 siblings, 1 reply; 14+ messages in thread From: Qiang Yu @ 2025-02-25 10:08 UTC (permalink / raw) To: Manivannan Sadhasivam, Wenbin Yao (Consultant) Cc: Konrad Dybcio, vkoul, kishon, p.zabel, dmitry.baryshkov, abel.vesa, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On 2/25/2025 4:17 PM, Manivannan Sadhasivam wrote: > On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: >> On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: >>> On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: >>>> On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: >>>>> On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: >>>>>> On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: >>>>>>> From: Qiang Yu <quic_qianyu@quicinc.com> >>>>>>> >>>>>>> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the >>>>>>> whole PHY (hardware and register), no_csr reset only resets PHY hardware >>>>>>> but retains register values, which means PHY setting can be skipped during >>>>>>> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled >>>>>>> after that. >>>>>>> >>>>>>> Hence, determine whether the PHY has been enabled in bootloader by >>>>>>> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is >>>>>>> available, skip BCR reset and PHY register setting to establish the PCIe >>>>>>> link with bootloader - programmed PHY settings. >>>>>>> >>>>>>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >>>>>>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> >>>>>> Some nitpicks below. >>>>>> >>>>>>> --- >>>> [...] >>>> >>>>>>> + * In this way, no matter whether the PHY settings were initially >>>>>>> + * programmed by bootloader or PHY driver itself, we can reuse them >>>>>> It is really possible to have bootloader not programming the init sequence for >>>>>> no_csr reset platforms? The comment sounds like it is possible. But I heard the >>>>>> opposite. >>>>> PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it >>>>> manually in UEFI shell if we want. >>>> IIUC this will not be a concern going forward, and this is a special case >>>> >>> I'm wondering how many *special* cases we may have to deal with going forward. >>> Anyhow, I would propose to atleast throw an error and fail probe() if: >>> >>> * the platform has no_csr reset AND >>> * bootloader has not initialized the PHY AND >>> * there are no init sequences in the kernel >>> >>> - Mani >> Hmmm, regardless of whether it's a special case, we can't assume that UEFI >> will enable the PHY supporting no_csr reset on all platforms. It's a bit >> risky. If we make such an assumption, we also won't need to check whether >> the PHY is enabled by UEFI during powering on. We just need to check >> whether no_csr reset is available. >> > I am not supportive of this assumption to be clear. While I am OK with relying > on no_csr reset and bootloader programming the PHY, we should also make sure to > catch if the PHY doesn't initialize it. Otherwise, the driver would assume that > the PHY is working, but the users won't see any PCIe devices. > >> But it makes sense to check the exsitence of PHY senquence. How about >> adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't >> initialized in UEFI and there is no cfg->tbls, return error and print some >> error log so that the PCIe controller will fail to probe. >> > Sounds good to me. I'm wondering is it necessary to add this check? In current PHY driver, for PHY that doesn't suppot no_csr reset there is also no such check. If a PHY supports no_csr reset and isn't init in UEFI and there is no cfg->tbls, the worst issue is link training fail and PCIe controller will also fail to probe. Adding sucj check seems not change the result. Thanks, Qiang > > - Mani > -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-25 10:08 ` Qiang Yu @ 2025-02-25 11:46 ` Dmitry Baryshkov 2025-02-26 3:12 ` Qiang Yu 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Baryshkov @ 2025-02-25 11:46 UTC (permalink / raw) To: Qiang Yu Cc: Manivannan Sadhasivam, Wenbin Yao (Consultant), Konrad Dybcio, vkoul, kishon, p.zabel, abel.vesa, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On Tue, Feb 25, 2025 at 06:08:03PM +0800, Qiang Yu wrote: > > On 2/25/2025 4:17 PM, Manivannan Sadhasivam wrote: > > On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: > > > On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: > > > > On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: > > > > > On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > > > > > > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > > > > > > > On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > > > > > > > > From: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > > > > > > > Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > > > > > > > > whole PHY (hardware and register), no_csr reset only resets PHY hardware > > > > > > > > but retains register values, which means PHY setting can be skipped during > > > > > > > > PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > > > > > > > > after that. > > > > > > > > > > > > > > > > Hence, determine whether the PHY has been enabled in bootloader by > > > > > > > > verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > > > > > > > > available, skip BCR reset and PHY register setting to establish the PCIe > > > > > > > > link with bootloader - programmed PHY settings. > > > > > > > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > > > > > > > Some nitpicks below. > > > > > > > > > > > > > > > --- > > > > > [...] > > > > > > > > > > > > > + * In this way, no matter whether the PHY settings were initially > > > > > > > > + * programmed by bootloader or PHY driver itself, we can reuse them > > > > > > > It is really possible to have bootloader not programming the init sequence for > > > > > > > no_csr reset platforms? The comment sounds like it is possible. But I heard the > > > > > > > opposite. > > > > > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > > > > > > manually in UEFI shell if we want. > > > > > IIUC this will not be a concern going forward, and this is a special case > > > > > > > > > I'm wondering how many *special* cases we may have to deal with going forward. > > > > Anyhow, I would propose to atleast throw an error and fail probe() if: > > > > > > > > * the platform has no_csr reset AND > > > > * bootloader has not initialized the PHY AND > > > > * there are no init sequences in the kernel > > > > > > > > - Mani > > > Hmmm, regardless of whether it's a special case, we can't assume that UEFI > > > will enable the PHY supporting no_csr reset on all platforms. It's a bit > > > risky. If we make such an assumption, we also won't need to check whether > > > the PHY is enabled by UEFI during powering on. We just need to check > > > whether no_csr reset is available. > > > > > I am not supportive of this assumption to be clear. While I am OK with relying > > on no_csr reset and bootloader programming the PHY, we should also make sure to > > catch if the PHY doesn't initialize it. Otherwise, the driver would assume that > > the PHY is working, but the users won't see any PCIe devices. > > > > > But it makes sense to check the exsitence of PHY senquence. How about > > > adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't > > > initialized in UEFI and there is no cfg->tbls, return error and print some > > > error log so that the PCIe controller will fail to probe. > > > > > Sounds good to me. > I'm wondering is it necessary to add this check? In current PHY driver, > for PHY that doesn't suppot no_csr reset there is also no such check. > If a PHY supports no_csr reset and isn't init in UEFI and there is no > cfg->tbls, the worst issue is link training fail and PCIe controller will > also fail to probe. Adding sucj check seems not change the result. Failing the training is a random error which can mean a lot, e.g. the missing voltage rail. An explicit check is beneficial, it helps developers (and users) to better understand the reason of the failure. -- With best wishes Dmitry -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-25 11:46 ` Dmitry Baryshkov @ 2025-02-26 3:12 ` Qiang Yu 2025-02-26 5:19 ` Dmitry Baryshkov 0 siblings, 1 reply; 14+ messages in thread From: Qiang Yu @ 2025-02-26 3:12 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Manivannan Sadhasivam, Wenbin Yao (Consultant), Konrad Dybcio, vkoul, kishon, p.zabel, abel.vesa, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On 2/25/2025 7:46 PM, Dmitry Baryshkov wrote: > On Tue, Feb 25, 2025 at 06:08:03PM +0800, Qiang Yu wrote: >> On 2/25/2025 4:17 PM, Manivannan Sadhasivam wrote: >>> On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: >>>> On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: >>>>> On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: >>>>>> On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: >>>>>>> On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: >>>>>>>> On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: >>>>>>>>> From: Qiang Yu <quic_qianyu@quicinc.com> >>>>>>>>> >>>>>>>>> Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the >>>>>>>>> whole PHY (hardware and register), no_csr reset only resets PHY hardware >>>>>>>>> but retains register values, which means PHY setting can be skipped during >>>>>>>>> PHY init if PCIe link is enabled in booltloader and only no_csr is toggled >>>>>>>>> after that. >>>>>>>>> >>>>>>>>> Hence, determine whether the PHY has been enabled in bootloader by >>>>>>>>> verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is >>>>>>>>> available, skip BCR reset and PHY register setting to establish the PCIe >>>>>>>>> link with bootloader - programmed PHY settings. >>>>>>>>> >>>>>>>>> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> >>>>>>>>> Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> >>>>>>>> Some nitpicks below. >>>>>>>> >>>>>>>>> --- >>>>>> [...] >>>>>> >>>>>>>>> + * In this way, no matter whether the PHY settings were initially >>>>>>>>> + * programmed by bootloader or PHY driver itself, we can reuse them >>>>>>>> It is really possible to have bootloader not programming the init sequence for >>>>>>>> no_csr reset platforms? The comment sounds like it is possible. But I heard the >>>>>>>> opposite. >>>>>>> PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it >>>>>>> manually in UEFI shell if we want. >>>>>> IIUC this will not be a concern going forward, and this is a special case >>>>>> >>>>> I'm wondering how many *special* cases we may have to deal with going forward. >>>>> Anyhow, I would propose to atleast throw an error and fail probe() if: >>>>> >>>>> * the platform has no_csr reset AND >>>>> * bootloader has not initialized the PHY AND >>>>> * there are no init sequences in the kernel >>>>> >>>>> - Mani >>>> Hmmm, regardless of whether it's a special case, we can't assume that UEFI >>>> will enable the PHY supporting no_csr reset on all platforms. It's a bit >>>> risky. If we make such an assumption, we also won't need to check whether >>>> the PHY is enabled by UEFI during powering on. We just need to check >>>> whether no_csr reset is available. >>>> >>> I am not supportive of this assumption to be clear. While I am OK with relying >>> on no_csr reset and bootloader programming the PHY, we should also make sure to >>> catch if the PHY doesn't initialize it. Otherwise, the driver would assume that >>> the PHY is working, but the users won't see any PCIe devices. >>> >>>> But it makes sense to check the exsitence of PHY senquence. How about >>>> adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't >>>> initialized in UEFI and there is no cfg->tbls, return error and print some >>>> error log so that the PCIe controller will fail to probe. >>>> >>> Sounds good to me. >> I'm wondering is it necessary to add this check? In current PHY driver, >> for PHY that doesn't suppot no_csr reset there is also no such check. >> If a PHY supports no_csr reset and isn't init in UEFI and there is no >> cfg->tbls, the worst issue is link training fail and PCIe controller will >> also fail to probe. Adding sucj check seems not change the result. > Failing the training is a random error which can mean a lot, e.g. the > missing voltage rail. An explicit check is beneficial, it helps > developers (and users) to better understand the reason of the failure. In the struct qmp_phy_cfg, tbls is not a pointer, we can't directly check if tbls == NULL to determine if the PHY init sequence is available. Can we add a separate patch to change the definition from "const struct qmp_phy_cfg_tbls tbls" to "const struct qmp_phy_cfg_tbls *tbls" like tlbs_rc and tbls_ep, even though this will affect all platforms? -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-26 3:12 ` Qiang Yu @ 2025-02-26 5:19 ` Dmitry Baryshkov 2025-02-26 5:31 ` Manivannan Sadhasivam 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Baryshkov @ 2025-02-26 5:19 UTC (permalink / raw) To: Qiang Yu Cc: Manivannan Sadhasivam, Wenbin Yao (Consultant), Konrad Dybcio, vkoul, kishon, p.zabel, abel.vesa, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On Wed, Feb 26, 2025 at 11:12:18AM +0800, Qiang Yu wrote: > > On 2/25/2025 7:46 PM, Dmitry Baryshkov wrote: > > On Tue, Feb 25, 2025 at 06:08:03PM +0800, Qiang Yu wrote: > > > On 2/25/2025 4:17 PM, Manivannan Sadhasivam wrote: > > > > On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: > > > > > On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: > > > > > > On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: > > > > > > > On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > > > > > > > > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > > > > > > > > > On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > > > > > > > > > > From: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > > > > > > > > > > > Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > > > > > > > > > > whole PHY (hardware and register), no_csr reset only resets PHY hardware > > > > > > > > > > but retains register values, which means PHY setting can be skipped during > > > > > > > > > > PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > > > > > > > > > > after that. > > > > > > > > > > > > > > > > > > > > Hence, determine whether the PHY has been enabled in bootloader by > > > > > > > > > > verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > > > > > > > > > > available, skip BCR reset and PHY register setting to establish the PCIe > > > > > > > > > > link with bootloader - programmed PHY settings. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > > > > > > > > > Some nitpicks below. > > > > > > > > > > > > > > > > > > > --- > > > > > > > [...] > > > > > > > > > > > > > > > > > + * In this way, no matter whether the PHY settings were initially > > > > > > > > > > + * programmed by bootloader or PHY driver itself, we can reuse them > > > > > > > > > It is really possible to have bootloader not programming the init sequence for > > > > > > > > > no_csr reset platforms? The comment sounds like it is possible. But I heard the > > > > > > > > > opposite. > > > > > > > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > > > > > > > > manually in UEFI shell if we want. > > > > > > > IIUC this will not be a concern going forward, and this is a special case > > > > > > > > > > > > > I'm wondering how many *special* cases we may have to deal with going forward. > > > > > > Anyhow, I would propose to atleast throw an error and fail probe() if: > > > > > > > > > > > > * the platform has no_csr reset AND > > > > > > * bootloader has not initialized the PHY AND > > > > > > * there are no init sequences in the kernel > > > > > > > > > > > > - Mani > > > > > Hmmm, regardless of whether it's a special case, we can't assume that UEFI > > > > > will enable the PHY supporting no_csr reset on all platforms. It's a bit > > > > > risky. If we make such an assumption, we also won't need to check whether > > > > > the PHY is enabled by UEFI during powering on. We just need to check > > > > > whether no_csr reset is available. > > > > > > > > > I am not supportive of this assumption to be clear. While I am OK with relying > > > > on no_csr reset and bootloader programming the PHY, we should also make sure to > > > > catch if the PHY doesn't initialize it. Otherwise, the driver would assume that > > > > the PHY is working, but the users won't see any PCIe devices. > > > > > > > > > But it makes sense to check the exsitence of PHY senquence. How about > > > > > adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't > > > > > initialized in UEFI and there is no cfg->tbls, return error and print some > > > > > error log so that the PCIe controller will fail to probe. > > > > > > > > > Sounds good to me. > > > I'm wondering is it necessary to add this check? In current PHY driver, > > > for PHY that doesn't suppot no_csr reset there is also no such check. > > > If a PHY supports no_csr reset and isn't init in UEFI and there is no > > > cfg->tbls, the worst issue is link training fail and PCIe controller will > > > also fail to probe. Adding sucj check seems not change the result. > > Failing the training is a random error which can mean a lot, e.g. the > > missing voltage rail. An explicit check is beneficial, it helps > > developers (and users) to better understand the reason of the failure. > In the struct qmp_phy_cfg, tbls is not a pointer, we can't directly check > if tbls == NULL to determine if the PHY init sequence is available. Can we > add a separate patch to change the definition from > "const struct qmp_phy_cfg_tbls tbls" to > "const struct qmp_phy_cfg_tbls *tbls" like tlbs_rc and tbls_ep, even though > this will affect all platforms? Of course no. There is no need to introduce extra indirection. Checking for qmp_phy_cfg.tbls.serdes_num should be more than enough. No matter what, the PHY with a proper configuration tables will have non-empty SERDES table. -- With best wishes Dmitry -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support 2025-02-26 5:19 ` Dmitry Baryshkov @ 2025-02-26 5:31 ` Manivannan Sadhasivam 0 siblings, 0 replies; 14+ messages in thread From: Manivannan Sadhasivam @ 2025-02-26 5:31 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Qiang Yu, Wenbin Yao (Consultant), Konrad Dybcio, vkoul, kishon, p.zabel, abel.vesa, neil.armstrong, quic_devipriy, linux-arm-msm, linux-phy, linux-kernel On Wed, Feb 26, 2025 at 07:19:11AM +0200, Dmitry Baryshkov wrote: > On Wed, Feb 26, 2025 at 11:12:18AM +0800, Qiang Yu wrote: > > > > On 2/25/2025 7:46 PM, Dmitry Baryshkov wrote: > > > On Tue, Feb 25, 2025 at 06:08:03PM +0800, Qiang Yu wrote: > > > > On 2/25/2025 4:17 PM, Manivannan Sadhasivam wrote: > > > > > On Tue, Feb 25, 2025 at 04:06:16PM +0800, Wenbin Yao (Consultant) wrote: > > > > > > On 2/24/2025 8:24 PM, Manivannan Sadhasivam wrote: > > > > > > > On Mon, Feb 24, 2025 at 12:46:44PM +0100, Konrad Dybcio wrote: > > > > > > > > On 24.02.2025 9:46 AM, Wenbin Yao (Consultant) wrote: > > > > > > > > > On 2/24/2025 3:33 PM, Manivannan Sadhasivam wrote: > > > > > > > > > > On Thu, Feb 20, 2025 at 06:22:53PM +0800, Wenbin Yao wrote: > > > > > > > > > > > From: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > > > > > > > > > > > > > Some QCOM PCIe PHYs support no_csr reset. Unlike BCR reset which resets the > > > > > > > > > > > whole PHY (hardware and register), no_csr reset only resets PHY hardware > > > > > > > > > > > but retains register values, which means PHY setting can be skipped during > > > > > > > > > > > PHY init if PCIe link is enabled in booltloader and only no_csr is toggled > > > > > > > > > > > after that. > > > > > > > > > > > > > > > > > > > > > > Hence, determine whether the PHY has been enabled in bootloader by > > > > > > > > > > > verifying QPHY_START_CTRL register. If it's programmed and no_csr reset is > > > > > > > > > > > available, skip BCR reset and PHY register setting to establish the PCIe > > > > > > > > > > > link with bootloader - programmed PHY settings. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> > > > > > > > > > > > Signed-off-by: Wenbin Yao <quic_wenbyao@quicinc.com> > > > > > > > > > > Some nitpicks below. > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > + * In this way, no matter whether the PHY settings were initially > > > > > > > > > > > + * programmed by bootloader or PHY driver itself, we can reuse them > > > > > > > > > > It is really possible to have bootloader not programming the init sequence for > > > > > > > > > > no_csr reset platforms? The comment sounds like it is possible. But I heard the > > > > > > > > > > opposite. > > > > > > > > > PCIe3 on X1E80100 QCP is disabled by default in UEFI. We need to enable it > > > > > > > > > manually in UEFI shell if we want. > > > > > > > > IIUC this will not be a concern going forward, and this is a special case > > > > > > > > > > > > > > > I'm wondering how many *special* cases we may have to deal with going forward. > > > > > > > Anyhow, I would propose to atleast throw an error and fail probe() if: > > > > > > > > > > > > > > * the platform has no_csr reset AND > > > > > > > * bootloader has not initialized the PHY AND > > > > > > > * there are no init sequences in the kernel > > > > > > > > > > > > > > - Mani > > > > > > Hmmm, regardless of whether it's a special case, we can't assume that UEFI > > > > > > will enable the PHY supporting no_csr reset on all platforms. It's a bit > > > > > > risky. If we make such an assumption, we also won't need to check whether > > > > > > the PHY is enabled by UEFI during powering on. We just need to check > > > > > > whether no_csr reset is available. > > > > > > > > > > > I am not supportive of this assumption to be clear. While I am OK with relying > > > > > on no_csr reset and bootloader programming the PHY, we should also make sure to > > > > > catch if the PHY doesn't initialize it. Otherwise, the driver would assume that > > > > > the PHY is working, but the users won't see any PCIe devices. > > > > > > > > > > > But it makes sense to check the exsitence of PHY senquence. How about > > > > > > adding the check in qmp_pcie_init, if a PHY supports no_csr reset and isn't > > > > > > initialized in UEFI and there is no cfg->tbls, return error and print some > > > > > > error log so that the PCIe controller will fail to probe. > > > > > > > > > > > Sounds good to me. > > > > I'm wondering is it necessary to add this check? In current PHY driver, > > > > for PHY that doesn't suppot no_csr reset there is also no such check. > > > > If a PHY supports no_csr reset and isn't init in UEFI and there is no > > > > cfg->tbls, the worst issue is link training fail and PCIe controller will > > > > also fail to probe. Adding sucj check seems not change the result. > > > Failing the training is a random error which can mean a lot, e.g. the > > > missing voltage rail. An explicit check is beneficial, it helps > > > developers (and users) to better understand the reason of the failure. > > In the struct qmp_phy_cfg, tbls is not a pointer, we can't directly check > > if tbls == NULL to determine if the PHY init sequence is available. Can we > > add a separate patch to change the definition from > > "const struct qmp_phy_cfg_tbls tbls" to > > "const struct qmp_phy_cfg_tbls *tbls" like tlbs_rc and tbls_ep, even though > > this will affect all platforms? > > Of course no. There is no need to introduce extra indirection. Checking > for qmp_phy_cfg.tbls.serdes_num should be more than enough. No matter > what, the PHY with a proper configuration tables will have non-empty > SERDES table. > +1. The check needs to be present in this series itself and it makes absolute sense to have it. Otherwise, it will become a hard to debug issue. - Mani -- மணிவண்ணன் சதாசிவம் -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-02-26 5:32 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-02-20 10:22 [PATCH v4 0/2] phy: qcom: qmp-pcie: Add PCIe PHY no_csr reset support Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically Wenbin Yao 2025-02-20 10:22 ` [PATCH v4 2/2] phy: qcom: qmp-pcie: Add PHY register retention support Wenbin Yao 2025-02-24 7:33 ` Manivannan Sadhasivam 2025-02-24 8:46 ` Wenbin Yao (Consultant) 2025-02-24 11:46 ` Konrad Dybcio 2025-02-24 12:24 ` Manivannan Sadhasivam 2025-02-25 8:06 ` Wenbin Yao (Consultant) 2025-02-25 8:17 ` Manivannan Sadhasivam 2025-02-25 10:08 ` Qiang Yu 2025-02-25 11:46 ` Dmitry Baryshkov 2025-02-26 3:12 ` Qiang Yu 2025-02-26 5:19 ` Dmitry Baryshkov 2025-02-26 5:31 ` Manivannan Sadhasivam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox