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@xxxxxxxxxxxxxxx>
> Signed-off-by: Xu Yang <xu.yang_2@xxxxxxx>
>
> ---
> 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
