Hi Ondřej, > > Hi Xu, > > On Mon, Feb 19, 2024 at 08:36:50AM +0000, Xu Yang wrote: > > Hi Ondřej, > > > > > > > > Hi, > > > > > > On Sun, Aug 20, 2023 at 11:15:18PM +0800, Xu Yang wrote: > > > > The try_src_count and try_snk_count may still be 1 after enter into > > > > unattached state. This may be caused by below case: > > > > - SNK_TRY->SNK_TRY_WAIT->SRC_TRYWAIT->SNK_UNATTACHED > > > > - SRC_TRY->SRC_TRY_WAIT->SNK_TRYWAIT->SNK_UNATTACHED > > > > > > > > The port->attached is not true at the end and tcpm_reset_port() will not > > > > be called. This will reset counter into for these cases, otherwise the tcpm > > > > won't try role when new cable attached. > > > > > > > > Signed-off-by: Xu Yang <xu.yang_2@xxxxxxx> > > > > --- > > > > drivers/usb/typec/tcpm/tcpm.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > > > > index 5639b9a1e0bf..c9a186a8c58c 100644 > > > > --- a/drivers/usb/typec/tcpm/tcpm.c > > > > +++ b/drivers/usb/typec/tcpm/tcpm.c > > > > @@ -3719,6 +3719,9 @@ static void tcpm_detach(struct tcpm_port *port) > > > > if (tcpm_port_is_disconnected(port)) > > > > port->hard_reset_count = 0; > > > > > > > > + port->try_src_count = 0; > > > > + port->try_snk_count = 0; > > > > > > This patch breaks partner detection for USB type-c hubs and USB type-c docks. > > > > I guess the type-c port of hub is sink-only and the type-c port of dock > > is DRP, right? > > The hub is sink-only, yes. > > > > > > > Connecting an unpowered USB-C 4-port HUB: > > > > > > Before reverting this patch: (endless loop) > > > > > > [ 12.957711] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] > > > [ 12.957720] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] > > > [ 12.957729] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS] > > > [ 13.157924] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms] > > > [ 13.157939] cc:=2 > > > [ 13.167339] pending state change SNK_TRY -> SNK_TRY_WAIT @ 100 ms [rev1 NONE_AMS] > > > [ 13.267545] state change SNK_TRY -> SNK_TRY_WAIT [delayed 100 ms] > > > [ 13.267561] state change SNK_TRY_WAIT -> SRC_TRYWAIT [rev1 NONE_AMS] > > > [ 13.267566] cc:=3 > > > [ 13.278148] pending state change SRC_TRYWAIT -> SRC_TRYWAIT_UNATTACHED @ 100 ms [rev1 NONE_AMS] > > > > Based on my assumption, the DRP port is presenting Rp-default termination on CC line again, > > then tcpc should report CC change due to a connection is established in 100 ms. However, this > > CC change is not reported here. This leads to state from SRC_TRYWAIT to SRC_TRYWAIT_UNATTACHED > > rather SRC_TRYWAIT_DEBOUNCE. > > > > Below log is a normal case. > > > > --- > > [ 149.954434] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] > > [ 149.954447] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] > > [ 149.954452] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS] > > [ 150.154543] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms] > > [ 150.154554] cc:=2 > > [ 150.154859] pending state change SNK_TRY -> SNK_TRY_WAIT @ 100 ms [rev1 NONE_AMS] > > [ 150.254881] state change SNK_TRY -> SNK_TRY_WAIT [delayed 100 ms] > > [ 150.254893] state change SNK_TRY_WAIT -> SRC_TRYWAIT [rev1 NONE_AMS] > > [ 150.254896] cc:=3 > > [ 150.255200] pending state change SRC_TRYWAIT -> SRC_TRYWAIT_UNATTACHED @ 100 ms [rev1 NONE_AMS] > > [ 150.257288] CC1: 0 -> 0, CC2: 2 -> 2 [state SRC_TRYWAIT, polarity 0, connected] > > [ 150.257295] state change SRC_TRYWAIT -> SRC_TRYWAIT_DEBOUNCE [rev1 NONE_AMS] > > [ 150.257300] pending state change SRC_TRYWAIT_DEBOUNCE -> SRC_ATTACHED @ 200 ms [rev1 NONE_AMS] > > [ 150.457319] state change SRC_TRYWAIT_DEBOUNCE -> SRC_ATTACHED [delayed 200 ms] > > [ 150.457329] cc:=3 > > [ 150.457606] polarity 1 > > [ 150.458314] Requesting mux state 1, usb-role 1, orientation 2 > > [ 150.460722] vbus:=1 charge=0 > > --- > > > > So the issue may be why that CC change is not reported? > > But there is no change. Your log has: > > CC1: 0 -> 0, CC2: 2 -> 2 [state SRC_TRYWAIT, polarity 0, connected] > > How to interpret this? This is with fusb302 driver. The driver has bunch of When try sink fails (note: cc:=2 in this period), the tcpm will change to SRC_TRYWAIT state and it will pull up CC to Rp-default (cc:=3). Since the partner is a sink-only port, I think the type-c chip will sense a connection is established. Therefore, a CC change event is reported by type-c chip. I'm not sure the behaviors of fusb302 chip when set cc:=3. If it does not generate interrupt for this change, then tcpm may think the partner has been disconnected and move the state to SRC_TRYWAIT_UNATTACHED. Maybe it's a real hw issue or the event is masked by sw. Is this dock also failed to connect other sink-only devices? > gates to not report cc status when it doesn't change: > > https://elixir.bootlin.com/linux/latest/source/ > drivers%2Fusb%2Ftypec%2Ftcpm%2Ffusb302.c%23L1215&data=05%7C02%7Cxu.yang_2%40nxp.com%7C836aa20d8f9549e9 > 636008dc34ea9e0f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638443429472475922%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bCXr5obX2B > hKh5ZZt7CZHQ6OLhJ7JFgSPkW7f49NKfs%3D&reserved=0 > > in several places where tcpm_cc_change is called. Not sure what is the > expectation of TCPM state machine, whether it always expects tcpm_cc_change() > call after it calls set_cc callback, or what exactly. I think the tcpm_cc_change() will be called only when a real CC change happens on the CC line. It's irrelevant to whether tcpm_set_cc() is called or not. Thanks, Xu Yang > > kind regards, > o. > > > Please refer to USB Type-C Specification > > Figure 4-17 Connection State Diagram: DRP with Accessory and Try.SNK Support > > > > Thanks, > > Xu Yang > > > > > [ 13.378347] state change SRC_TRYWAIT -> SRC_TRYWAIT_UNATTACHED [delayed 100 ms] > > > [ 13.378364] state change SRC_TRYWAIT_UNATTACHED -> SNK_UNATTACHED [rev1 NONE_AMS] > > > [ 13.378373] Start toggling > > > [ 13.387019] state change SNK_UNATTACHED -> TOGGLING [rev1 NONE_AMS] > > > [ 13.462597] CC1: 0 -> 0, CC2: 2 -> 2 [state TOGGLING, polarity 0, connected] > > > [ 13.462606] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] > > > [ 13.462613] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS] > > > [ 13.662808] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms] > > > [ 13.662827] cc:=2 > >
