From: Greg KH <gregkh@linuxfoundation.org>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: linux@roeck-us.net, heikki.krogerus@linux.intel.com,
linux-usb@vger.kernel.org, linux-imx@nxp.com, jun.li@nxp.com
Subject: Re: [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state
Date: Mon, 11 Oct 2021 13:25:02 +0200 [thread overview]
Message-ID: <YWQfDjkgRA4GR7ot@kroah.com> (raw)
In-Reply-To: <20211011103210.156552-1-xu.yang_2@nxp.com>
On Mon, Oct 11, 2021 at 06:32:10PM +0800, Xu Yang wrote:
> There are potential problems when states are set as following:
>
> tcpm_set_state(A, 0)
> tcpm_set_state(B, X)
>
> As long as the state A is set and the state_machine work is queued
> successfully, state_machine work will be scheduled soon after. Before
> running into tcpm_state_machine_work(), there is a chance to set state
> B again. If it does occur:
>
> either (X = 0)
> port->state = B and state_machine work is queued again, then work
> will be executed twice.
> or (X != 0)
> port->state = A and port->delayed_state = B, then work will be
> executed once but timer is still running.
>
> For this situation, tcpm should only handle the most recent state change
> as if only one state is set just now. Therefore, if the state_machine work
> has already been queued, it can't be queued again before running into
> tcpm_state_machine_work().
>
> The state_machine_running flag already prevents from queuing the work, so
> we can make it contain the pending stage (after work be queued and before
> running into tcpm_state_machine_work). The state_machine_pending_or_running
> flag can be used to indicate that a state can be handled without queuing
> the work again.
>
> Because the state_machine work has been queued for state A, there is no
> way to cancel as it may be already dequeued later, and then will run into
> tcpm_state_machine_work() certainly. To handle the delayed state B, such
> an abnormal work should be skiped. If port->delayed_state != INVALID_STATE
> and timer is still running, it's time to skip.
>
> Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging")
> cc: <stable@vger.kernel.org>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes for v2:
> -Try to avoid such problems occurring from the source.
> -Set a state_machine_pending_or_running flag to indicate that a state
> can be handled without queuing the work again.
I think this is a v3, as I see 2 v2 patches here :(
v4 now please?
thanks,
greg k-h
next prev parent reply other threads:[~2021-10-11 11:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 10:32 [PATCH v2] usb: typec: tcpm: fix issue of multiple tcpm_set_state Xu Yang
2021-10-11 11:25 ` Greg KH [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-08-27 11:48 Xu Yang
2021-09-13 10:42 ` Xu Yang
2021-10-09 2:28 ` Xu Yang
2021-10-11 6:31 ` Heikki Krogerus
2021-10-11 14:11 ` 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=YWQfDjkgRA4GR7ot@kroah.com \
--to=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 \
--cc=xu.yang_2@nxp.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.