diff mbox series

[RFC,v2,1/3] dt-bindings: phy: qcom,qmp-usb3-dp: Add sm6350 compatible

Message ID 20221125092749.46073-1-luca.weiss@fairphone.com
State New
Headers
Series [RFC,v2,1/3] dt-bindings: phy: qcom,qmp-usb3-dp: Add sm6350 compatible |

Commit Message

Luca Weiss Nov. 25, 2022, 9:27 a.m. UTC 
  Add the compatible describing the combo phy found on SM6350.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
@Johan Hovold, I've sent this v2 as RFC because there are several things
where I have questions on how it should be done.

In this patch, you can see there's cfg_ahb (&xo_board) and power-domains
is not set. In msm-4.19 &gcc_usb30_prim_gdsc is only used in the
ssusb@a600000 node, or should I also add it to qmpphy?

 .../bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml          | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Johan Hovold Nov. 25, 2022, 9:50 a.m. UTC | #1 
On Fri, Nov 25, 2022 at 10:27:47AM +0100, Luca Weiss wrote:
> Add the compatible describing the combo phy found on SM6350.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> @Johan Hovold, I've sent this v2 as RFC because there are several things
> where I have questions on how it should be done.
> 
> In this patch, you can see there's cfg_ahb (&xo_board) and power-domains
> is not set. In msm-4.19 &gcc_usb30_prim_gdsc is only used in the
> ssusb@a600000 node, or should I also add it to qmpphy?

Yeah, you may need to add a platform specific section of the clocks,
which appear to be different, even if I'm not sure they are currently
described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are
they named in the vendor's dts?

It should be OK to include the power-domain also for the PHY node.

>  .../bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml          | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> index 6f31693d9868..3e39e3e0504d 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> @@ -17,16 +17,18 @@ properties:
>    compatible:
>      enum:
>        - qcom,sc8280xp-qmp-usb43dp-phy
> +      - qcom,sm6350-qmp-usb3-dp-phy
>  
>    reg:
>      maxItems: 1
>  
>    clocks:
> -    maxItems: 4
> +    maxItems: 5
>  
>    clock-names:
>      items:
>        - const: aux
> +      - const: cfg_ahb
>        - const: ref
>        - const: com_aux
>        - const: usb3_pipe

So this would need to be moved to an allOf: construct at the end with
one section each for sc8280xp and sm6350.

> @@ -61,7 +63,6 @@ required:
>    - reg
>    - clocks
>    - clock-names
> -  - power-domains
>    - resets
>    - reset-names
>    - vdda-phy-supply

Johan
Luca Weiss Nov. 25, 2022, 9:55 a.m. UTC | #2 
Hi Johan,

On Fri Nov 25, 2022 at 10:50 AM CET, Johan Hovold wrote:
> On Fri, Nov 25, 2022 at 10:27:47AM +0100, Luca Weiss wrote:
> > Add the compatible describing the combo phy found on SM6350.
> > 
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
> > @Johan Hovold, I've sent this v2 as RFC because there are several things
> > where I have questions on how it should be done.
> > 
> > In this patch, you can see there's cfg_ahb (&xo_board) and power-domains
> > is not set. In msm-4.19 &gcc_usb30_prim_gdsc is only used in the
> > ssusb@a600000 node, or should I also add it to qmpphy?
>
> Yeah, you may need to add a platform specific section of the clocks,
> which appear to be different, even if I'm not sure they are currently
> described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are
> they named in the vendor's dts?

This is the msm-4.19 dts:
https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-usb.dtsi#354

>
> It should be OK to include the power-domain also for the PHY node.

Ack.

