From: sashiko-bot@kernel.org
To: "Krishna Kurapati" <krishna.kurapati@oss.qualcomm.com>
Cc: neil.armstrong@linaro.org, robh@kernel.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, olteanv@gmail.com,
vkoul@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 4/5] phy: qcom: m31-eusb2: Set phy type to EUSB2
Date: Wed, 26 Aug 2026 17:10:09 +0000 [thread overview]
Message-ID: <20260826171009.916911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826-eusb2-interrupt-v6-v6-4-ae2601cfa80c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] m31eusb2_phy_init fails to propagate error codes and always returns 0.
--
commit a59148cf39dc0afc1f852eb07be581b93aa157f1
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
phy: qcom: m31-eusb2: Set phy type to EUSB2
USB controllers like DWC3 are agnostic of the kind of phy (USB2/eUSB2)
connected to it. Set the phy type to EUSB2 to let the controller know
the phy type when queried during its probe.
> diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> index 0bec8657149c9..7e6b16b6952b5 100644
> --- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but m31eusb2_phy_init() fails to
propagate error codes and always returns 0.
If clk_prepare_enable() or phy_init(phy->repeater) fails, the code jumps
to the disable_repeater or disable_vreg labels:
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
...
disable_repeater:
phy_exit(phy->repeater);
disable_vreg:
regulator_bulk_disable(M31_EUSB_NUM_VREGS, phy->vregs);
return 0;
}
Should this return the trapped error code ret instead of 0?
If a consumer driver like DWC3 receives a success status but the PHY
initialization actually failed, could it attempt to access an unpowered or
unclocked PHY?
Additionally, failure codes from hardware initialization functions like
m31eusb2_phy_write_sequence() are ignored:
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
...
reset_control_deassert(phy->reset);
m31eusb2_phy_write_sequence(phy, data->setup_seq, data->setup_seq_nregs);
...
}
Should the return value of m31eusb2_phy_write_sequence() be checked and
propagated as well?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-eusb2-interrupt-v6-v6-0-ae2601cfa80c@oss.qualcomm.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Krishna Kurapati" <krishna.kurapati@oss.qualcomm.com>
Cc: neil.armstrong@linaro.org, robh@kernel.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, olteanv@gmail.com,
vkoul@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 4/5] phy: qcom: m31-eusb2: Set phy type to EUSB2
Date: Wed, 26 Aug 2026 17:10:09 +0000 [thread overview]
Message-ID: <20260826171009.916911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826-eusb2-interrupt-v6-v6-4-ae2601cfa80c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] m31eusb2_phy_init fails to propagate error codes and always returns 0.
--
commit a59148cf39dc0afc1f852eb07be581b93aa157f1
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
phy: qcom: m31-eusb2: Set phy type to EUSB2
USB controllers like DWC3 are agnostic of the kind of phy (USB2/eUSB2)
connected to it. Set the phy type to EUSB2 to let the controller know
the phy type when queried during its probe.
> diff --git a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> index 0bec8657149c9..7e6b16b6952b5 100644
> --- a/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-m31-eusb2.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but m31eusb2_phy_init() fails to
propagate error codes and always returns 0.
If clk_prepare_enable() or phy_init(phy->repeater) fails, the code jumps
to the disable_repeater or disable_vreg labels:
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
...
disable_repeater:
phy_exit(phy->repeater);
disable_vreg:
regulator_bulk_disable(M31_EUSB_NUM_VREGS, phy->vregs);
return 0;
}
Should this return the trapped error code ret instead of 0?
If a consumer driver like DWC3 receives a success status but the PHY
initialization actually failed, could it attempt to access an unpowered or
unclocked PHY?
Additionally, failure codes from hardware initialization functions like
m31eusb2_phy_write_sequence() are ignored:
drivers/phy/qualcomm/phy-qcom-m31-eusb2.c:m31eusb2_phy_init() {
...
reset_control_deassert(phy->reset);
m31eusb2_phy_write_sequence(phy, data->setup_seq, data->setup_seq_nregs);
...
}
Should the return value of m31eusb2_phy_write_sequence() be checked and
propagated as well?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-eusb2-interrupt-v6-v6-0-ae2601cfa80c@oss.qualcomm.com?part=4
next prev parent reply other threads:[~2026-08-26 17:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 17:02 [PATCH v6 0/5] Modify interrupt handling for eUSB2 Phy targets Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-08-26 17:02 ` [PATCH v6 1/5] dt-bindings: phy: Add PHY_TYPE_EUSB2 definition Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-08-31 6:46 ` Krzysztof Kozlowski
2026-08-31 6:46 ` Krzysztof Kozlowski
2026-08-26 17:02 ` [PATCH v6 2/5] include: linux: phy: Add phy attribute "type" and associated helpers Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-09-04 23:01 ` Thinh Nguyen
2026-09-04 23:01 ` Thinh Nguyen
2026-08-26 17:02 ` [PATCH v6 3/5] phy: snps-eusb2: Set phy type to EUSB2 Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-09-04 23:02 ` Thinh Nguyen
2026-09-04 23:02 ` Thinh Nguyen
2026-08-26 17:02 ` [PATCH v6 4/5] phy: qcom: m31-eusb2: " Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-08-26 17:10 ` sashiko-bot [this message]
2026-08-26 17:10 ` sashiko-bot
2026-09-04 23:02 ` Thinh Nguyen
2026-09-04 23:02 ` Thinh Nguyen
2026-08-26 17:02 ` [PATCH v6 5/5] usb: dwc3: qcom: Modify interrupt handling for eUSB2 Phy targets Krishna Kurapati
2026-08-26 17:02 ` Krishna Kurapati
2026-08-26 17:19 ` sashiko-bot
2026-08-26 17:19 ` sashiko-bot
2026-09-02 10:28 ` Konrad Dybcio
2026-09-02 10:28 ` Konrad Dybcio
2026-09-04 23:07 ` Thinh Nguyen
2026-09-04 23:07 ` Thinh Nguyen
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=20260826171009.916911F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krishna.kurapati@oss.qualcomm.com \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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.