From: Xu Yang <xu.yang_2@nxp.com>
To: linux@roeck-us.net
Cc: jun.li@nxp.com, heikki.krogerus@linux.intel.com,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-imx@nxp.com
Subject: [PATCH 1/2] usb: typec: tcpm: Fix up tcpm set delayed state which may not delay
Date: Tue, 24 Aug 2021 19:30:13 +0800 [thread overview]
Message-ID: <20210824113014.1420117-1-xu.yang_2@nxp.com> (raw)
Setting a delayed state by tcpm_set_state may enter the delayed state
instantly without delay for the specified time.
[ 65.424458] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected]
[ 65.424475] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
[ 65.427233] VBUS off
[ 65.427238] VBUS VSAFE0V
[ 65.427243] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS]
[ 65.427252] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms]
[ 65.427258] cc:=2
In this log, tcpm should change to SNK_TRY state after 200 ms.
The following sequence may trigger this abnormal result:
[tcpm_pd_event_handler] [tcpm_state_machine_work]
1 tcpm_set_state(A, 0)
2 port->state = A
3 port->delayed_state = INVALID_STATE
4 queue work to worker_list
5 tcpm_set_state(B, ms)
6 port->delayed_state = B
7 start timer
8 dequeue work from worker_list
9 tcpm_state_machine_work
10 port->delayed_state != INVALID_STATE
11 port->state = B
12 port->delayed_state = INVALID_STATE
13 handle B state
In step 9, tcpm_state_machine_work gets scheduled because it has
been queued in step 4. At this point, however, both port->state and
port->delayed_state are non INVALID_STATE which causes the pending state
to be handled in step 13 without delay.
If a non-delayed state and a delayed state are orderly set in some works
except tcpm_state_machine_work, this bug will certainly occur. Also, if
set in a thread different from tcpm worker thread, this bug may occur.
Therefore, when port->delayed_state is a valid state but the
state_machine_timer is still running, tcpm_state_machine_work should
keep the delayed state pending until the state_machine_timer timeout.
Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
cc: <stable@vger.kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index c40e0513873d..4bdf119b1306 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4815,7 +4815,8 @@ static void tcpm_state_machine_work(struct kthread_work *work)
goto done;
/* If we were queued due to a delayed state change, update it now */
- if (port->delayed_state) {
+ if (port->delayed_state != INVALID_STATE &&
+ ktime_after(ktime_get(), port->delayed_runtime)) {
tcpm_log(port, "state change %s -> %s [delayed %ld ms]",
tcpm_states[port->state],
tcpm_states[port->delayed_state], port->delay_ms);
--
2.25.1
next reply other threads:[~2021-08-24 11:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 11:30 Xu Yang [this message]
2021-08-24 11:30 ` [PATCH 2/2] usb: typec: tcpm: Don't handle two continuous same state Xu Yang
2021-08-24 16:41 ` Guenter Roeck
2021-08-24 16:56 ` [PATCH 1/2] usb: typec: tcpm: Fix up tcpm set delayed state which may not delay Guenter Roeck
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=20210824113014.1420117-1-xu.yang_2@nxp.com \
--to=xu.yang_2@nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jun.li@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).