From: sashiko-bot@kernel.org
To: "Ronak Raheja" <ronak.raheja@oss.qualcomm.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, olteanv@gmail.com,
devicetree@vger.kernel.org, vkoul@kernel.org,
conor+dt@kernel.org, neil.armstrong@linaro.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH v3 4/4] phy: qualcomm: qmp-combo: Add support for Hawi SoC
Date: Fri, 08 May 2026 23:26:19 +0000 [thread overview]
Message-ID: <20260508232620.2FD04C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260508213234.4643-5-ronak.raheja@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing DP PHY function pointers in `hawi_usb3dpphy_cfg` lead to NULL pointer dereferences when the DP PHY is initialized.
- [High] Valid register offset `0x00` causes the AON toggle hardware reset override to be silently skipped.
--
commit 39c99ec3129f1da7348c282db12eb565e967941d
Author: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
phy: qualcomm: qmp-combo: Add support for Hawi SoC
This commit adds support for the USB3-DP combo PHY found on the Hawi
platform, introducing new V10 register layouts and the COM AON register
module.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 93f1aa10d4008..53b709ea93d52 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
[ ... ]
> @@ -2705,6 +2895,27 @@ static const struct qmp_phy_cfg x1e80100_usb3dpphy_cfg = {
> .regs = qmp_v6_n4_usb3phy_regs_layout,
> };
>
> +static const struct qmp_phy_cfg hawi_usb3dpphy_cfg = {
> + .offsets = &qmp_combo_offsets_v10,
> +
> + .serdes_tbl = hawi_usb3_serdes_tbl,
> + .serdes_tbl_num = ARRAY_SIZE(hawi_usb3_serdes_tbl),
> + .tx_tbl = hawi_usb3_tx_tbl,
> + .tx_tbl_num = ARRAY_SIZE(hawi_usb3_tx_tbl),
> + .rx_tbl = hawi_usb3_rx_tbl,
> + .rx_tbl_num = ARRAY_SIZE(hawi_usb3_rx_tbl),
> + .pcs_tbl = hawi_usb3_pcs_tbl,
> + .pcs_tbl_num = ARRAY_SIZE(hawi_usb3_pcs_tbl),
> + .pcs_usb_tbl = hawi_usb3_pcs_usb_tbl,
> + .pcs_usb_tbl_num = ARRAY_SIZE(hawi_usb3_pcs_usb_tbl),
> +
> + .regs = qmp_v10_usb3phy_regs_layout,
> + .reset_list = msm8996_usb3phy_reset_l,
> + .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> + .vreg_list = qmp_phy_vreg_l,
> + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> +};
Does this configuration miss the DP PHY function pointers?
Because this is a USB3-DP combo PHY, the driver unconditionally creates the DP
PHY. When a DisplayPort controller tries to initialize it, functions like
qmp_combo_dp_init() and qmp_combo_dp_power_on() will unconditionally call
cfg->dp_aux_init(qmp) and cfg->configure_dp_tx(qmp).
Without these pointers defined in hawi_usb3dpphy_cfg, will this lead to a NULL
pointer dereference and a kernel panic upon DP PHY initialization?
[ ... ]
> @@ -3699,9 +3915,9 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
> SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
>
> /* override hardware control for reset of qmp phy */
> - if (pcs_aon && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> - qphy_clrbits(pcs_aon, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> - qphy_clrbits(pcs_aon, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> + if (aon_toggle && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> + qphy_clrbits(aon_toggle, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> + qphy_clrbits(aon_toggle, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> }
Is it possible for the hardware reset override to be silently skipped here?
The V10 register layout maps QPHY_AON_TOGGLE_ENABLE to
QPHY_V10_COM_AON_USB3_AON_TOGGLE_ENABLE, which is defined as 0x00 in
phy-qcom-qmp-com-aon-v10.h.
Because 0x00 is a valid register offset but evaluates to false in C, the
check for cfg->regs[QPHY_AON_TOGGLE_ENABLE] will fail. This would skip the
qphy_clrbits() calls entirely, bypassing the necessary hardware reset override
sequence and leaving the PHY in a broken state.
Could we use a different way to check if this register is supported by the
layout without relying on the truthiness of the offset value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508213234.4643-1-ronak.raheja@oss.qualcomm.com?part=4
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Ronak Raheja" <ronak.raheja@oss.qualcomm.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, olteanv@gmail.com,
devicetree@vger.kernel.org, vkoul@kernel.org,
conor+dt@kernel.org, neil.armstrong@linaro.org,
linux-phy@lists.infradead.org
Subject: Re: [PATCH v3 4/4] phy: qualcomm: qmp-combo: Add support for Hawi SoC
Date: Fri, 08 May 2026 23:26:19 +0000 [thread overview]
Message-ID: <20260508232620.2FD04C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260508213234.4643-5-ronak.raheja@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing DP PHY function pointers in `hawi_usb3dpphy_cfg` lead to NULL pointer dereferences when the DP PHY is initialized.
- [High] Valid register offset `0x00` causes the AON toggle hardware reset override to be silently skipped.
--
commit 39c99ec3129f1da7348c282db12eb565e967941d
Author: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
phy: qualcomm: qmp-combo: Add support for Hawi SoC
This commit adds support for the USB3-DP combo PHY found on the Hawi
platform, introducing new V10 register layouts and the COM AON register
module.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 93f1aa10d4008..53b709ea93d52 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
[ ... ]
> @@ -2705,6 +2895,27 @@ static const struct qmp_phy_cfg x1e80100_usb3dpphy_cfg = {
> .regs = qmp_v6_n4_usb3phy_regs_layout,
> };
>
> +static const struct qmp_phy_cfg hawi_usb3dpphy_cfg = {
> + .offsets = &qmp_combo_offsets_v10,
> +
> + .serdes_tbl = hawi_usb3_serdes_tbl,
> + .serdes_tbl_num = ARRAY_SIZE(hawi_usb3_serdes_tbl),
> + .tx_tbl = hawi_usb3_tx_tbl,
> + .tx_tbl_num = ARRAY_SIZE(hawi_usb3_tx_tbl),
> + .rx_tbl = hawi_usb3_rx_tbl,
> + .rx_tbl_num = ARRAY_SIZE(hawi_usb3_rx_tbl),
> + .pcs_tbl = hawi_usb3_pcs_tbl,
> + .pcs_tbl_num = ARRAY_SIZE(hawi_usb3_pcs_tbl),
> + .pcs_usb_tbl = hawi_usb3_pcs_usb_tbl,
> + .pcs_usb_tbl_num = ARRAY_SIZE(hawi_usb3_pcs_usb_tbl),
> +
> + .regs = qmp_v10_usb3phy_regs_layout,
> + .reset_list = msm8996_usb3phy_reset_l,
> + .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> + .vreg_list = qmp_phy_vreg_l,
> + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> +};
Does this configuration miss the DP PHY function pointers?
Because this is a USB3-DP combo PHY, the driver unconditionally creates the DP
PHY. When a DisplayPort controller tries to initialize it, functions like
qmp_combo_dp_init() and qmp_combo_dp_power_on() will unconditionally call
cfg->dp_aux_init(qmp) and cfg->configure_dp_tx(qmp).
Without these pointers defined in hawi_usb3dpphy_cfg, will this lead to a NULL
pointer dereference and a kernel panic upon DP PHY initialization?
[ ... ]
> @@ -3699,9 +3915,9 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
> SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
>
> /* override hardware control for reset of qmp phy */
> - if (pcs_aon && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> - qphy_clrbits(pcs_aon, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> - qphy_clrbits(pcs_aon, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> + if (aon_toggle && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> + qphy_clrbits(aon_toggle, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> + qphy_clrbits(aon_toggle, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> }
Is it possible for the hardware reset override to be silently skipped here?
The V10 register layout maps QPHY_AON_TOGGLE_ENABLE to
QPHY_V10_COM_AON_USB3_AON_TOGGLE_ENABLE, which is defined as 0x00 in
phy-qcom-qmp-com-aon-v10.h.
Because 0x00 is a valid register offset but evaluates to false in C, the
check for cfg->regs[QPHY_AON_TOGGLE_ENABLE] will fail. This would skip the
qphy_clrbits() calls entirely, bypassing the necessary hardware reset override
sequence and leaving the PHY in a broken state.
Could we use a different way to check if this register is supported by the
layout without relying on the truthiness of the offset value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508213234.4643-1-ronak.raheja@oss.qualcomm.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-05-08 23:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 21:32 [PATCH v3 0/4] phy: qcom: Introduce USB support for Hawi Ronak Raheja
2026-05-08 21:32 ` Ronak Raheja
2026-05-08 21:32 ` [PATCH v3 1/4] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Hawi QMP PHY Ronak Raheja
2026-05-08 21:32 ` Ronak Raheja
2026-05-08 21:32 ` [PATCH v3 2/4] dt-bindings: phy: qcom,m31-eusb2-phy: Document M31 eUSB2 PHY for Hawi Ronak Raheja
2026-05-08 21:32 ` Ronak Raheja
2026-05-08 21:32 ` [PATCH v3 3/4] dt-bindings: usb: qcom,snps-dwc3: Add Hawi compatible Ronak Raheja
2026-05-08 21:32 ` Ronak Raheja
2026-05-08 21:32 ` [PATCH v3 4/4] phy: qualcomm: qmp-combo: Add support for Hawi SoC Ronak Raheja
2026-05-08 21:32 ` Ronak Raheja
2026-05-08 23:26 ` sashiko-bot [this message]
2026-05-08 23:26 ` sashiko-bot
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=20260508232620.2FD04C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=ronak.raheja@oss.qualcomm.com \
--cc=sashiko@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.