All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Li <lijun.kernel@gmail.com>
To: ChiYuan Huang <u0084500@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	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>, Li Jun <jun.li@nxp.com>
Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue
Date: Wed, 7 Oct 2020 00:52:07 +0800	[thread overview]
Message-ID: <CAKgpwJWwyvUyVj+jQ0y2i_eK1XEN2g3NvR0zgrRLfcmtgn8DDg@mail.gmail.com> (raw)
In-Reply-To: <CADiBU38wk825SqtFRAiYqqV47Wwi43AuWKut19qeTbGBZFqPow@mail.gmail.com>

ChiYuan Huang <u0084500@gmail.com> 于2020年10月6日周二 下午12:38写道:
>
> Guenter Roeck <linux@roeck-us.net> 於 2020年10月5日 週一 下午11:30寫道:
> >
> > On 10/5/20 4:08 AM, Greg KH wrote:
> > [ ... ]
> > >>> What ever happened with this patch, is there still disagreement?
> > >>>
> > >>
> > >> Yes, there is. I wouldn't have added the conditional without reason,
> > >> and I am concerned that removing it entirely will open another problem.
> > >> Feel free to apply, though - I can't prove that my concern is valid,
> > >> and after all we'll get reports from the field later if it is.
> > >
> > > Ok, can I get an ack so I know who to come back to in the future if
> > > there are issues?  :)
> > >
> >
> > Not from me, for the reasons I stated. I would be ok with something like:
> >
> > -       if (tcpm_port_is_disconnected(port))
> > +       if (tcpm_port_is_disconnected(port) ||
> > +           (tcpm_cc_is_open(port->cc1) && tcpm_cc_is_open(port->cc2)))
> >
> > to narrow down the condition.
>
> I have tried the above comment and It doesn't work.
> How about to change the judgement like as below
>
> -       if (tcpm_port_is_disconnected(port))
> +       if (tcpm_port_is_disconnected(port) || !port->vbus_present)
>
> The hard_reset_count not reset issue is following by the below order
> 1. VBUS off ( at the same time, cc is still detected as attached)
> port->attached become false and cc is not open
> 2. After that, cc detached.
> due to port->attached is false, tcpm_detach() directly return.

If tcpm_detach() return directly, then how your patch can reset
hard_reset_count?

I am seeing the same issue on my platform, the proposed change:
-       if (tcpm_port_is_disconnected(port))
-               port->hard_reset_count = 0;
+       port->hard_reset_count = 0;
can't resolve it on my platform.

How about reset hard_reset_count in SNK_READY?
@@ -3325,6 +3329,7 @@ static void run_state_machine(struct tcpm_port *port)
        case SNK_READY:
                port->try_snk_count = 0;
                port->update_sink_caps = false;
+               port->hard_reset_count = 0;
                if (port->explicit_contract) {
                        typec_set_pwr_opmode(port->typec_port,
                                             TYPEC_PWR_MODE_PD);

can this resolve your problem?

Li Jun
>
> And that's why hard_reset_count is not reset to 0.
> >
> > Guenter

  reply	other threads:[~2020-10-06 16:52 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 [this message]
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
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=CAKgpwJWwyvUyVj+jQ0y2i_eK1XEN2g3NvR0zgrRLfcmtgn8DDg@mail.gmail.com \
    --to=lijun.kernel@gmail.com \
    --cc=cy_huang@richtek.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=jun.li@nxp.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.