The synchronous command completion path in ucsi_sync_control_common()
hardcodes a 5 second (5 * HZ) timeout when waiting for the PPM to signal
command completion via ACPI notification. This value matched
UCSI_TIMEOUT_MS when it was still 5000 ms, but it was not updated when
that macro was later raised to 10000 ms to fix PPM reset timeouts.

As a result, the two PPM communication paths are now inconsistent: the
polling path in ucsi_reset_ppm() respects the 10 second timeout, while
the event-driven completion path still uses 5 seconds. On machines where
the firmware is slow to respond during boot (e.g. some Lenovo ThinkPad
models such as the E14 Gen 7), commands sent after the PPM reset, such
as SET_NOTIFICATION_ENABLE and GET_CAPABILITY, can exceed 5 seconds and
cause UCSI initialization to fail with:

    ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

Once UCSI init aborts, USB-C PD negotiation never completes, which in
turn blocks USB-C dock enumeration since the dock depends on a successful
PD contract.

Replace the hardcoded 5 * HZ with msecs_to_jiffies(UCSI_TIMEOUT_MS) so
that both communication paths share a single, consistent timeout value,
and future adjustments to UCSI_TIMEOUT_MS are picked up automatically.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221740
Link: https://bugzilla.kernel.org/show_bug.cgi?id=2183790
Fixes: bf4f9ae1cb08c ("usb: typec: ucsi: increase timeout for PPM reset operations")
Cc: stable@vger.kernel.org
Signed-off-by: Huang Wei <huangwei@kylinos.cn>
---
 drivers/usb/typec/ucsi/ucsi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index d221ca9bc88e..37fa20b302ba 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -91,7 +91,8 @@ int ucsi_sync_control_common(struct ucsi *ucsi, u64 command, u32 *cci,
 	if (ret)
 		goto out_clear_bit;
 
-	if (!wait_for_completion_timeout(&ucsi->complete, 5 * HZ))
+	if (!wait_for_completion_timeout(&ucsi->complete,
+					 msecs_to_jiffies(UCSI_TIMEOUT_MS)))
 		ret = -ETIMEDOUT;
 
 out_clear_bit:
-- 
2.25.1

On Wed, 05. Aug 16:57, Huang Wei wrote:
> The synchronous command completion path in ucsi_sync_control_common()
> hardcodes a 5 second (5 * HZ) timeout when waiting for the PPM to signal
> command completion via ACPI notification. This value matched
> UCSI_TIMEOUT_MS when it was still 5000 ms, but it was not updated when
> that macro was later raised to 10000 ms to fix PPM reset timeouts.

Thanks, lgtm.

Reviewed-by: Fedor Pchelkin <boddah8794@gmail.com>

On Wed, Aug 05, 2026 at 04:57:25PM +0800, Huang Wei wrote:
> The synchronous command completion path in ucsi_sync_control_common()
> hardcodes a 5 second (5 * HZ) timeout when waiting for the PPM to signal
> command completion via ACPI notification. This value matched
> UCSI_TIMEOUT_MS when it was still 5000 ms, but it was not updated when
> that macro was later raised to 10000 ms to fix PPM reset timeouts.
> 
> As a result, the two PPM communication paths are now inconsistent: the
> polling path in ucsi_reset_ppm() respects the 10 second timeout, while
> the event-driven completion path still uses 5 seconds. On machines where
> the firmware is slow to respond during boot (e.g. some Lenovo ThinkPad
> models such as the E14 Gen 7), commands sent after the PPM reset, such
> as SET_NOTIFICATION_ENABLE and GET_CAPABILITY, can exceed 5 seconds and
> cause UCSI initialization to fail with:
> 
>     ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
> 
> Once UCSI init aborts, USB-C PD negotiation never completes, which in
> turn blocks USB-C dock enumeration since the dock depends on a successful
> PD contract.
> 
> Replace the hardcoded 5 * HZ with msecs_to_jiffies(UCSI_TIMEOUT_MS) so
> that both communication paths share a single, consistent timeout value,
> and future adjustments to UCSI_TIMEOUT_MS are picked up automatically.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221740
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=2183790
> Fixes: bf4f9ae1cb08c ("usb: typec: ucsi: increase timeout for PPM reset operations")
> Cc: stable@vger.kernel.org
> Signed-off-by: Huang Wei <huangwei@kylinos.cn>

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

> ---
>  drivers/usb/typec/ucsi/ucsi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index d221ca9bc88e..37fa20b302ba 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -91,7 +91,8 @@ int ucsi_sync_control_common(struct ucsi *ucsi, u64 command, u32 *cci,
>  	if (ret)
>  		goto out_clear_bit;
>  
> -	if (!wait_for_completion_timeout(&ucsi->complete, 5 * HZ))
> +	if (!wait_for_completion_timeout(&ucsi->complete,
> +					 msecs_to_jiffies(UCSI_TIMEOUT_MS)))
>  		ret = -ETIMEDOUT;
>  
>  out_clear_bit:
> -- 
> 2.25.1

-- 
heikki

Hi Heikki,

Thanks a lot for the review!

One small thing in case you haven't queued this yet: the second Link
tag in the commit message,

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=2183790

has a typo in the bug ID (2183790 does not exist - kernel.org bugzilla
IDs are six digits). Please feel free to drop that line when applying;
the first link (bug 221740) is the relevant one.

Best regards,
Huang Wei