[PATCH v4] phy: Add USB3 PHY support to Google Tensor SoC USB PHY driver

[RD Babiera]

On Mon, Jul 6, 2026 at 4:27 PM <sashiko-bot at kernel.org> wrote:
> [Severity: High]
> This is a pre-existing issue, but does this function have a race condition
> with power management that could cause a bus fault?
>
> google_usb_set_orientation() checks pm_runtime_suspended(gphy->dev) without
> holding a PM runtime reference. If the USB core releases its PM reference
> immediately after this check, the device could suspend and power off the PHY.
>
> The function would then acquire the lock and call set_vbus_valid() and
> program_tca_locked() on unclocked and unpowered MMIO registers, resulting
> in a synchronous external abort.
>
> Would it be safer to use pm_runtime_get_sync() to ensure the hardware
> remains active during these accesses?

I'll add a get_noresume call prior to checking runtime_suspended,
and then adding a put_autosuspend at the end of the set_orientation
call. If the suspended check fails, we can put_noidle here. This would
cover not programming vbus_valid when unnecessary, and addressing
any race condition if the runtime count drops to zero during the locked
section.

> [Severity: High]
> Can this lead to redundant TCA programming and a 2.5-second timeout?
>
> Looking at google_usb_set_orientation(), gphy->orientation is updated before
> the mutex is acquired:
>
> google_usb_set_orientation() {
>         gphy->orientation = orientation;
>
>         if (pm_runtime_suspended(gphy->dev))
>                 return 0;
>
>         guard(mutex)(&gphy->phy_mutex);
>         ...
>
> If a Type-C plug event (Thread A) sets gphy->orientation but is preempted
> before taking the lock, and the USB core concurrently calls
> google_usb3_phy_power_on() (Thread B), Thread B will see the new
> orientation, program the TCA, and release the lock.
>
> When Thread A resumes, it will acquire the mutex, see COMBO_PHY_TCA_READY,
> and call program_tca_locked() a second time with the identical configuration.
> Since writing the same configuration to the TCA hardware doesn't trigger a
> new XA_ACT_EVT interrupt, wait_tca_xa_ack() will stall for its full timeout.
>
> Should the orientation update be moved inside the lock?

It should be moved inside the lock, but because if the orientation is
set to none, there can be a race condition where power_on passes the
orientation check and then proceeds to program the TCA when the orientation
is none. Setting the valid bit on the TCA_TCPC register starts a new XA_ACT_EVT
interrupt, so the stall here isn't possible.

Best,
RD