From: sashiko-bot@kernel.org
To: "Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 5/6] arm64: dts: qcom: pm8150b: move vdd-vbus-supply to connector nodes
Date: Tue, 19 May 2026 13:00:47 +0000 [thread overview]
Message-ID: <20260519130048.A16F9C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260519-fix-tcpm-vbus-v1-5-14754695282d@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Resource leak of fwnode reference in Type-C driver probe.
--
commit 41b7b2878f5810dff29da5bdf47dafca44618828
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
usb: typec: tcpm: qcom: prefer VBUS supply from the connector node
This commit modifies the PMIC Type-C port driver to look for the VBUS
supply in the connector node rather than the main device node. It falls
back to the old vdd-vbus property if the connector node does not specify it.
> diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
> index 8051eaa469913..429bd42a0e628 100644
> --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
> +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
[ ... ]
> @@ -720,7 +722,15 @@ int qcom_pmic_typec_port_probe(struct platform_device *pdev,
>
> mutex_init(&pmic_typec_port->vbus_lock);
>
> - pmic_typec_port->vdd_vbus = devm_regulator_get(dev, "vdd-vbus");
> + connector = device_get_named_child_node(dev, "connector");
> + if (!connector)
> + return -EINVAL;
> +
> + pmic_typec_port->vdd_vbus = devm_of_regulator_get_optional(dev,
> + to_of_node(connector),
> + "vbus");
> + if (pmic_typec_port->vdd_vbus == ERR_PTR(-ENODEV))
> + pmic_typec_port->vdd_vbus = devm_regulator_get(dev, "vdd-vbus");
> if (IS_ERR(pmic_typec_port->vdd_vbus))
> return PTR_ERR(pmic_typec_port->vdd_vbus);
device_get_named_child_node() returns a node with its reference count
incremented. Does this code leak the fwnode reference by missing a call to
fwnode_handle_put(connector) on both the error paths and the success path?
For example, when the regulator fetch fails, the function returns directly
without dropping the reference:
if (IS_ERR(pmic_typec_port->vdd_vbus))
return PTR_ERR(pmic_typec_port->vdd_vbus);
Could a call to fwnode_handle_put(connector) be added to ensure the
reference is properly released?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-fix-tcpm-vbus-v1-0-14754695282d@oss.qualcomm.com?part=5
next prev parent reply other threads:[~2026-05-19 13:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 10:48 [PATCH 0/6] usb: typec: tcpm: qcom: use connector to specify VBUS regulator Dmitry Baryshkov
2026-05-19 10:48 ` [PATCH 1/6] dt-bindings: usb: qcom,pmic-typec: deprecate device-specific VBUS Dmitry Baryshkov
2026-05-19 10:58 ` sashiko-bot
2026-05-19 11:26 ` Konrad Dybcio
2026-05-19 11:37 ` Bryan O'Donoghue
2026-05-19 10:48 ` [PATCH 2/6] usb: typec: tcpm: qcom: prefer VBUS supply from the connector node Dmitry Baryshkov
2026-05-19 11:16 ` sashiko-bot
2026-05-19 11:25 ` Konrad Dybcio
2026-05-19 14:05 ` Heikki Krogerus
2026-05-19 10:48 ` [PATCH 3/6] arm64: dts: qcom: pm4125: move vdd-vbus-supply to connector nodes Dmitry Baryshkov
2026-05-19 11:26 ` Konrad Dybcio
2026-05-19 10:48 ` [PATCH 4/6] arm64: dts: qcom: pm7250b: " Dmitry Baryshkov
2026-05-19 11:27 ` Konrad Dybcio
2026-05-19 12:01 ` sashiko-bot
2026-05-19 12:17 ` Dmitry Baryshkov
2026-05-19 10:48 ` [PATCH 5/6] arm64: dts: qcom: pm8150b: " Dmitry Baryshkov
2026-05-19 11:27 ` Konrad Dybcio
2026-05-19 13:00 ` sashiko-bot [this message]
2026-05-19 10:48 ` [PATCH 6/6] arm64: dts: qcom: pmi632: " Dmitry Baryshkov
2026-05-19 11:27 ` Konrad Dybcio
2026-05-19 11:41 ` [PATCH 0/6] usb: typec: tcpm: qcom: use connector to specify VBUS regulator Bryan O'Donoghue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260519130048.A16F9C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.