[1/2] dt-bindings: usb: dwc3: Add snps,host-vbus-glitches avoiding vbus glitch

  From: Ran Wang <ran.wang_1@nxp.com>

When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
(or its control signal) will turn on immediately on related Root Hub
ports. Then the VBUS will be de-asserted for a little while during xhci
reset (conducted by xhci driver) for a little while and back to normal.

This VBUS glitch might cause some USB devices emuration fail if kernel
boot with them connected. One SW workaround which can fix this is to
program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
host mode in DWC3 driver(per signal measurement result, it will be too
late to do it in xhci-plat.c or xhci.c).

Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
 1 file changed, 7 insertions(+)
  

On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> From: Ran Wang <ran.wang_1@nxp.com>
> 
> When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> (or its control signal) will turn on immediately on related Root Hub
> ports. Then the VBUS will be de-asserted for a little while during xhci
> reset (conducted by xhci driver) for a little while and back to normal.
> 
> This VBUS glitch might cause some USB devices emuration fail if kernel
> boot with them connected. One SW workaround which can fix this is to
> program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> host mode in DWC3 driver(per signal measurement result, it will be too
> late to do it in xhci-plat.c or xhci.c).
> 
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> Reviewed-by: Peter Chen <peter.chen@nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> index 203a1eb66691f..dbf272b76e0b5 100644
> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> @@ -273,6 +273,13 @@ properties:
>        with an external supply.
>      type: boolean
>  
> +  snps,host-vbus-glitches:
> +    description:
> +      When set, power off all Root Hub ports immediately after
> +      setting host mode to avoid vbus (negative) glitch happen in later
> +      xhci reset. And the vbus will back to 5V automatically when reset done.
> +    type: boolean

Why do we want to have a property for this at all? The commit message
seems to describe a problem that's limited to specific configurations
and appears to be somethng the driver should do unconditionally.

Could you explain why this cannot be done unconditionally please?

Thanks,
Conor.

> +
>    snps,is-utmi-l1-suspend:
>      description:
>        True when DWC3 asserts output signal utmi_l1_suspend_n, false when
> -- 
> 2.34.1
>
  

On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > From: Ran Wang <ran.wang_1@nxp.com>
> > 
> > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > (or its control signal) will turn on immediately on related Root Hub
> > ports. Then the VBUS will be de-asserted for a little while during xhci
> > reset (conducted by xhci driver) for a little while and back to normal.
> > 
> > This VBUS glitch might cause some USB devices emuration fail if kernel
> > boot with them connected. One SW workaround which can fix this is to
> > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > host mode in DWC3 driver(per signal measurement result, it will be too
> > late to do it in xhci-plat.c or xhci.c).
> > 
> > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > index 203a1eb66691f..dbf272b76e0b5 100644
> > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > @@ -273,6 +273,13 @@ properties:
> >        with an external supply.
> >      type: boolean
> >  
> > +  snps,host-vbus-glitches:
> > +    description:
> > +      When set, power off all Root Hub ports immediately after
> > +      setting host mode to avoid vbus (negative) glitch happen in later
> > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> > +    type: boolean
> 
> Why do we want to have a property for this at all? The commit message
> seems to describe a problem that's limited to specific configurations
> and appears to be somethng the driver should do unconditionally.
> 
> Could you explain why this cannot be done unconditionally please?

It depends on board design, not all system vbus can be controller by root
hub port. If it is always on, it will not trigger this issue.

Frank

> 
> Thanks,
> Conor.
> 
> > +
> >    snps,is-utmi-l1-suspend:
> >      description:
> >        True when DWC3 asserts output signal utmi_l1_suspend_n, false when
> > -- 
> > 2.34.1
> >
  