>
> >  .../bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml          | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > index 6f31693d9868..3e39e3e0504d 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > @@ -17,16 +17,18 @@ properties:
> >    compatible:
> >      enum:
> >        - qcom,sc8280xp-qmp-usb43dp-phy
> > +      - qcom,sm6350-qmp-usb3-dp-phy
> >  
> >    reg:
> >      maxItems: 1
> >  
> >    clocks:
> > -    maxItems: 4
> > +    maxItems: 5
> >  
> >    clock-names:
> >      items:
> >        - const: aux
> > +      - const: cfg_ahb
> >        - const: ref
> >        - const: com_aux
> >        - const: usb3_pipe
>
> So this would need to be moved to an allOf: construct at the end with
> one section each for sc8280xp and sm6350.

Ack.

Thanks for the quick response!

Regards,
Luca

>
> > @@ -61,7 +63,6 @@ required:
> >    - reg
> >    - clocks
> >    - clock-names
> > -  - power-domains
> >    - resets
> >    - reset-names
> >    - vdda-phy-supply
>
> Johan
Johan Hovold Nov. 25, 2022, 10:19 a.m. UTC | #3 
On Fri, Nov 25, 2022 at 10:55:31AM +0100, Luca Weiss wrote:
> Hi Johan,
> 
> On Fri Nov 25, 2022 at 10:50 AM CET, Johan Hovold wrote:
> > On Fri, Nov 25, 2022 at 10:27:47AM +0100, Luca Weiss wrote:
> > > Add the compatible describing the combo phy found on SM6350.
> > > 
> > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > > ---
> > > @Johan Hovold, I've sent this v2 as RFC because there are several things
> > > where I have questions on how it should be done.
> > > 
> > > In this patch, you can see there's cfg_ahb (&xo_board) and power-domains
> > > is not set. In msm-4.19 &gcc_usb30_prim_gdsc is only used in the
> > > ssusb@a600000 node, or should I also add it to qmpphy?
> >
> > Yeah, you may need to add a platform specific section of the clocks,
> > which appear to be different, even if I'm not sure they are currently
> > described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are
> > they named in the vendor's dts?
> 
> This is the msm-4.19 dts:
> https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-usb.dtsi#354

		clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
			<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>,
			<&rpmhcc RPMH_QLINK_CLK>,
			<&gcc GCC_USB3_PRIM_CLKREF_CLK>,
			<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
		clock-names = "aux_clk", "pipe_clk", "ref_clk_src",
				"ref_clk", "com_aux_clk";

So it looks like you don't need update the binding for the clocks as the
above matches sc8280xp:

	aux
	ref
	com_aux
	usb3_pipe

Parent clocks (ref_clk_src) should not be included in the binding, but
rather be handled by the clock driver. For example, see:

	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/

> > >  .../bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml          | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > index 6f31693d9868..3e39e3e0504d 100644
> > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > @@ -17,16 +17,18 @@ properties:
> > >    compatible:
> > >      enum:
> > >        - qcom,sc8280xp-qmp-usb43dp-phy
> > > +      - qcom,sm6350-qmp-usb3-dp-phy
> > >  
> > >    reg:
> > >      maxItems: 1
> > >  
> > >    clocks:
> > > -    maxItems: 4
> > > +    maxItems: 5
> > >  
> > >    clock-names:
> > >      items:
> > >        - const: aux
> > > +      - const: cfg_ahb
> > >        - const: ref
> > >        - const: com_aux
> > >        - const: usb3_pipe
> >
> > So this would need to be moved to an allOf: construct at the end with
> > one section each for sc8280xp and sm6350.
> 
> Ack.

So no need to change this it seems.

