[PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Prashanth K]

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash. More
info about the crash at [1].

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

[1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/

Prashanth K (3):
  arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
  arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
  arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk

Pratham Pratap (2):
  arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
  arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk

 arch/arm64/boot/dts/qcom/qcs615.dtsi  | 2 ++
 arch/arm64/boot/dts/qcom/qdu1000.dtsi | 1 +
 arch/arm64/boot/dts/qcom/sm8150.dtsi  | 2 ++
 arch/arm64/boot/dts/qcom/sm8350.dtsi  | 2 ++
 arch/arm64/boot/dts/qcom/sm8450.dtsi  | 1 +
 5 files changed, 8 insertions(+)

-- 
2.25.1

[PATCH v1 1/5] arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk

[Prashanth K]

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 4dbda54b47a5..4477ec14ab1d 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3657,6 +3657,7 @@ usb_1_dwc3: usb@a600000 {
 				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
 				iommus = <&apps_smmu 0x140 0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
@@ -3736,6 +3737,7 @@ usb_2_dwc3: usb@a800000 {
 				interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
 				iommus = <&apps_smmu 0x160 0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
-- 
2.25.1

[PATCH v1 2/5] arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk

[Prashanth K]

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 5f93cae01b06..a4fc3657ff87 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2651,6 +2651,7 @@ usb_1_dwc3: usb@a600000 {
 				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
 				iommus = <&apps_smmu 0x0 0x0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
@@ -2729,6 +2730,7 @@ usb_2_dwc3: usb@a800000 {
 				interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
 				iommus = <&apps_smmu 0x20 0x0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
-- 
2.25.1

[PATCH v1 3/5] arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk

[Prashanth K]

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 0b36f4cd4497..58c98bffee17 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -5461,6 +5461,7 @@ usb_1_dwc3: usb@a600000 {
 				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
 				iommus = <&apps_smmu 0x0 0x0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
-- 
2.25.1

[PATCH v1 4/5] arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk

[Prashanth K]

From: Pratham Pratap <quic_ppratap@quicinc.com>

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

Signed-off-by: Pratham Pratap <quic_ppratap@quicinc.com>
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qcs615.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
index edfb796d8dd3..7c377f3402c1 100644
--- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
@@ -3600,6 +3600,7 @@ usb_1_dwc3: usb@a600000 {
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,has-lpm-erratum;
 				snps,hird-threshold = /bits/ 8 <0x10>;
@@ -3661,6 +3662,7 @@ usb_2_dwc3: usb@a800000 {
 				phy-names = "usb2-phy";
 
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,has-lpm-erratum;
 				snps,hird-threshold = /bits/ 8 <0x10>;
-- 
2.25.1

[PATCH v1 5/5] arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk

[Prashanth K]

From: Pratham Pratap <quic_ppratap@quicinc.com>

During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.

This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.

Signed-off-by: Pratham Pratap <quic_ppratap@quicinc.com>
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qdu1000.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/qdu1000.dtsi b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
index f973aa8f7477..b3c673e24726 100644
--- a/arch/arm64/boot/dts/qcom/qdu1000.dtsi
+++ b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
@@ -1022,6 +1022,7 @@ usb_1_dwc3: usb@a600000 {
 
 				iommus = <&apps_smmu 0xc0 0x0>;
 				snps,dis_u2_susphy_quirk;
+				snps,dis_u3_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				snps,dis-u1-entry-quirk;
 				snps,dis-u2-entry-quirk;
-- 
2.25.1

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Konrad Dybcio]

On 3/25/25 1:30 PM, Prashanth K wrote:
> During device mode initialization on certain QC targets, before the
> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
> register write fails. As a result, GEVTADDR registers are still 0x0.
> Upon setting runstop bit, DWC3 controller attempts to write the new
> events to address 0x0, causing an SMMU fault and system crash. More
> info about the crash at [1].
> 
> This was initially observed on SM8450 and later reported on few
> other targets as well. As suggested by Qualcomm HW team, clearing
> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
> write failures. Address this by setting the snps,dis_u3_susphy_quirk
> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
> and hasn't exhibited any side effects.
> 
> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
> 
> Prashanth K (3):
>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
> 
> Pratham Pratap (2):
>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk

Are there more targets affected, from the list of the ones currently
supported upstream?

Konrad

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Prashanth K]

On 25-03-25 08:11 pm, Konrad Dybcio wrote:
> On 3/25/25 1:30 PM, Prashanth K wrote:
>> During device mode initialization on certain QC targets, before the
>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
>> register write fails. As a result, GEVTADDR registers are still 0x0.
>> Upon setting runstop bit, DWC3 controller attempts to write the new
>> events to address 0x0, causing an SMMU fault and system crash. More
>> info about the crash at [1].
>>
>> This was initially observed on SM8450 and later reported on few
>> other targets as well. As suggested by Qualcomm HW team, clearing
>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
>> and hasn't exhibited any side effects.
>>
>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
>>
>> Prashanth K (3):
>>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
>>
>> Pratham Pratap (2):
>>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
> 
> Are there more targets affected, from the list of the ones currently
> supported upstream?
> 
> Konrad

My initial plan was to add it for all the QC platforms, but wasn't
confident enough about it. Because we have seen the issue only on these
targets and hence tested only on these.

Regards,
Prashanth K

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Konrad Dybcio]

On 3/25/25 4:01 PM, Prashanth K wrote:
> 
> 
> On 25-03-25 08:11 pm, Konrad Dybcio wrote:
>> On 3/25/25 1:30 PM, Prashanth K wrote:
>>> During device mode initialization on certain QC targets, before the
>>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
>>> register write fails. As a result, GEVTADDR registers are still 0x0.
>>> Upon setting runstop bit, DWC3 controller attempts to write the new
>>> events to address 0x0, causing an SMMU fault and system crash. More
>>> info about the crash at [1].
>>>
>>> This was initially observed on SM8450 and later reported on few
>>> other targets as well. As suggested by Qualcomm HW team, clearing
>>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
>>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
>>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
>>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
>>> and hasn't exhibited any side effects.
>>>
>>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
>>>
>>> Prashanth K (3):
>>>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>>>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>>>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
>>>
>>> Pratham Pratap (2):
>>>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>>>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
>>
>> Are there more targets affected, from the list of the ones currently
>> supported upstream?
>>
>> Konrad
> 
> My initial plan was to add it for all the QC platforms, but wasn't
> confident enough about it. Because we have seen the issue only on these
> targets and hence tested only on these.

Okay, let's proceed with these and in the meantime please query internally
whether it could be applicable to others too

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Bjorn Andersson]

On Tue, Mar 25, 2025 at 05:31:28PM +0100, Konrad Dybcio wrote:
> On 3/25/25 4:01 PM, Prashanth K wrote:
> > 
> > 
> > On 25-03-25 08:11 pm, Konrad Dybcio wrote:
> >> On 3/25/25 1:30 PM, Prashanth K wrote:
> >>> During device mode initialization on certain QC targets, before the
> >>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
> >>> register write fails. As a result, GEVTADDR registers are still 0x0.
> >>> Upon setting runstop bit, DWC3 controller attempts to write the new
> >>> events to address 0x0, causing an SMMU fault and system crash. More
> >>> info about the crash at [1].
> >>>
> >>> This was initially observed on SM8450 and later reported on few
> >>> other targets as well. As suggested by Qualcomm HW team, clearing
> >>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
> >>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
> >>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
> >>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
> >>> and hasn't exhibited any side effects.
> >>>
> >>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
> >>>
> >>> Prashanth K (3):
> >>>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
> >>>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
> >>>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
> >>>
> >>> Pratham Pratap (2):
> >>>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
> >>>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
> >>
> >> Are there more targets affected, from the list of the ones currently
> >> supported upstream?
> >>
> >> Konrad
> > 
> > My initial plan was to add it for all the QC platforms, but wasn't
> > confident enough about it. Because we have seen the issue only on these
> > targets and hence tested only on these.
> 
> Okay, let's proceed with these and in the meantime please query internally
> whether it could be applicable to others too
> 

But if it applies to all qcom targets, wouldn't it make more sense to
add the property in the qcom glue driver?

Regards,
Bjorn

> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> Konrad

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Prashanth K]

On 26-03-25 03:40 am, Bjorn Andersson wrote:
> On Tue, Mar 25, 2025 at 05:31:28PM +0100, Konrad Dybcio wrote:
>> On 3/25/25 4:01 PM, Prashanth K wrote:
>>>
>>>
>>> On 25-03-25 08:11 pm, Konrad Dybcio wrote:
>>>> On 3/25/25 1:30 PM, Prashanth K wrote:
>>>>> During device mode initialization on certain QC targets, before the
>>>>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
>>>>> register write fails. As a result, GEVTADDR registers are still 0x0.
>>>>> Upon setting runstop bit, DWC3 controller attempts to write the new
>>>>> events to address 0x0, causing an SMMU fault and system crash. More
>>>>> info about the crash at [1].
>>>>>
>>>>> This was initially observed on SM8450 and later reported on few
>>>>> other targets as well. As suggested by Qualcomm HW team, clearing
>>>>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
>>>>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
>>>>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
>>>>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
>>>>> and hasn't exhibited any side effects.
>>>>>
>>>>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
>>>>>
>>>>> Prashanth K (3):
>>>>>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
>>>>>
>>>>> Pratham Pratap (2):
>>>>>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
>>>>
>>>> Are there more targets affected, from the list of the ones currently
>>>> supported upstream?
>>>>
>>>> Konrad
>>>
>>> My initial plan was to add it for all the QC platforms, but wasn't
>>> confident enough about it. Because we have seen the issue only on these
>>> targets and hence tested only on these.
>>
>> Okay, let's proceed with these and in the meantime please query internally
>> whether it could be applicable to others too
>>
> 
> But if it applies to all qcom targets, wouldn't it make more sense to
> add the property in the qcom glue driver?

Hi Bjorn, This issue was seen only on some targets 2 years back, so we
only tested on those platforms. I think its better to add it to other QC
targets only if we see that issue.

> 
> Regards,
> Bjorn
> 
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Konrad

Thanks for the review Konrad

Regards,
Prashanth K

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Konrad Dybcio]

On 3/25/25 11:10 PM, Bjorn Andersson wrote:
> On Tue, Mar 25, 2025 at 05:31:28PM +0100, Konrad Dybcio wrote:
>> On 3/25/25 4:01 PM, Prashanth K wrote:
>>>
>>>
>>> On 25-03-25 08:11 pm, Konrad Dybcio wrote:
>>>> On 3/25/25 1:30 PM, Prashanth K wrote:
>>>>> During device mode initialization on certain QC targets, before the
>>>>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
>>>>> register write fails. As a result, GEVTADDR registers are still 0x0.
>>>>> Upon setting runstop bit, DWC3 controller attempts to write the new
>>>>> events to address 0x0, causing an SMMU fault and system crash. More
>>>>> info about the crash at [1].
>>>>>
>>>>> This was initially observed on SM8450 and later reported on few
>>>>> other targets as well. As suggested by Qualcomm HW team, clearing
>>>>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
>>>>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
>>>>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
>>>>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
>>>>> and hasn't exhibited any side effects.
>>>>>
>>>>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
>>>>>
>>>>> Prashanth K (3):
>>>>>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
>>>>>
>>>>> Pratham Pratap (2):
>>>>>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>>>>>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
>>>>
>>>> Are there more targets affected, from the list of the ones currently
>>>> supported upstream?
>>>>
>>>> Konrad
>>>
>>> My initial plan was to add it for all the QC platforms, but wasn't
>>> confident enough about it. Because we have seen the issue only on these
>>> targets and hence tested only on these.
>>
>> Okay, let's proceed with these and in the meantime please query internally
>> whether it could be applicable to others too
>>
> 
> But if it applies to all qcom targets, wouldn't it make more sense to
> add the property in the qcom glue driver?

If we did that and the issue was ever fixed in future hw, we'd have to
either re-add this patchset again or invent a snps,*en*_u3_susphy_quirk

Konrad

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Dmitry Baryshkov]

On Tue, Mar 25, 2025 at 08:31:55PM +0530, Prashanth K wrote:
> 
> 
> On 25-03-25 08:11 pm, Konrad Dybcio wrote:
> > On 3/25/25 1:30 PM, Prashanth K wrote:
> >> During device mode initialization on certain QC targets, before the
> >> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
> >> register write fails. As a result, GEVTADDR registers are still 0x0.
> >> Upon setting runstop bit, DWC3 controller attempts to write the new
> >> events to address 0x0, causing an SMMU fault and system crash. More
> >> info about the crash at [1].
> >>
> >> This was initially observed on SM8450 and later reported on few
> >> other targets as well. As suggested by Qualcomm HW team, clearing
> >> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
> >> write failures. Address this by setting the snps,dis_u3_susphy_quirk
> >> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
> >> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
> >> and hasn't exhibited any side effects.
> >>
> >> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
> >>
> >> Prashanth K (3):
> >>   arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
> >>   arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
> >>   arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk

It is hard to belive that this quirk is to be set for SM8150, SM8350,
SM8450, but not SM8250.

> >>
> >> Pratham Pratap (2):
> >>   arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
> >>   arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
> > 
> > Are there more targets affected, from the list of the ones currently
> > supported upstream?
> > 
> > Konrad
> 
> My initial plan was to add it for all the QC platforms, but wasn't
> confident enough about it. Because we have seen the issue only on these
> targets and hence tested only on these.
> 
> Regards,
> Prashanth K

-- 
With best wishes
Dmitry

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Krishna Kurapati]

On 3/26/2025 5:51 AM, Dmitry Baryshkov wrote:
> On Tue, Mar 25, 2025 at 08:31:55PM +0530, Prashanth K wrote:
>>
>>
>> On 25-03-25 08:11 pm, Konrad Dybcio wrote:
>>> On 3/25/25 1:30 PM, Prashanth K wrote:
>>>> During device mode initialization on certain QC targets, before the
>>>> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
>>>> register write fails. As a result, GEVTADDR registers are still 0x0.
>>>> Upon setting runstop bit, DWC3 controller attempts to write the new
>>>> events to address 0x0, causing an SMMU fault and system crash. More
>>>> info about the crash at [1].
>>>>
>>>> This was initially observed on SM8450 and later reported on few
>>>> other targets as well. As suggested by Qualcomm HW team, clearing
>>>> the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
>>>> write failures. Address this by setting the snps,dis_u3_susphy_quirk
>>>> to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
>>>> on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
>>>> and hasn't exhibited any side effects.
>>>>
>>>> [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
>>>>
>>>> Prashanth K (3):
>>>>    arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
>>>>    arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
>>>>    arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
> 
> It is hard to belive that this quirk is to be set for SM8150, SM8350,
> SM8450, but not SM8250.
> 

At the moment we wanted to add this quirk for targets where issue has 
shown up either internal to QC or at customer's end. But the issue 
didn't come up on SM8250/ SM8550/ SM8650 so far either from customer end 
or ours. Would like to update for other targets on need basis.

Regards,
Krishna,

>>>>
>>>> Pratham Pratap (2):
>>>>    arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
>>>>    arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
>>>
>>> Are there more targets affected, from the list of the ones currently
>>> supported upstream?
>>>
>>> Konrad
>>
>> My initial plan was to add it for all the QC platforms, but wasn't
>> confident enough about it. Because we have seen the issue only on these
>> targets and hence tested only on these.
>>
>> Regards,
>> Prashanth K
> 

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Dmitry Baryshkov]

On Wed, Mar 26, 2025 at 10:52:46AM +0530, Krishna Kurapati wrote:
> 
> 
> On 3/26/2025 5:51 AM, Dmitry Baryshkov wrote:
> > On Tue, Mar 25, 2025 at 08:31:55PM +0530, Prashanth K wrote:
> > > 
> > > 
> > > On 25-03-25 08:11 pm, Konrad Dybcio wrote:
> > > > On 3/25/25 1:30 PM, Prashanth K wrote:
> > > > > During device mode initialization on certain QC targets, before the
> > > > > runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
> > > > > register write fails. As a result, GEVTADDR registers are still 0x0.
> > > > > Upon setting runstop bit, DWC3 controller attempts to write the new
> > > > > events to address 0x0, causing an SMMU fault and system crash. More
> > > > > info about the crash at [1].
> > > > > 
> > > > > This was initially observed on SM8450 and later reported on few
> > > > > other targets as well. As suggested by Qualcomm HW team, clearing
> > > > > the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
> > > > > write failures. Address this by setting the snps,dis_u3_susphy_quirk
> > > > > to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
> > > > > on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
> > > > > and hasn't exhibited any side effects.
> > > > > 
> > > > > [1]: https://lore.kernel.org/all/fa94cbc9-e637-ba9b-8ec8-67c6955eca98@quicinc.com/
> > > > > 
> > > > > Prashanth K (3):
> > > > >    arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
> > > > >    arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
> > > > >    arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
> > 
> > It is hard to belive that this quirk is to be set for SM8150, SM8350,
> > SM8450, but not SM8250.
> > 
> 
> At the moment we wanted to add this quirk for targets where issue has shown
> up either internal to QC or at customer's end. But the issue didn't come up
> on SM8250/ SM8550/ SM8650 so far either from customer end or ours. Would
> like to update for other targets on need basis.

I'm not questioning SM8[56]50, but not seeing SM8250 here is really
doubtful.

-- 
With best wishes
Dmitry

Re: [PATCH v1 0/5] Add snps,dis_u3_susphy_quirk for some QC targets

[Bjorn Andersson]

On Tue, 25 Mar 2025 18:00:14 +0530, Prashanth K wrote:
> During device mode initialization on certain QC targets, before the
> runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
> register write fails. As a result, GEVTADDR registers are still 0x0.
> Upon setting runstop bit, DWC3 controller attempts to write the new
> events to address 0x0, causing an SMMU fault and system crash. More
> info about the crash at [1].
> 
> [...]

Applied, thanks!

[1/5] arm64: dts: qcom: sm8150: Add snps,dis_u3_susphy_quirk
      commit: 9bdbd5286ea597db6131c197ae9ee8614cce1890
[2/5] arm64: dts: qcom: sm8350: Add snps,dis_u3_susphy_quirk
      commit: a7dac91e56ae58e1479002e5b94fab73039f2e29
[3/5] arm64: dts: qcom: sm8450: Add snps,dis_u3_susphy_quirk
      commit: 9588f10adb5b67bea7eeebed2490c20dfbe82e77
[4/5] arm64: dts: qcom: qcs615: Add snps,dis_u3_susphy_quirk
      commit: ad2011e02dab5ccc9f38848a3d909855a4ae7c8f
[5/5] arm64: dts: qcom: qdu1000: Add snps,dis_u3_susphy_quirk
      commit: 25eee6c64376fcdc375b97c7e1f105e132654563

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>