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

[RD Babiera]

On Mon, Jun 15, 2026 at 11:17 AM <sashiko-bot at kernel.org> wrote:
> [Severity: High]
> Does this missing update cause USB3 signal routing failures on orientation
> changes?
>
> When the Type-C orientation changes, google_usb_set_orientation() updates
> the software state and calls set_vbus_valid(gphy). While this was sufficient
> for USB2, it doesn't seem to reprogram the newly added USB3 TCA hardware
> multiplexer.
>
> If the orientation flips while the USB3 PHY is active, will the hardware
> state miss the update because program_tca_locked() is not invoked, leaving
> the TCA_TCPC_CONNECTOR_ORIENTATION bit stale?

program_tca_locked should be called if the phy_init and phy_power on sequence
are completed and an orientation change is made. I'll add an internal phy state
enum to indicate when the operation is safe and check in
google_usb_set_orientation.

> [Severity: Medium]
> Is it safe to mix goto-based error handling with scope-based cleanup here?
>
> According to the cleanup subsystem documentation, usage of goto and cleanup
> helpers like guard(mutex) should never be mixed in the same function. Can
> this create confusing execution order and resource ownership?

I'll remove the go-to statements here.

> [Severity: Medium]
> Are we missing a step to revert the hardware clock request on the error path?

set_pmgt_ref_clk_req_n() will reset on the error path as the HW is powered down
and powered on, so there is no concern here.

> [Severity: High]
> Is this hardware teardown sequence in the correct order?

The teardown sequence is consistent with our requirements, no
concern on our end.

> [Severity: High]
> Will this unconditionally time out on subsequent power-on calls?

phy-core documentation indicates that power_on is called after phy_init,
and the power_on callback will only be called when the power_on count is 0.
In addition, the aforementioned internal phy state will prevent an unnecessary
power-on call if the PHY had not been torn down yet.

> [Severity: Medium]
> Is the usb3_core memory region actually used anywhere in the driver?
>
> This maps the usb3_core resource and aborts the probe if it is missing,
> but the resulting gphy->usb3_core_base pointer doesn't appear to be
> referenced later. Could this introduce an unnecessary strict dependency
> that breaks the probe on older Device Trees lacking this resource?

This currently isn't being used in the driver, so it will be fine to
remove it for now.

Best,
RD