Johan
Luca Weiss Nov. 25, 2022, 12:53 p.m. UTC | #4 
On Fri Nov 25, 2022 at 11:19 AM CET, Johan Hovold wrote:
> On Fri, Nov 25, 2022 at 10:55:31AM +0100, Luca Weiss wrote:
> > Hi Johan,
> > 
> > On Fri Nov 25, 2022 at 10:50 AM CET, Johan Hovold wrote:
> > > On Fri, Nov 25, 2022 at 10:27:47AM +0100, Luca Weiss wrote:
> > > > Add the compatible describing the combo phy found on SM6350.
> > > > 
> > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > > > ---
> > > > @Johan Hovold, I've sent this v2 as RFC because there are several things
> > > > where I have questions on how it should be done.
> > > > 
> > > > In this patch, you can see there's cfg_ahb (&xo_board) and power-domains
> > > > is not set. In msm-4.19 &gcc_usb30_prim_gdsc is only used in the
> > > > ssusb@a600000 node, or should I also add it to qmpphy?
> > >
> > > Yeah, you may need to add a platform specific section of the clocks,
> > > which appear to be different, even if I'm not sure they are currently
> > > described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are
> > > they named in the vendor's dts?
> > 
> > This is the msm-4.19 dts:
> > https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-usb.dtsi#354
>
> 		clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> 			<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>,
> 			<&rpmhcc RPMH_QLINK_CLK>,
> 			<&gcc GCC_USB3_PRIM_CLKREF_CLK>,
> 			<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
> 		clock-names = "aux_clk", "pipe_clk", "ref_clk_src",
> 				"ref_clk", "com_aux_clk";
>
> So it looks like you don't need update the binding for the clocks as the
> above matches sc8280xp:
>
> 	aux
> 	ref
> 	com_aux
> 	usb3_pipe

Thanks for checking!

>
> Parent clocks (ref_clk_src) should not be included in the binding, but
> rather be handled by the clock driver. For example, see:
>
> 	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
> 	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/

So I assume you mean that I shouldn't do this:

clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
     <&rpmhcc RPMH_QLINK_CLK>,
     <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
     <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
clock-names = "aux", "ref", "com_aux", "usb3_pipe";

But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work
fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in
debugfs).


And for the driver patch, I've discovered that this phy doesn't have
separate txa/tbx region, so dts was also wrong there. Do you know if
there's a way to test DP phy initialization without having all the USB-C
plumbing in place? Might be good to validate at least phy init works if
we're already touching all of this.

Regards
Luca

>
> > > >  .../bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml          | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > index 6f31693d9868..3e39e3e0504d 100644
> > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > @@ -17,16 +17,18 @@ properties:
> > > >    compatible:
> > > >      enum:
> > > >        - qcom,sc8280xp-qmp-usb43dp-phy
> > > > +      - qcom,sm6350-qmp-usb3-dp-phy
> > > >  
> > > >    reg:
> > > >      maxItems: 1
> > > >  
> > > >    clocks:
> > > > -    maxItems: 4
> > > > +    maxItems: 5
> > > >  
> > > >    clock-names:
> > > >      items:
> > > >        - const: aux
> > > > +      - const: cfg_ahb
> > > >        - const: ref
> > > >        - const: com_aux
> > > >        - const: usb3_pipe
> > >
> > > So this would need to be moved to an allOf: construct at the end with
> > > one section each for sc8280xp and sm6350.
> > 
> > Ack.
>
> So no need to change this it seems.
>
> Johan
Johan Hovold Nov. 25, 2022, 1:52 p.m. UTC | #5 
On Fri, Nov 25, 2022 at 01:53:25PM +0100, Luca Weiss wrote:
> On Fri Nov 25, 2022 at 11:19 AM CET, Johan Hovold wrote:
> > On Fri, Nov 25, 2022 at 10:55:31AM +0100, Luca Weiss wrote:
> > > On Fri Nov 25, 2022 at 10:50 AM CET, Johan Hovold wrote:

