Re: [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied

[Andy Shevchenko]

On Thu, Mar 26, 2020 at 11:45:18AM +0200, Peter Ujfalusi wrote:
> On 26/03/2020 10.39, Rafael J. Wysocki wrote:
> > On Wed, Mar 25, 2020 at 11:09 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
> >> On Wed, Mar 25, 2020 at 5:51 AM Andy Shevchenko
> >> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:

...

> > OK, so the situation right now is that commit 58b116bce136 has
> > introduced a regression and so it needs to be fixed or reverted.  The
> > cases that were previously broken and were unbroken by that commit
> > don't matter here, so you cannot argue that they would be "broken".
> 
> commit 58b116bce136 is from 2014 and the whole ULPI support for dwc3
> came in a year later.
> While I agree that 58b116bce136 fail to handle came a year later, but
> technically it did not introduced a regression.
> 
> The revert on the other hand is going to introduce a regression as
> things were working fine since 2014. Not sure why the dwc3 issue got
> this long to be noticed as the 58b116bce136 was already in kernel when
> the ULPI support was added...

I dare to say that is luck based on people's laziness to figure out the root
cause. As I pointed out in email to Saravana the issue is not limited to USB
case and, if my memory doesn't trick me out, I suffered from it approximately
in ~2014-2015 with pin control tables.

> > It looks to me like the original issue fixed by the commit in question
> > needs to be addressed differently, so I would vote for reverting it
> > and starting over.
> 
> Fwiw my original approach was a bit different:
> https://lore.kernel.org/patchwork/patch/454800/

Can you apply above scenario to your patch and see if it solves the issue?
On the other hand to you possess the hardware you can test the original
scenario with my patch applied?

> Greg changed it to what ended up in the kernel:
> https://lore.kernel.org/patchwork/cover/454799/

-- 
With Best Regards,
Andy Shevchenko