Re: [PATCH v2 1/2] usb: typec: tcpm: Don't cut a pending state delay short on a re-queue

[sashiko-bot@kernel.org]

> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> tcpm_state_machine_work() applies port->delayed_state as soon as it
> runs, assuming it only runs when the state machine timer fired. The
> work can also run because it was queued for another reason while it was
> already running.
> 
> This happens at every port registration: tcpm_init() runs with the port
> lock held and calls tcpm_set_state() twice with no delay (default state,
> then PORT_RESET). The first call queues the work, which starts and
> blocks on the lock; the second call queues it again. The first run
> handles PORT_RESET and schedules PORT_RESET_WAIT_OFF after
> PD_T_ERROR_RECOVERY; the second run then applies it at once. On an
> Orange Pi 5 (FUSB302) the log shows the 100 ms ErrorRecovery taking
> 6 us:
> 
>   pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
>   state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
> 
> so the "clean slate" that tcpm_init() asks for never happens.
> 
> If the delay has not expired yet, re-arm the timer for the time left
> and return, as tcpm_send_queued_message() already does.
> 
> Fixes: 3ed8e1c2ac99 ("usb: typec: tcpm: Migrate workqueue to RT priority for processing events")
> Cc: stable@vger.kernel.org
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-tcpm-attach-reboot-v2-0-b4bc6ca83490@gmail.com?part=1