On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > From: Ran Wang <ran.wang_1@nxp.com>
> > > 
> > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > (or its control signal) will turn on immediately on related Root Hub
> > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > reset (conducted by xhci driver) for a little while and back to normal.
> > > 
> > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > boot with them connected. One SW workaround which can fix this is to
> > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > late to do it in xhci-plat.c or xhci.c).
> > > 
> > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > ---
> > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > @@ -273,6 +273,13 @@ properties:
> > >        with an external supply.
> > >      type: boolean
> > >  
> > > +  snps,host-vbus-glitches:
> > > +    description:
> > > +      When set, power off all Root Hub ports immediately after
> > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > +      xhci reset. And the vbus will back to 5V automatically when reset done.

nit: "will return to"

> > > +    type: boolean
> > 
> > Why do we want to have a property for this at all? The commit message
> > seems to describe a problem that's limited to specific configurations
> > and appears to be somethng the driver should do unconditionally.
> > 
> > Could you explain why this cannot be done unconditionally please?
> 
> It depends on board design, not all system vbus can be controller by root
> hub port. If it is always on, it will not trigger this issue.

Okay, that seems reasonable to have a property for. Can you add that
info to the commit message please?

On another note, I like it when the property name explains why you would
add it, rather than the thing it is trying to solve.
Named after the disease, rather than the symptoms, if you get me. I
tried to come up with a name here, but could not really suggest
something good. If you can think of something, that'd be good, but don't
stress it.

Thanks,
Conor.
  

On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > 
> > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > (or its control signal) will turn on immediately on related Root Hub
> > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > 
> > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > boot with them connected. One SW workaround which can fix this is to
> > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > late to do it in xhci-plat.c or xhci.c).
> > > > 
> > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > @@ -273,6 +273,13 @@ properties:
> > > >        with an external supply.
> > > >      type: boolean
> > > >  
> > > > +  snps,host-vbus-glitches:
> > > > +    description:
> > > > +      When set, power off all Root Hub ports immediately after
> > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> 
> nit: "will return to"
> 
> > > > +    type: boolean
> > > 
> > > Why do we want to have a property for this at all? The commit message
> > > seems to describe a problem that's limited to specific configurations
> > > and appears to be somethng the driver should do unconditionally.
> > > 
> > > Could you explain why this cannot be done unconditionally please?
> > 
> > It depends on board design, not all system vbus can be controller by root
> > hub port. If it is always on, it will not trigger this issue.
> 
> Okay, that seems reasonable to have a property for. Can you add that
> info to the commit message please?

By the way, I sent v4 at
https://lore.kernel.org/imx/20240124152525.3910311-1-Frank.Li@nxp.com/T/#t

How about add below sentence?

This was only happen when PORTSC[PP} can control vbus. Needn't set it if
vbus is always on.

> 
> On another note, I like it when the property name explains why you would
> add it, rather than the thing it is trying to solve.
> Named after the disease, rather than the symptoms, if you get me. I
> tried to come up with a name here, but could not really suggest
> something good. If you can think of something, that'd be good, but don't
> stress it.

snps,host-vbus-glitches change to snps,host-vbus-glitches-quirk.

How about use below description:

When set, power off all Root Hub ports immediately after
setting host mode to avoid vbus (negative) glitch happen in later
xhci reset. That may cause some USB devices emuration fail when kernel boot
with device connected and PORTSC[PP] control vbus in board desgin.

Frank
> 
> Thanks,
> Conor.
>
  

