<SNIP>
My end goal here is to find a way to test vanilla v6.0 with the two patches reverted on your end. I thought that during my testing I saw tusb1210 print those timeout messages during its probe and that disabling the driver worked to break the loop, but I went back to double check and it doesn't work so scratch that idea. Configuring extcon as a built-in breaks host functionality with or without patches on my end, so I'm not sure it could be a path.
I won't have time to try things with 0043b-TODO-driver-core-Break-infinite-loop-when-deferred-p.patch until the weekend, meanwhile can you give this diff a try with vanilla (no reverts) v6.0:
modified drivers/phy/ti/phy-tusb1210.c @@ -127,6 +127,7 @@ static int tusb1210_set_mode(struct phy *phy, enum phy_mode mode, int submode) u8 reg;
ret = tusb1210_ulpi_read(tusb, ULPI_OTG_CTRL, ®);
- WARN_ON(ret < 0); if (ret < 0) return ret;
@@ -152,7 +153,10 @@ static int tusb1210_set_mode(struct phy *phy, enum phy_mode mode, int submode) }
tusb->otg_ctrl = reg;
- return tusb1210_ulpi_write(tusb, ULPI_OTG_CTRL, reg);
ret = tusb1210_ulpi_write(tusb, ULPI_OTG_CTRL, reg);
WARN_ON(ret < 0);
return ret;
}
#ifdef CONFIG_POWER_SUPPLY
? I'm curious to see if there's masked errors on your end since dwc3 driver doesn't check for those.
root@yuna:~# dmesg | grep -i -E 'warn|assert|error|tusb|dwc3' 8250_mid: probe of 0000:00:04.0 failed with error -16 platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.Intel Corporation-Merrifield.bin failed with error -2 sof-audio-pci-intel-tng 0000:00:0d.0: error: I/O region is too small. sof-audio-pci-intel-tng 0000:00:0d.0: error: failed to probe DSP -19
This is done through configfs only when the switch is set to device mode.
Sure, but can it be disabled? We are looking for unknown variables, so excluding this would be a reasonable thing to do.
It's not enabled until I flip the switch to device mode.