From: Krishna Kurapati <quic_kriskura@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Bjorn Andersson <quic_bjorande@quicinc.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Andy Gross <agross@kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-phy@lists.infradead.org>, <quic_ppratap@quicinc.com>,
<quic_jackp@quicinc.com>, <stable@vger.kernel.org>
Subject: Re: [PATCH 5.15.y] phy: qcom: qmp: Fix NULL pointer dereference for USB Uni PHYs
Date: Sun, 17 Nov 2024 17:21:09 +0530 [thread overview]
Message-ID: <51f7cfa8-3362-46e3-a9e5-e43d585d4ac0@quicinc.com> (raw)
In-Reply-To: <ibh3n7gl5qcawpiyjgxy2yum6jsmfv5lpfefuun3m2ktldcswl@odhjnmkj5jre>
On 11/15/2024 9:29 PM, Dmitry Baryshkov wrote:
> On Fri, Nov 15, 2024 at 02:45:45PM +0530, Krishna Kurapati wrote:
>> Commit [1] introduced DP support to QMP driver. While doing so, the
>> dp and usb configuration structures were added to a combo_phy_cfg
>> structure. During probe, the match data is used to parse and identify the
>> dp and usb configs separately. While doing so, the usb_cfg variable
>> represents the configuration parameters for USB part of the phy (whether
>> it is DP-Cobo or Uni). during probe, one corner case of parsing usb_cfg
>> for Uni PHYs is left incomplete and it is left as NULL. This NULL variable
>> further percolates down to qmp_phy_create() call essentially getting
>> de-referenced and causing a crash.
>
> The UNI PHY platforms don't have usb3-phy subnode. As such the usb_cfg
> variable should not be used in the for_each_available_child_of_node()
> loop.
>
> Please provide details for the platform on which you observe the crash
> and the backtrace.
>
I got this error when I started working on multiport support (begining
of 2023). Initially I tried testing on my code on 5.15, hence this patch
was raised on the same.
The 2 qmp phys on sa8195 and sa8295 (based on sc8280xp) are uni phy and
the following was the DT node that worked out for me on 5.15 codebase:
usb_1_qmpphy: ssphy@88eb000 {
compatible = "qcom,sm8150-qmp-usb3-uni-phy";
reg = <0x088eb000 0x200>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
//status = "disabled";
clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
<&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_USB3_SEC_CLKREF_CLK>,
<&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>;
clock-names = "aux", "ref_clk_src", "ref", "com_aux";
resets = <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>,
<&gcc GCC_USB3_UNIPHY_MP0_BCR>;
reset-names = "phy", "common";
//vdda-phy-supply = <&L3C>;
vdda-pll-supply = <&L5E>;
usb_1_ssphy: usb3-phy@88eb200 {
reg = <0x088eb200 0x200>,
<0x088eb400 0x200>,
<0x088eb800 0x800>,
<0x088eb600 0x200>;
#clock-cells = <0>;
#phy-cells = <0>;
clocks = <&gcc GCC_USB3_MP_PHY_PIPE_0_CLK>;
clock-names = "pipe0";
clock-output-names = "usb3_uni_phy_pipe_clk_src";
};
};
I was hitting the bug when I write the DT above way on top of 5.15 baseline.
In 5.15.y, the SM8150 usb_2_qmpphy dT is as follows:
usb_2_qmpphy: phy@88eb000 {
compatible = "qcom,sm8150-qmp-usb3-uni-phy";
reg = <0 0x088eb000 0 0x200>;
status = "disabled";
#address-cells = <2>;
#size-cells = <2>;
ranges;
clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK>,
<&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_USB3_SEC_CLKREF_CLK>,
<&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>;
clock-names = "aux", "ref_clk_src", "ref",
"com_aux";
resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>,
<&gcc GCC_USB3_PHY_SEC_BCR>;
reset-names = "phy", "common";
usb_2_ssphy: phy@88eb200 {
reg = <0 0x088eb200 0 0x200>,
<0 0x088eb400 0 0x200>,
<0 0x088eb800 0 0x800>,
<0 0x088eb600 0 0x200>;
#clock-cells = <0>;
#phy-cells = <0>;
clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>;
clock-names = "pipe0";
clock-output-names =
"usb3_uni_phy_pipe_clk_src";
};
};
IIRC, when I tried using the above sm8150 dt on 5.15.y, the phy_create
was (either not getting called) or crashing. Probably because
"of_node_name_eq()" didn't find either "dp-phy" or "usb3-phy" and cfg
variable was NULL.
I can try reproducing the issue and get back again in a week.
Apologies if I have misunderstood something and this patch doesn't make
sense. Let me know if I have made any mistake anywhere (either in my DT)
or in understanding.
Regards,
Krishna,
next prev parent reply other threads:[~2024-11-17 11:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 9:15 Krishna Kurapati
2024-11-15 15:59 ` Dmitry Baryshkov
2024-11-17 11:51 ` Krishna Kurapati [this message]
2024-11-17 12:57 ` Dmitry Baryshkov
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=51f7cfa8-3362-46e3-a9e5-e43d585d4ac0@quicinc.com \
--to=quic_kriskura@quicinc.com \
--cc=agross@kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=kishon@kernel.org \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=quic_bjorande@quicinc.com \
--cc=quic_jackp@quicinc.com \
--cc=quic_ppratap@quicinc.com \
--cc=stable@vger.kernel.org \
--cc=swboyd@chromium.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®