On Wed, Jan 24, 2024 at 02:17:22PM -0500, Frank Li wrote:
> On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> > On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > > 
> > > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > > (or its control signal) will turn on immediately on related Root Hub
> > > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > > 
> > > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > > boot with them connected. One SW workaround which can fix this is to
> > > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > > late to do it in xhci-plat.c or xhci.c).
> > > > > 
> > > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > ---
> > > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > @@ -273,6 +273,13 @@ properties:
> > > > >        with an external supply.
> > > > >      type: boolean
> > > > >  
> > > > > +  snps,host-vbus-glitches:
> > > > > +    description:
> > > > > +      When set, power off all Root Hub ports immediately after
> > > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> > 
> > nit: "will return to"
> > 
> > > > > +    type: boolean
> > > > 
> > > > Why do we want to have a property for this at all? The commit message
> > > > seems to describe a problem that's limited to specific configurations
> > > > and appears to be somethng the driver should do unconditionally.
> > > > 
> > > > Could you explain why this cannot be done unconditionally please?
> > > 
> > > It depends on board design, not all system vbus can be controller by root
> > > hub port. If it is always on, it will not trigger this issue.
> > 
> > Okay, that seems reasonable to have a property for. Can you add that
> > info to the commit message please?
> 
> By the way, I sent v4 at
> https://lore.kernel.org/imx/20240124152525.3910311-1-Frank.Li@nxp.com/T/#t

I see.

> How about add below sentence?
> 
> This was only happen when PORTSC[PP} can control vbus. Needn't set it if
> vbus is always on.

"This can only happen when ... controls vbus, if vbus is always on, omit
this property".

Just a wee grammatical nitpicking.

> > On another note, I like it when the property name explains why you would
> > add it, rather than the thing it is trying to solve.
> > Named after the disease, rather than the symptoms, if you get me. I
> > tried to come up with a name here, but could not really suggest
> > something good. If you can think of something, that'd be good, but don't
> > stress it.
> 
> snps,host-vbus-glitches change to snps,host-vbus-glitches-quirk.

I don't think adding "quirk" moves the needle.

> How about use below description:
> 
> When set, power off all Root Hub ports immediately after
> setting host mode to avoid vbus (negative) glitch happen in later
> xhci reset. That may cause some USB devices emuration fail when kernel boot
> with device connected and PORTSC[PP] control vbus in board desgin.

"When set, all root hub ports should be powered off immediately after
enabling host mode, to avoid Vbus (negative) glitches that may happen
during xHCI reset. These glitches can cause enumeration of some USB
devices to fail when PORTSC[PP] controls Vbus. If Vbus is always on,
omit this property."

How's that?
  

On Thu, Jan 25, 2024 at 05:43:22PM +0000, Conor Dooley wrote:
> On Wed, Jan 24, 2024 at 02:17:22PM -0500, Frank Li wrote:
> > On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> > > On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > > > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > > > 
> > > > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > > > (or its control signal) will turn on immediately on related Root Hub
> > > > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > > > 
> > > > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > > > boot with them connected. One SW workaround which can fix this is to
> > > > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > > > late to do it in xhci-plat.c or xhci.c).
> > > > > > 
> > > > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > @@ -273,6 +273,13 @@ properties:
> > > > > >        with an external supply.
> > > > > >      type: boolean
> > > > > >  
> > > > > > +  snps,host-vbus-glitches:
> > > > > > +    description:
> > > > > > +      When set, power off all Root Hub ports immediately after
> > > > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> > > 
> > > nit: "will return to"
> > > 
> > > > > > +    type: boolean
> > > > > 
> > > > > Why do we want to have a property for this at all? The commit message
> > > > > seems to describe a problem that's limited to specific configurations
> > > > > and appears to be somethng the driver should do unconditionally.
> > > > > 
> > > > > Could you explain why this cannot be done unconditionally please?
> > > > 
> > > > It depends on board design, not all system vbus can be controller by root
> > > > hub port. If it is always on, it will not trigger this issue.
> > > 
> > > Okay, that seems reasonable to have a property for. Can you add that
> > > info to the commit message please?
> > 
> > By the way, I sent v4 at
> > https://lore.kernel.org/imx/20240124152525.3910311-1-Frank.Li@nxp.com/T/#t
> 
> I see.
> 
> > How about add below sentence?
> > 
> > This was only happen when PORTSC[PP} can control vbus. Needn't set it if
> > vbus is always on.
> 
> "This can only happen when ... controls vbus, if vbus is always on, omit
> this property".
> 
> Just a wee grammatical nitpicking.
> 
> > > On another note, I like it when the property name explains why you would
> > > add it, rather than the thing it is trying to solve.
> > > Named after the disease, rather than the symptoms, if you get me. I
> > > tried to come up with a name here, but could not really suggest
> > > something good. If you can think of something, that'd be good, but don't
> > > stress it.
> > 
> > snps,host-vbus-glitches change to snps,host-vbus-glitches-quirk.
> 
> I don't think adding "quirk" moves the needle.

