usb:typec:tcpm:support double Rp to Vbus cable as sink
Subsystems (3)
PATCH 1/1 usb:typec:tcpm:support double Rp to Vbus cable as sink
The USB Type-C Cable and Connector Specification defines the wire connections for the USB Type-C to USB 2.0 Standard-A cable assembly (Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus non-standard cables which produced by UGREEN circulating on the market, and it can affects the normal operations of the state machine easily, especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.
Message as follow:
[ 58.900212] VBUS on [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] [ 62.625006] VBUS off [ 62.625012] VBUS VSAFE0V
--- drivers/usb/typec/tcpm/tcpm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/typec/tcpm/tcpm.c +2 -1
@@ -519,7 +519,8 @@ static const char * const pd_rev[] = {#define tcpm_port_is_sink (port) \ ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)))#define tcpm_cc_is_source (cc) ((cc) == TYPEC_CC_RD)#define tcpm_cc_is_audio (cc) ((cc) == TYPEC_CC_RA)
Signature · 1 line
2.29.0
Heikki Krogerus
maintainerQuoted 28 lines · Michael Wu
The USB Type-C Cable and Connector Specification defines the wire connections for the USB Type-C to USB 2.0 Standard-A cable assembly (Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus non-standard cables which produced by UGREEN circulating on the market, and it can affects the normal operations of the state machine easily, especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.Message as follow:
[ 58.900212] VBUS on [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] [ 62.625006] VBUS off [ 62.625012] VBUS VSAFE0VSigned-off-by Michael Wu <[email protected]>--- drivers/usb/typec/tcpm/tcpm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/usb/typec/tcpm/tcpm.c +0
-0
drivers/usb/typec/tcpm/tcpm.c static const char * const pd_rev[] = { · line 526
Quoted 9 lines
drivers/usb/typec/tcpm/tcpm.c +2
-1@@ -519,7 +519,8 @@ static const char * const pd_rev[] = {#define tcpm_port_is_sink (port) \ ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)))#define tcpm_cc_is_source (cc) ((cc) == TYPEC_CC_RD)#define tcpm_cc_is_audio (cc) ((cc) == TYPEC_CC_RA)
This look OK to me, but I would still like to wait for comments from Guenter - just in case.
thanks,
Signature · 1 line
heikki
Quoted 36 lines · Heikki Krogerus
Quoted 35 lines · Michael Wu
The USB Type-C Cable and Connector Specification defines the wire connections for the USB Type-C to USB 2.0 Standard-A cable assembly (Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus non-standard cables which produced by UGREEN circulating on the market, and it can affects the normal operations of the state machine easily, especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.Message as follow:
[ 58.900212] VBUS on [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] [ 62.625006] VBUS off [ 62.625012] VBUS VSAFE0VSigned-off-by Michael Wu <[email protected]>--- drivers/usb/typec/tcpm/tcpm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/usb/typec/tcpm/tcpm.c +2
-1@@ -519,7 +519,8 @@ static const char * const pd_rev[] = {#define tcpm_port_is_sink (port) \ ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)))
Quoted 6 lines
drivers/usb/typec/tcpm/tcpm.c static const char * const pd_rev[] = { · line 526
Quoted 2 lines
drivers/usb/typec/tcpm/tcpm.c +0
-0#define tcpm_cc_is_source (cc) ((cc) == TYPEC_CC_RD)#define tcpm_cc_is_audio (cc) ((cc) == TYPEC_CC_RA)This look OK to me, but I would still like to wait for comments from Guenter - just in case.
Look at the conditions. Reordered, we end up with
(tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)) which simplifies to tcpm_cc_is_sink((port)->cc1) making the complete expression tcpm_cc_is_sink((port)->cc1) || (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) which simplifies further to tcpm_cc_is_sink((port)->cc1) || tcpm_cc_is_sink((port)->cc2)
The simplified expression doesn't conflict with other detections, so I am ok with it. It might be worthwhile adding a comment to the code, though, explaining the reason.
Guenter
Quoted 2 lines
thanks,
Quoted 54 lines · Guenter Roeck
Quoted 24 lines · Heikki Krogerus
Quoted 23 lines · Michael Wu
The USB Type-C Cable and Connector Specification defines the wire connections for the USB Type-C to USB 2.0 Standard-A cable assembly (Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus non-standard cables which produced by UGREEN circulating on the market, and it can affects the normal operations of the state machine easily, especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.Message as follow:
[ 58.900212] VBUS on
[ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] [ 62.625006] VBUS off
[ 62.625012] VBUS VSAFE0VSigned-off-by Michael Wu <[email protected]>---
drivers/usb/typec/tcpm/tcpm.c| 3 ++-1 file changed, 2 insertions(+), 1 deletion(-)Quoted 17 lines
drivers/usb/typec/tcpm/tcpm.c static const char * const pd_rev[] = { · line 525
Quoted 13 lines
drivers/usb/typec/tcpm/tcpm.c +2
-1@@ -519,7 +519,8 @@ static const char * const pd_rev[] = { #define tcpm_port_is_sink(port) \ ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))) #define tcpm_cc_is_source(cc) ((cc) == TYPEC_CC_RD) #define tcpm_cc_is_audio(cc) ((cc) == TYPEC_CC_RA)This look OK to me, but I would still like to wait for comments from Guenter - just in case.
Look at the conditions. Reordered, we end up with
(tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))
which simplifies to
tcpm_cc_is_sink((port)->cc1)
making the complete expression
tcpm_cc_is_sink((port)->cc1) || (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))
which simplifies further to
tcpm_cc_is_sink((port)->cc1) || tcpm_cc_is_sink((port)->cc2)
Quoted 7 lines
The simplified expression doesn't conflict with other detections, so I am ok with it. It might be worthwhile adding a comment to the code, though, explaining the reason
GuenterQuoted 2 lines
thanks,
Dear Guenter,
I have modified it according to your opinion, and resend it as patch v2[1]. Please review.
[1] https://lore.kernel.org/all/[email protected]/
Signature · 2 lines
Regards, Michael Wu