All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Li <jun.li@nxp.com>
To: Guenter Roeck <linux@roeck-us.net>, ChiYuan Huang <u0084500@gmail.com>
Cc: Jun Li <lijun.kernel@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Linux USB List <linux-usb@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	cy_huang <cy_huang@richtek.com>
Subject: RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue
Date: Mon, 12 Oct 2020 08:58:17 +0000	[thread overview]
Message-ID: <VE1PR04MB6528165DAECBCD18083AEDDE89070@VE1PR04MB6528.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <25503f4e-58d1-8c11-9e5e-ea570b529d09@roeck-us.net>



> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Sunday, October 11, 2020 3:32 AM
> To: Jun Li <jun.li@nxp.com>; ChiYuan Huang <u0084500@gmail.com>
> Cc: Jun Li <lijun.kernel@gmail.com>; Greg KH <gregkh@linuxfoundation.org>;
> Heikki Krogerus <heikki.krogerus@linux.intel.com>; Linux USB List
> <linux-usb@vger.kernel.org>; lkml <linux-kernel@vger.kernel.org>;
> cy_huang <cy_huang@richtek.com>
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> On 10/10/20 4:21 AM, Jun Li wrote:

...

> >>
> >> Like I mentioned before, whatever the condition is, hard_reset_count
> >> must be reset to zero during tcpm_detach.
> >
> > This may not be so correct as you said, I think Guenter's concern is valid.
> >
> > tcpm_detach() is not *only* be called in cases of *physical* detach
> > like the function name suggests.
> >
> > The current proposals may *wrongly* reset this counter.
> >
> > Let me give an example:
> >
> > HARD_RESET_SEND -> HARD_RESET_START -> SNK_HARD_RESET_SINK_OFF ->
> > SNK_HARD_RESET_WAIT_VBUS -> SNK_UNATTACHED(in case of VBUS doesn't
> > come back in expected duration)
> > -> call to tcpm_detach()
> >
> > In this sequence, does the sink need keep the counter? From the PD
> > spec, I think the answer is yes, sink need this counter to judge if
> > need do hard reset again or error recovery on later try, see:
> >
> > Figure 8-67 Sink Port State Diagram
> >
> > The difference between your case and my example, is your case never
> > turn off vbus, so will not go to SNK_UNATTACHED, so will not call to
> > tcpm_detach() after first hard reset.
> >
> > So
> > 	if (tcpm_port_is_disconnected(port))
> > 		port->hard_reset_count = 0;
> >
> > should keep as it is, the counter can only be cleared if there is
> > really physical disconnect by *partner*.
> >
> > But current tcpm code may have some problem on keeping local CC state
> > if there is hard reset on-going(port->hard_reset_count > 0), because
> > the current handling of SNK_UNATTACHED may cause disconnection
> > generated by *local*(partner actually keeps its CC), e.g. reset
> > polarity and do drp_toggling, this should be fixed, but this is
> > another patch, I can try to do this later.
> >
> > Back to your problem, I think the issue is, at the first tcpm_detach()
> > the cc disconnect event hasn't happen, so the reset counter is left
> > there but the port->attached is cleared, then the following(real
> > disconnect)
> > tcpm_detach() will just return directly due to port->attached is false.
> >
> > So I guess this will resolve your problem:
> >
> > @@ -2885,6 +2885,9 @@ static void tcpm_reset_port(struct tcpm_port
> > *port)
> >
> >  static void tcpm_detach(struct tcpm_port *port)  {
> > +       if (tcpm_port_is_disconnected(port))
> > +               port->hard_reset_count = 0;
> > +
> >         if (!port->attached)
> >                 return;
> >
> > @@ -2893,9 +2896,6 @@ static void tcpm_detach(struct tcpm_port *port)
> >                 port->tcpc->set_bist_data(port->tcpc, false);
> >         }
> >
> > -       if (tcpm_port_is_disconnected(port))
> > -               port->hard_reset_count = 0;
> > -
> >         tcpm_reset_port(port);
> >  }
> >
> >
> > Compared with current code's condition:
> >    3 static bool tcpm_port_is_disconnected(struct tcpm_port *port)
> >    4 {
> >    5         return (!port->attached && port->cc1 == TYPEC_CC_OPEN &&
> >    6                 port->cc2 == TYPEC_CC_OPEN) ||
> >    7                (port->attached && ((port->polarity ==
> TYPEC_POLARITY_CC1 &&
> >    8                                     port->cc1 == TYPEC_CC_OPEN) ||
> >    9                                    (port->polarity ==
> TYPEC_POLARITY_CC2 &&
> >   10                                     port->cc2 == TYPEC_CC_OPEN)));
> >   11 }
> >
> > My above change is only adding another condition to clear the reset counter:
> > (!port->attached && port->cc1 == TYPEC_CC_OPEN && port->cc2 ==
> > TYPEC_CC_OPEN)
> >
> > This condition is close to Guenter's suggestion in this thread:
> >
> > -       if (tcpm_port_is_disconnected(port))
> > +       if (tcpm_port_is_disconnected(port) ||
> > +           (tcpm_cc_is_open(port->cc1) &&
> > + tcpm_cc_is_open(port->cc2)))
> >
> > Hi Guenter, any comments on this?
> >
> 
> That makes sense, and I would agree to the change you suggest above.

Thanks.

Li Jun
> 
> Guenter
> 
> > Thanks
> > Li Jun
> >
> >>
> >> But refer to Guenter's mail,  he prefer to narrow down the condition
> >> to reset this counter.
> >>
> >> I think the original thought is important why to put this line there.
> >>
> >> Hi, Guenter:
> >>    From the discussion, we really need to know why you put the reset
> >> line below port attached is false and also make some judgement.
> >> I think there may be ome condition that we don't considered.
> >
> > This condition was added at first place, I think my above
> >>
> >>>
> >>>>
> >>>>>>>>
> >>>>>>>> Guenter


  parent reply	other threads:[~2020-10-12  8:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 15:35 [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue cy_huang
2020-09-02 16:57 ` Guenter Roeck
2020-09-03 16:21   ` ChiYuan Huang
2020-09-04 19:41     ` Guenter Roeck
2020-09-05  1:24       ` ChiYuan Huang
2020-09-05 15:51         ` Guenter Roeck
2020-09-06 15:22           ` ChiYuan Huang
2020-09-15  3:07             ` ChiYuan Huang
2020-10-02 13:31               ` Greg KH
2020-10-02 14:26                 ` Guenter Roeck
2020-10-05 11:08                   ` Greg KH
2020-10-05 15:30                     ` Guenter Roeck
2020-10-06  4:37                       ` ChiYuan Huang
2020-10-06 16:52                         ` Jun Li
2020-10-06 17:39                           ` ChiYuan Huang
2020-10-07 10:13                             ` ChiYuan Huang
2020-10-09  6:12                               ` Jun Li
2020-10-09 16:06                                 ` ChiYuan Huang
2020-10-10 11:21                                   ` Jun Li
2020-10-10 19:31                                     ` Guenter Roeck
2020-10-12  6:22                                       ` ChiYuan Huang
2020-10-12  9:25                                         ` Jun Li
2020-10-12  8:58                                       ` Jun Li [this message]
2020-10-10 15:46                                   ` Guenter Roeck
2020-10-09  2:58                             ` Jun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VE1PR04MB6528165DAECBCD18083AEDDE89070@VE1PR04MB6528.eurprd04.prod.outlook.com \
    --to=jun.li@nxp.com \
    --cc=cy_huang@richtek.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=lijun.kernel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=u0084500@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.