Re: [PATCH 1/2] clk: mediatek: mt7988: keep combo-lane U3 PHY ref clock enabled
From: Frank Wunderlich
Date: Mon Sep 21 2026 - 07:32:21 EST
Am 21. September 2026 um 11:59 schrieb "AngeloGioacchino Del Regno" <angelogioacchino.delregno@xxxxxxxxxxxxx>:
Hi angelo
> On 9/19/26 13:47, Frank Wunderlich wrote:
>
> >
> > From: Mihai Ordean <research@xxxxxxxxxxxxxxx>
> > CLK_INFRA_USB_PIPE is the reference clock of xphyu3port0, the U3/PCIe
> > combo serdes. On MT7988 that lane is shared between ssusb0's SuperSpeed
> > side and pcie2, but only the consumer that claims the PHY holds the gate.
> > On the BPI-R4 Pro, ssusb0 is configured USB2-only (u3p-dis-msk=1) and
> > pcie2 claims the lane for the CN13/CN15 M.2 slot, so pcie2 is the sole
> > holder. u3p-dis-msk does not remove ssusb0's SuperSpeed root hub: that is
> > decided by xhci_has_one_roothub(), which keys off usb3_rhub.num_ports
> > from the xHCI capability registers, so bus 2 is registered and live
> > regardless. When the M.2 slot is empty, pcie2 fails link training (-110)
> > and its error path calls phy_power_off()/phy_exit(), which gates this
> > clock - and sspxtp_sel with it, as nothing else consumes it. The still
> > registered SuperSpeed root hub is then left polling a serdes whose PHY
> > reference clock has just stopped,
> >
> I'm not sure why said clock cannot be assigned to the USB controller as well
> as the PCIe PHY to keep the refcount high, avoiding to gate it?
the clock is assigned to the phy which is assigned to both consumers
mt7988a.dtsi:
xsphy: xs-phy@11e10000 {
compatible = "mediatek,mt7988-xsphy",
"mediatek,xsphy";
...
xphyu3port0: usb-phy@3400 {
reg = <0x3400 0x500>;
clocks = <&infracfg CLK_INFRA_USB_PIPE>;
ssusb0: usb@11190000 {
compatible = "mediatek,mt7988-xhci", "mediatek,mtk-xhci";
...
phys = <&xphyu2port0 PHY_TYPE_USB2>,
<&xphyu3port0 PHY_TYPE_USB3>;
};
pcie2: pcie@11280000 {
compatible = "mediatek,mt7986-pcie",
"mediatek,mt8192-pcie";
...
phys = <&xphyu3port0 PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
...
};
but this seems not enough...do you mean we need to define the clock again for both
consumers (e.g. via assigned-clock-parents property)?
regards Frank
> Cheers,
> Angelo
>
> >
> > and asserts the shared SSUSB interrupt
> > outside the xHCI event ring; xhci_irq() reads USBSTS with EINT clear and
> > returns IRQ_NONE, so the core disables the line ("nobody cared") and the
> > next USB teardown blocks forever in xhci_disable_slot().
> > Boot logs show the storm threshold being crossed 86-107 ms after the
> > pcie2 probe failure, while the earlier combo-mux switch to PCIe mode
> > (~550 ms before) causes no trouble, pointing at the clock gating rather
> > than the mux as the trigger.
> > Mark the gate CLK_IS_CRITICAL so the combo lane keeps its reference clock.
> > Only port 0's gate is affected; ssusb1 uses CLK_INFRA_USB_PIPE_CK_P1.
> > Signed-off-by: Mihai Ordean <research@xxxxxxxxxxxxxxx>
> > Signed-off-by: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx>
regards Frank