On Thu, Oct 13, 2022 at 12:35 PM Ferry Toth fntoth@gmail.com wrote:
<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: >
OK, got a chance to try things with that patch. Both v6.0 and v6.0 with my patches reverted work the same, my Kingston DataTraveller USB stick enumerates and works as expected.
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.
OK to cut this back and forth short, I think it'd be easier to just ask you to run what I run. Here's vanilla v6.0 bzImage and initrd (built with your config + CONFIG_PHY_TUSB1210=y) I tested with https://drive.google.com/drive/folders/1H28AL1coPPZ2kLTYskDuDdWo-oE7DRPH?usp... let's see how it behaves on your setup. There's also the U-Boot binary I use in that folder in case you want to give it a try.
Now on Merrifield dwc3_get_extcon() doesn't do anything but call extcon_get_extcon_dev() which doesn't touch any hardware or interact with other drivers, so assuming
So current v6.0 has: dwc3_get_extcon - dwc3_get_dr_mode - ... - dwc3_core_init - .. - dwc3_core_init_mode (not working)
I changed to: dwc3_get_dr_mode - dwc3_get_extcon - .. - dwc3_core_init - .. - dwc3_core_init_mode (no change)
Then to: dwc3_get_dr_mode - .. - dwc3_core_init - .. - dwc3_get_extcon - dwc3_core_init_mode (works)
still holds(did you double check that with vanilla v6.0?) the only difference that I can see is execution timings. It seems to me it's either an extra delay added by execution of extcon_get_extcon_dev() (unlikely) or multiple partial probes that include dwc3_core_init() that change things. You can try to check the latter by adding an artificial probe deferral point after dwc3_core_init(). Something like (didn't test this):
modified drivers/usb/dwc3/core.c @@ -1860,6 +1860,10 @@ static int dwc3_probe(struct platform_device *pdev) goto err3;
ret = dwc3_core_init(dwc); + static int deferral_counter = 0; + if (deferral_counter++ < 9) /* I counted 9 deferrals in my testing */ + ret = -EPROBE_DEFER; + if (ret) { dev_err_probe(dev, ret, "failed to initialize core\n"); goto err4;