I think "quirk" is reasonable because it is workaround.

Frank

> 
> > How about use below description:
> > 
> > When set, power off all Root Hub ports immediately after
> > setting host mode to avoid vbus (negative) glitch happen in later
> > xhci reset. That may cause some USB devices emuration fail when kernel boot
> > with device connected and PORTSC[PP] control vbus in board desgin.
> 
> "When set, all root hub ports should be powered off immediately after
> enabling host mode, to avoid Vbus (negative) glitches that may happen
> during xHCI reset. These glitches can cause enumeration of some USB
> devices to fail when PORTSC[PP] controls Vbus. If Vbus is always on,
> omit this property."
> 
> How's that?
  

On Thu, Jan 25, 2024 at 11:06:09PM -0500, Frank Li wrote:

> > > > On another note, I like it when the property name explains why you would
> > > > add it, rather than the thing it is trying to solve.
> > > > Named after the disease, rather than the symptoms, if you get me. I
> > > > tried to come up with a name here, but could not really suggest
> > > > something good. If you can think of something, that'd be good, but don't
> > > > stress it.
> > > 
> > > snps,host-vbus-glitches change to snps,host-vbus-glitches-quirk.
> > 
> > I don't think adding "quirk" moves the needle.
> 
> I think "quirk" is reasonable because it is workaround.

Workaround is what the software will do. In the binding we just describe
what the problem is.
  

On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > 
> > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > (or its control signal) will turn on immediately on related Root Hub
> > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > 
> > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > boot with them connected. One SW workaround which can fix this is to
> > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > late to do it in xhci-plat.c or xhci.c).
> > > > 
> > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > @@ -273,6 +273,13 @@ properties:
> > > >        with an external supply.
> > > >      type: boolean
> > > >  
> > > > +  snps,host-vbus-glitches:
> > > > +    description:
> > > > +      When set, power off all Root Hub ports immediately after
> > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> 
> nit: "will return to"
> 
> > > > +    type: boolean
> > > 
> > > Why do we want to have a property for this at all? The commit message
> > > seems to describe a problem that's limited to specific configurations
> > > and appears to be somethng the driver should do unconditionally.
> > > 
> > > Could you explain why this cannot be done unconditionally please?
> > 
> > It depends on board design, not all system vbus can be controller by root
> > hub port. If it is always on, it will not trigger this issue.
> 
> Okay, that seems reasonable to have a property for. Can you add that
> info to the commit message please?

But if vbus is always on, then applying the work-around would be a NOP, 
right? So you could just apply this unconditionally.

Rob
  

On Tue, Jan 30, 2024 at 12:13:22PM -0600, Rob Herring wrote:
> On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> > On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > > 
> > > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > > (or its control signal) will turn on immediately on related Root Hub
> > > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > > 
> > > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > > boot with them connected. One SW workaround which can fix this is to
> > > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > > late to do it in xhci-plat.c or xhci.c).
> > > > > 
> > > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > ---
> > > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > @@ -273,6 +273,13 @@ properties:
> > > > >        with an external supply.
> > > > >      type: boolean
> > > > >  
> > > > > +  snps,host-vbus-glitches:
> > > > > +    description:
> > > > > +      When set, power off all Root Hub ports immediately after
> > > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> > 
> > nit: "will return to"
> > 
> > > > > +    type: boolean
> > > > 
> > > > Why do we want to have a property for this at all? The commit message
> > > > seems to describe a problem that's limited to specific configurations
> > > > and appears to be somethng the driver should do unconditionally.
> > > > 
> > > > Could you explain why this cannot be done unconditionally please?
> > > 
> > > It depends on board design, not all system vbus can be controller by root
> > > hub port. If it is always on, it will not trigger this issue.
> > 
> > Okay, that seems reasonable to have a property for. Can you add that
> > info to the commit message please?
> 
> But if vbus is always on, then applying the work-around would be a NOP, 
> right? So you could just apply this unconditionally.

