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

RD Babiera rdbabiera at google.com
Mon Jul 6 15:43:51 PDT 2026


On Tue, Jun 30, 2026 at 7:40 PM <sashiko-bot at kernel.org> wrote:
> > +static int google_usb3_phy_exit(struct phy *_phy)
> > +{
> > +     struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
> > +     struct google_usb_phy *gphy = inst->parent;
> > +
> > +     dev_dbg(gphy->dev, "exiting usb3 phy\n");
> > +
> > +     guard(mutex)(&gphy->phy_mutex);
> > +
> > +     set_pmgt_ref_clk_req_n(gphy, false);
> > +     reset_control_bulk_assert(inst->num_rsts, inst->rsts);
> > +     clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
>
> [Severity: High]
> Is the manual teardown sequence here in the correct order?
>
> In google_usb3_phy_init(), resources are acquired in this order:
> 1) set_pmgt_ref_clk_req_n(true)
> 2) clock enable
> 3) reset deassert
>
> The __free blocks in the init function correctly establish the error cleanup
> sequence in reverse order (LIFO). However, here the upstream reference clock
> request is disabled before placing the hardware block into reset and
> disabling clocks.
>
> Could disabling the clock request before asserting reset freeze the IP in an
> invalid state and prevent subsequent wakeups?

I've verified both orderings of set_pmgt_ref_clk_req_n in phy_exit, will
change to be consistent with phy_init ordering though.

> > +
> > +     return program_tca_locked(gphy);
>
> [Severity: High]
> Should this check if the Type-C port is actually connected before calling
> program_tca_locked()?
>
> If the port is disconnected (gphy->orientation == TYPEC_ORIENTATION_NONE),
> program_tca_locked() falls through its else branch, configuring the registers
> for TYPEC_ORIENTATION_NORMAL and setting TCA_TCPC_VALID.
>
> Since the Type-C switch callback google_usb_set_orientation() correctly skips
> TCA programming if the orientation is NONE, should a similar check be present
> here to prevent enabling the SuperSpeed data path for a phantom connection?

Will guard behind gphy->orientation in next version. If the port is
disconnected the
PHY will be treated as being in normal orientation, but given USB mode is being
programmed here and not NC, it's more correct to only program USB when
a port partner is actually connected.

Best,
RD



More information about the linux-phy mailing list