> > > > Yeah, you may need to add a platform specific section of the clocks,
> > > > which appear to be different, even if I'm not sure they are currently
> > > > described correctly (xo_board as cfg_ahb and "QLINK" as ref). How are
> > > > they named in the vendor's dts?
> > > 
> > > This is the msm-4.19 dts:
> > > https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-usb.dtsi#354
> >
> > 		clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> > 			<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>,
> > 			<&rpmhcc RPMH_QLINK_CLK>,
> > 			<&gcc GCC_USB3_PRIM_CLKREF_CLK>,
> > 			<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
> > 		clock-names = "aux_clk", "pipe_clk", "ref_clk_src",
> > 				"ref_clk", "com_aux_clk";
> >
> > So it looks like you don't need update the binding for the clocks as the
> > above matches sc8280xp:
> >
> > 	aux
> > 	ref
> > 	com_aux
> > 	usb3_pipe
> 
> Thanks for checking!
> 
> >
> > Parent clocks (ref_clk_src) should not be included in the binding, but
> > rather be handled by the clock driver. For example, see:
> >
> > 	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
> > 	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/
> 
> So I assume you mean that I shouldn't do this:
> 
> clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
>      <&rpmhcc RPMH_QLINK_CLK>,
>      <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
>      <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> clock-names = "aux", "ref", "com_aux", "usb3_pipe";
> 
> But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work
> fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in
> debugfs).

Exactly. Since the vendor dts describes RPMH_QLINK_CLK as parent of ref,
I'd suggest modelling that in the clock driver. Perhaps it has just been
left on by the boot firmware. Someone with access to docs may be able
explain how it is supposed to be used.

> And for the driver patch, I've discovered that this phy doesn't have
> separate txa/tbx region, so dts was also wrong there. Do you know if
> there's a way to test DP phy initialization without having all the USB-C
> plumbing in place? Might be good to validate at least phy init works if
> we're already touching all of this.

Do you mean that it appears to work as sc8280xp with txa/txb shared by
both the USB and DP parts?

I guess you need a proper setup to test it properly. Not sure what
you'll be able to learn otherwise, apart from whether it passes basic
smoke testing.

Johan
Luca Weiss Nov. 25, 2022, 2:12 p.m. UTC | #6 
On Fri Nov 25, 2022 at 2:52 PM CET, Johan Hovold wrote:
> On Fri, Nov 25, 2022 at 01:53:25PM +0100, Luca Weiss wrote:
> > > Parent clocks (ref_clk_src) should not be included in the binding, but
> > > rather be handled by the clock driver. For example, see:
> > >
> > > 	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
> > > 	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/
> > 
> > So I assume you mean that I shouldn't do this:
> > 
> > clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> >      <&rpmhcc RPMH_QLINK_CLK>,
> >      <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
> >      <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> > clock-names = "aux", "ref", "com_aux", "usb3_pipe";
> > 
> > But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work
> > fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in
> > debugfs).
>
> Exactly. Since the vendor dts describes RPMH_QLINK_CLK as parent of ref,
> I'd suggest modelling that in the clock driver. Perhaps it has just been
> left on by the boot firmware. Someone with access to docs may be able
> explain how it is supposed to be used.

RPMH_QLINK_CLK is also in msm-4.19 ref_clk_src for
GCC_UFS_MEM_CLKREF_CLK (ufsphy_mem) and also ref_clk (ufshc_mem).

Honestly since it works fine without adding this to gcc driver and I
don't really know much about clk (and have no docs for this) would it be
okay to just ignore RPMH_QLINK_CLK?

>
> > And for the driver patch, I've discovered that this phy doesn't have
> > separate txa/tbx region, so dts was also wrong there. Do you know if
> > there's a way to test DP phy initialization without having all the USB-C
> > plumbing in place? Might be good to validate at least phy init works if
> > we're already touching all of this.
>
> Do you mean that it appears to work as sc8280xp with txa/txb shared by
> both the USB and DP parts?

Yes, looks like it. Can't find any evidence pointing in any other
direction at least, everything I've seen shows .txa = 0x1200 & .txb =
0x1600.

>
> I guess you need a proper setup to test it properly. Not sure what
> you'll be able to learn otherwise, apart from whether it passes basic
> smoke testing.

Currently it's not even smoke testing because dp phy is never getting
enabled because there's no consumer. That's why I guess it was never
noticed it's wrongly described in dts.

Regards
Luca

