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

[RD Babiera]

On Mon, Jun 22, 2026 at 11:05 AM <sashiko-bot at kernel.org> wrote:
> [Severity: High]
> Will this error path leak the reference clock request?
>
> Since set_pmgt_ref_clk_req_n(gphy, true) was called earlier, if
> clk_bulk_prepare_enable() fails we return without deasserting the clock
> request.
>
> The driver core doesn't invoke phy_exit() if phy_init() fails, so the
> request will remain permanently asserted.
>
> [Severity: High]
> Does this error path also leak the reference clock request?
>
> It properly unwinds the clocks and resets, but it misses calling
> set_pmgt_ref_clk_req_n(gphy, false) before returning.

I addressed this in V1 where a phy_init failure would likely result
in the hardware powering off and on again and the request would
clear, but I'll change it for the next version for correctness.

> [Severity: High]
> If program_tca_locked() fails, will hardware programming retries fail
> because the software state was prematurely updated?
>
> If the USB subsystem retries powering on the PHY after an error, the early
> success check at the top of google_usb3_phy_power_on() will hit and return 0
> without actually re-attempting the hardware configuration.

I'll change this so that COMBO_PHY_TCA_READY is set when the initial
PoR => NC check passes, but subsequent power_on calls skip waiting
for the PoR => NC request and allow the program_tca_locked() call
to be made while the internal PHY state is COMBO_PHY_TCA_READY.

> [Severity: High]
> Is the missing .power_off callback going to cause the state machine to
> desync on suspend and resume?
>
> During suspend, without a power off hook, gphy->phy_state remains
> COMBO_PHY_TCA_READY. On resume, google_usb3_phy_power_on() checks this
> state and returns 0 without reprogramming the TCA hardware, which could
> permanently break the link.

The change above should cover this case.

> [Severity: Critical]
> Will unconditionally requesting the usb3 clocks break backwards compatibility
> on systems using older device trees?
>
> If an older device tree only provides USB2 resources, devm_clk_bulk_get()
> will fail here and abort the entire probe sequence.
>
> [Severity: Critical]
> Similarly, will unconditionally requiring the usb3_tca resource break probe
> for older device trees that only define USB2 resources?
>
> If the memory region is missing from the DT, this will return an error and
> prevent the USB2 PHY from working on those devices.

The PHY IP supports the USB3 resources by default, so it makes sense
to bake in the requirements.

Best,
RD