On Sun, Oct 09, 2022 at 10:02:26PM -0700, Andrey Smirnov wrote:
> On Fri, Oct 7, 2022 at 6:07 AM Ferry Toth <fntoth@xxxxxxxxx> wrote:
Thank you for the testing on your side!
...
> OK, Ferry, I think I'm going to need clarification on specifics on
> your test setup. Can you share your kernel config, maybe your
> "/proc/config.gz", somewhere? When you say you are running vanilla
> Linux, do you mean it or do you mean vanilla tree + some patch delta?
>
> The reason I'm asking is because I'm having a hard time reproducing
> the problem on my end. In fact, when I build v6.0
> (4fe89d07dcc2804c8b562f6c7896a45643d34b2f) and then do a
>
> git revert 8bd6b8c4b100 0f0101719138 (original revert proposed by Andy)
>
> I get an infinite loop of reprobing that looks something like (some
> debug tracing, function name + line number, included):
Yes, this is (one of) known drawback(s) of deferred probe hack. I think
the kernel that Ferry runs has a patch that basically reverts one from
2014 [1] and allows to have extcon as a module. (1)
[1]: 58b116bce136 ("drivercore: deferral race condition fix")
> which renders the system completely unusable, but USB host is
> definitely going to be broken too. Now, ironically, with my patch
> in-place, an attempt to probe extcon that ends up deferring the probe
> happens before the ULPI driver failure (which wasn't failing driver
> probe prior to https://lore.kernel.org/all/20220213130524.18748-7-hdegoede@xxxxxxxxxx/),
> there no "driver binding" event that re-triggers deferred probe
> causing the loop, so the system progresses to a point where extcon is
> available and dwc3 driver eventually loads.
>
> After that, and I don't know if I'm doing the same test, USB host
> seems to work as expected. lsusb works, my USB stick enumerates as
> expected. Switching the USB mux to micro-USB and back shuts the host
> functionality down and brings it up as expected. Now I didn't try to
> load any gadgets to make sure USB gadget works 100%, but since you
> were saying it was USB host that was broken, I wasn't concerned with
> that. Am I doing the right test?
Hmm... What you described above sounds more like a yet another attempt to
workaround (1). _If_ this is the case, we probably can discuss how to fix
it in generic way (somewhere in dd.c, rather than in the certain driver).
That said, the real test case should be performed on top of clean kernel
before judging if it's good or bad.
> For the reference what I test with is:
> - vanilla kernel, no patch delta (sans minor debug tracing) + initrd
> built with Buildroot 2022.08.1
> - Initrd is using systemd (don't think that really matters, but who knows)
> - U-Boot 2022.04 (built with Buildroot as well)
> - kernel config is x86_64_defconfig + whatever I gathered from *.cfg
> files in https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-bsp/recipes-kernel/linux/files
--
With Best Regards,
Andy Shevchenko