Supposed yes. But I have not confidence to apply this unconditionaly.
There are too much difference SOC and dwc3 version. Not sure if it brokes
something. I think it should apply workround as less as possible.

Frank

> 
> Rob
  

On Tue, Jan 30, 2024, Frank Li wrote:
> On Tue, Jan 30, 2024 at 12:13:22PM -0600, Rob Herring wrote:
> > On Wed, Jan 24, 2024 at 05:59:00PM +0000, Conor Dooley wrote:
> > > On Wed, Jan 24, 2024 at 12:47:14PM -0500, Frank Li wrote:
> > > > On Wed, Jan 24, 2024 at 05:36:42PM +0000, Conor Dooley wrote:
> > > > > On Fri, Jan 19, 2024 at 04:31:28PM -0500, Frank Li wrote:
> > > > > > From: Ran Wang <ran.wang_1@nxp.com>
> > > > > > 
> > > > > > When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> > > > > > (or its control signal) will turn on immediately on related Root Hub
> > > > > > ports. Then the VBUS will be de-asserted for a little while during xhci
> > > > > > reset (conducted by xhci driver) for a little while and back to normal.
> > > > > > 
> > > > > > This VBUS glitch might cause some USB devices emuration fail if kernel
> > > > > > boot with them connected. One SW workaround which can fix this is to
> > > > > > program all PORTSC[PP] to 0 to turn off VBUS immediately after setting
> > > > > > host mode in DWC3 driver(per signal measurement result, it will be too
> > > > > > late to do it in xhci-plat.c or xhci.c).
> > > > > > 
> > > > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > > > Reviewed-by: Peter Chen <peter.chen@nxp.com>
> > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > index 203a1eb66691f..dbf272b76e0b5 100644
> > > > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > @@ -273,6 +273,13 @@ properties:
> > > > > >        with an external supply.
> > > > > >      type: boolean
> > > > > >  
> > > > > > +  snps,host-vbus-glitches:
> > > > > > +    description:
> > > > > > +      When set, power off all Root Hub ports immediately after
> > > > > > +      setting host mode to avoid vbus (negative) glitch happen in later
> > > > > > +      xhci reset. And the vbus will back to 5V automatically when reset done.
> > > 
> > > nit: "will return to"
> > > 
> > > > > > +    type: boolean
> > > > > 
> > > > > Why do we want to have a property for this at all? The commit message
> > > > > seems to describe a problem that's limited to specific configurations
> > > > > and appears to be somethng the driver should do unconditionally.
> > > > > 
> > > > > Could you explain why this cannot be done unconditionally please?
> > > > 
> > > > It depends on board design, not all system vbus can be controller by root
> > > > hub port. If it is always on, it will not trigger this issue.
> > > 
> > > Okay, that seems reasonable to have a property for. Can you add that
> > > info to the commit message please?
> > 
> > But if vbus is always on, then applying the work-around would be a NOP, 
> > right? So you could just apply this unconditionally.
> 
> Supposed yes. But I have not confidence to apply this unconditionaly.
> There are too much difference SOC and dwc3 version. Not sure if it brokes
> something. I think it should apply workround as less as possible.
> 

I can't confirm if there will be negative effect to any platform in the
market. But from review, IMHO functionally it should be fine applying
this unconditionally.

BR,
Thinh