Re: [PATCH v2 1/2] phy: qcom: pcie: Determine has_nocsr_reset dynamically

From: Wenbin Yao (Consultant)
Date: Thu Feb 13 2025 - 03:10:28 EST


On 2/12/2025 8:31 PM, Konrad Dybcio wrote:
On 11.02.2025 10:53 AM, Philipp Zabel wrote:
On Di, 2025-02-11 at 17:42 +0800, Wenbin Yao wrote:
From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxxx>
Signed-off-by: Wenbin Yao <quic_wenbyao@xxxxxxxxxxx>
Reviewed-by: Abel Vesa <abel.vesa@xxxxxxxxxx>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx>
---
[...]

static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
@@ -4203,11 +4196,14 @@ 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))
+ qmp->nocsr_reset = devm_reset_control_get_exclusive(dev, "phy_nocsr");
+ if (IS_ERR(qmp->nocsr_reset)) {
+ if (PTR_ERR(qmp->nocsr_reset) == -ENOENT ||
+ PTR_ERR(qmp->nocsr_reset) == -EINVAL)
Why is -EINVAL ignored here?
If the NOCSR (partial) reset is missing, we can still assert the "full" reset
and program the hardware from the ground up. It's also needed for backwards
dt compat as not all platforms described it when originally added.

Seems like we really can't ignore -EINVAL. If no_csr reset is missing in
dts, it will return -ENOENT, which is turned into NULL by
devm_reset_control_get_optional_exclusive. -EINVAL indicates something
wrong in args we passed to the function and the reset property that need to
be fixed.


Without this you could just use
devm_reset_control_get_optional_exclusive(), which already turns -
ENOENT into NULL. That seems to me the correct thing to do, as from
driver point-of-view, this reset control is optional.
Good point, I forgot _optional_ was a thing in the reset framework

Konrad

Will use devm_reset_control_get_optional_exclusive function in patch v3.

--
With best wishes
Wenbin