>
> Johan
Johan Hovold Nov. 29, 2022, 3:29 p.m. UTC | #7 
On Fri, Nov 25, 2022 at 03:12:24PM +0100, Luca Weiss wrote:
> On Fri Nov 25, 2022 at 2:52 PM CET, Johan Hovold wrote:
> > On Fri, Nov 25, 2022 at 01:53:25PM +0100, Luca Weiss wrote:
> > > > Parent clocks (ref_clk_src) should not be included in the binding, but
> > > > rather be handled by the clock driver. For example, see:
> > > >
> > > > 	https://lore.kernel.org/all/20221121085058.31213-4-johan+linaro@kernel.org/
> > > > 	https://lore.kernel.org/all/20221115152956.21677-1-quic_shazhuss@quicinc.com/
> > > 
> > > So I assume you mean that I shouldn't do this:
> > > 
> > > clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> > >      <&rpmhcc RPMH_QLINK_CLK>,
> > >      <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
> > >      <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> > > clock-names = "aux", "ref", "com_aux", "usb3_pipe";
> > > 
> > > But for "ref" use GCC_USB3_PRIM_CLKREF_CLK? That also seems to work
> > > fine, also if RPMH_QLINK_CLK is not used from Linux-side (checked in
> > > debugfs).
> >
> > Exactly. Since the vendor dts describes RPMH_QLINK_CLK as parent of ref,
> > I'd suggest modelling that in the clock driver. Perhaps it has just been
> > left on by the boot firmware. Someone with access to docs may be able
> > explain how it is supposed to be used.
> 
> RPMH_QLINK_CLK is also in msm-4.19 ref_clk_src for
> GCC_UFS_MEM_CLKREF_CLK (ufsphy_mem) and also ref_clk (ufshc_mem).
> 
> Honestly since it works fine without adding this to gcc driver and I
> don't really know much about clk (and have no docs for this) would it be
> okay to just ignore RPMH_QLINK_CLK?

Preferably it should be fixed now as it may be harder to figure out
what's missing in case this causes trouble in some setup later.

But, yeah, the lack of documentation is a pain.

Hopefully Bjorn or Vinod can help out with getting this sorted properly.

> > > And for the driver patch, I've discovered that this phy doesn't have
> > > separate txa/tbx region, so dts was also wrong there. Do you know if
> > > there's a way to test DP phy initialization without having all the USB-C
> > > plumbing in place? Might be good to validate at least phy init works if
> > > we're already touching all of this.
> >
> > Do you mean that it appears to work as sc8280xp with txa/txb shared by
> > both the USB and DP parts?
> 
> Yes, looks like it. Can't find any evidence pointing in any other
> direction at least, everything I've seen shows .txa = 0x1200 & .txb =
> 0x1600.

Ok. I've also only seen indirect references to the DP registers
for the older platforms, but at least of them do have the separate DP TX
regions.

> > I guess you need a proper setup to test it properly. Not sure what
> > you'll be able to learn otherwise, apart from whether it passes basic
> > smoke testing.
> 
> Currently it's not even smoke testing because dp phy is never getting
> enabled because there's no consumer. That's why I guess it was never
> noticed it's wrongly described in dts.

Yeah, people shouldn't be adding (copy-pasted) nodes for peripherals
that they are not able to test (especially given the lack of
documentation), but I guess the USB3-DP case is a bit of a grey area as
the USB part can have been verified. Fortunately, this should be less of
any issue with the new binding scheme.

Johan
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 6f31693d9868..3e39e3e0504d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -17,16 +17,18 @@  properties:
   compatible:
     enum:
       - qcom,sc8280xp-qmp-usb43dp-phy
+      - qcom,sm6350-qmp-usb3-dp-phy
 
   reg:
     maxItems: 1
 
   clocks:
-    maxItems: 4
+    maxItems: 5
 
   clock-names:
     items:
       - const: aux
+      - const: cfg_ahb
       - const: ref
       - const: com_aux
       - const: usb3_pipe
@@ -61,7 +63,6 @@  required:
   - reg
   - clocks
   - clock-names
-  - power-domains
   - resets
   - reset-names
   - vdda-phy-supply