Re: [PATCH v2 2/3] usb: dwc3: qcom: Use the UTMI clock as PIPE clock in DisplayPort-only modes

[Joonhoe Kim <26rote@gmail.com>]

On Tue, 03 Nov 2026 14:35:19 +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
[...]
> Should state->mode == TYPEC_STATE_SAFE and TYPEC_STATE_USB be checked
> before inspecting state->alt, and can gating qcom->dp_only on
> !qcom->dp_active miss valid transitions to DP-only mode?

Yes to both.

typec_altmode_set_mux() passes the DP altmode with the safe and USB
states as well. pmic_glink_altmode passes no altmode with the safe
state, so this did not show up in my tests. v3 checks the safe state
first and treats only the modal states with the DP SVID as
DisplayPort.

The USB states from the DisplayPort altmode driver (exit, removal,
configuration back to USB) all follow a safe state, so they now switch
back to the PIPE clock. Always selecting the UTMI clock for C or E also
covers a change from D to C/E without a safe state in between.

v3 also always selects the UTMI clock for pin assignment C or E. It
keeps the UTMI clock on a change from C/E to D/F while DisplayPort is
active. If the PHY switches then, USB 2.0 keeps working and USB 3 waits
until a USB state follows the next safe state. The PIPE clock while the
PHY is in DP-only mode would stop USB, so v3 errs towards the UTMI
clock.

> [Severity: High]
> How does the synchronization between dwc3_qcom_mux_set(), system sleep, and
> runtime PM handle the following cases?
[...]
> Could the clock selection check be performed inside dwc3_qcom_resume() (so
> both system resume and runtime resume apply any pending change before the
> core resumes), with qcom->pipe_clk_lock and qcom->pm_suspended covering the
> full suspend and resume sequences?

Yes, the cases are real. v3 follows the suggestion:

- The mux callback no longer resumes the glue.
- A flag set under the lock at the start of a runtime or system suspend
  and cleared after the core has resumed makes the callback only
  record the state in between (cases 1 and 2). If the suspend fails,
  the flag is cleared and the state applied right away.
- dwc3_qcom_resume() compares the recorded state with the clock
  selected in QSCRATCH and switches before the core resumes (cases 1,
  3 and 4). v3 has no cached clock state any more. A change recorded
  while the core resumes is applied when the flag is cleared.

I kept pm_suspended as it is, because the resume interrupt handler
uses it.

Tested on the Lenovo Y700 Gen 5 (TB323FU, Kaanapali); details are in
the v3 cover. In those tests the mux state came after resume or needed
no clock change, so a recorded change was not applied on resume.

v3: https://lore.kernel.org/all/20261112113838.506-1-26rote@gmail.com/

Thanks,
Joonhoe Kim