linux-stable.git/drivers/usb/typec, branch master

usb: typec: hd3ss3220: fix VBUS regulator error message

2026-08-14T01:49:43+00:00

hd3ss3220_regulator_control() enables the VBUS regulator when @on is
true and disables it when @on is false.  However, its error message uses
the opposite operation name, so an enable failure is reported as a
disable failure and vice versa.

Print the operation that was actually attempted.  Reporting the opposite
regulator operation on failures can mislead debugging of VBUS problems.

Fixes: 27fbc19e52b9 ("usb: typec: hd3ss3220: Enable VBUS based on role state")
Cc: stable@vger.kernel.org
Reviewed-by: Heikki Krogerus 
Signed-off-by: Xu Rao 
Link: https://patch.msgid.link/7A42A287B2B588D0+20260812094632.348581-1-raoxu@uniontech.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive()

2026-08-14T01:49:06+00:00

Previously, tcpci_irq() always passed TCPC_TX_SOP as the receive type
to tcpm_pd_receive(), ignoring the actual frame type reported by the
TCPC_RX_BUF_FRAME_TYPE register.

Cache the TCPC_RX_DETECT register value in rx_type_mask variable. When
a PD messageis received, read TCPC_RX_BUF_FRAME_TYPE register and handle
the message only if its frame type is enabled in mask.

The TCPC_RX_BUF_FRAME_TYPE register records the received message type,
which has a 1:1 mapping to enum tcpm_transmit_type.

Fixes: fb7ff25ae433 ("usb: typec: tcpm: add discover identity support for SOP'")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang 
Acked-by: Heikki Krogerus 
Reviewed-by: Badhri Jagan Sridharan 
Link: https://patch.msgid.link/20260723104614.3717623-1-xu.yang_2@oss.nxp.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion

2026-08-14T01:48:55+00:00

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 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Fedor Pchelkin 
Link: https://patch.msgid.link/20260805085725.389761-1-huangwei@kylinos.cn
Signed-off-by: Greg Kroah-Hartman

usb: typec: thunderbolt: Disable work before freeing tbt on remove

2026-08-14T01:37:54+00:00

tbt_altmode_remove() drops the plug and cable references without
draining tbt->work. The work function dereferences those references,
and can also requeue itself in its error path. The VDM callbacks can
queue the same work item.

Disable and drain tbt->work before dropping the references. This waits
for an existing invocation and prevents subsequent schedule_work()
calls from queueing it during teardown.

This issue was found by an in-house static analysis tool and confirmed
by manual code review.

Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu 
Acked-by: Heikki Krogerus 
Link: https://patch.msgid.link/20260802014959.416687-1-fanwu01@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman

Merge 7.2-rc5 into usb-next

2026-07-27T06:40:53+00:00

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path

2026-07-23T08:38:19+00:00

The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and
ordering in port unregistration") consolidated port teardown into the
ucsi_unregister_port() helper. However, it introduced an ordering problem
in the ucsi_init() error path.

Fix this by ensuring ucsi_unregister_port() is called before we unregister
their corresponding lockdep keys.

Cc: stable@vger.kernel.org
Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration")
Reported-by: "Borah, Chaitanya Kumar" 
Closes: https://lore.kernel.org/all/22064276-6c56-411a-9f20-6917ceeb865f@intel.com/
Signed-off-by: Andrei Kuchynski 
Tested-by: Chaitanya Kumar Borah 
Reviewed-by: Heikki Krogerus 
Link: https://patch.msgid.link/20260717104614.325250-1-akuchynski@chromium.org
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: implement retry mechanism for Discover Identity VDMs

2026-07-23T08:33:18+00:00

The current mechanism for sending Discover Identity in the ready state
presents a flaw where tcpm_queue_vdm can collide with non interruptible
AMSes such as GET_SINK_CAP or VCONN_SWAP. vdm_run_state_machine will hit
the VDM_STATE_BUSY state, and Discover SVIDs or Discover Modes will not
retry.

This patch introduces a state machine under the enum vdm_discovery_states.
The tcpm_port field vdm_discovery_state tracks which step of the Discover
Identity process has been completed.

The current TCPM implementation utilizes the send_discover and
send_discover_prime booleans to queue Discover Identity in the
aforementioned collision case. These booleans are removed in place of
vdm_discovery_state and send_discover_work is replaced by
vdm_discovery_work, which runs unconditionally in the ready state.
When the Discovery process is complete, the port will move to the
VDM_DISCOVERY_COMPLETE state and vdm_discovery_work becomes a no-op.
When there are still Discovery VDMs to be sent, vdm_discovery_work will
continue based on the last received response from the port partner or
cable.

Signed-off-by: RD Babiera 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Badhri Jagan Sridharan 
Link: https://patch.msgid.link/20260717232612.3671978-2-rdbabiera@google.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: altmodes: select DRM_AUX_HPD_BRIDGE for TYPEC_DP_ALTMODE

2026-07-17T10:33:18+00:00

When TYPEC_DP_ALTMODE is enabled, DRM_AUX_HPD_BRIDGE is most likely
also needed for embedded platforms. Select it when available.

Suggested-by: Xu Yang 
Signed-off-by: Chaoyi Chen 
Reviewed-by: Heikki Krogerus 
Link: https://patch.msgid.link/20260709062147.240-1-kernel@airkyi.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: Add support for Battery Cap response message

2026-07-17T10:33:06+00:00

Add support for responding to Get_Battery_Cap (extended) request with a
a Battery_Capabilities (extended) msg. The requester will request
Battery Cap for a specific battery using an index in Get_Battery_Cap. In
case of failure to identify battery, TCPM shall reply with an
appropriate message indicating so.

As the Battery Cap Data Block size is 9 Bytes (lesser than
MaxExtendedMsgChunkLen of 26B), only a single chunk is required to
complete the AMS.

Support for Battery_Capabilities message is required for sinks that
contain battery as specified in USB PD Rev3.1 v1.8
("Applicability of Data Messages" section).

Signed-off-by: Amit Sunil Dhamne 
Reviewed-by: Badhri Jagan Sridharan 
Acked-by: Heikki Krogerus 
Link: https://patch.msgid.link/20260714-batt-caps-upstream-v1-1-c86f0a7fbbda@google.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: Add support for Battery Status response message

2026-07-17T10:32:45+00:00

Add support for responding to a Get_Battery_Status request with a
Battery_Status message. The port partner shall request the status of a
port's battery by providing an index in the Get_Battery_Status AMS. In
case of failure to identify the battery, the port shall reply with an
appropriate message indicating so.

Support for Battery_Status message is required for sinks that contain
battery as specified in USB PD Rev3.1 v1.8
("Applicability of Data Messages" section).

Signed-off-by: Amit Sunil Dhamne 
Reviewed-by: Badhri Jagan Sridharan 
Acked-by: Heikki Krogerus 
Link: https://patch.msgid.link/20260714-batt-status-v5-2-9de4aa900b69@google.com
Signed-off-by: Greg Kroah-Hartman