From: Grant Likely <grant.likely@arm.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Saravana Kannan <saravanak@google.com>,
Andrzej Hajda <a.hajda@samsung.com>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Felipe Balbi <balbi@kernel.org>, Mark Brown <broonie@kernel.org>,
Ferry Toth <fntoth@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Android Kernel Team <kernel-team@android.com>, nd <nd@arm.com>
Subject: Re: [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied
Date: Thu, 26 Mar 2020 13:45:50 +0000 [thread overview]
Message-ID: <6c04af00-adc8-6be2-b7fd-b4a875524563@arm.com> (raw)
In-Reply-To: <20200326120323.GR1922688@smile.fi.intel.com>
On 26/03/2020 12:03, Andy Shevchenko wrote:
> 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@google.com> wrote:
>>>> On Wed, Mar 25, 2020 at 5:51 AM Andy Shevchenko
>>>> <andriy.shevchenko@linux.intel.com> 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.
I've not been involved in this for a very long time, but from our past
conversations and the description that is given here I still feel that
this problem is a design bug on the dwc3 driver dependencies rather than
a failure with driver core. dwc3 is doing something rather convoluted
and it would be worth reevaluating how probe failures are unwound on
that particular driver stack.
g.
next prev parent reply other threads:[~2020-03-26 13:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 17:57 Andy Shevchenko
2020-03-25 3:29 ` Saravana Kannan
2020-03-25 12:51 ` Andy Shevchenko
2020-03-25 22:08 ` Saravana Kannan
2020-03-26 8:39 ` Rafael J. Wysocki
2020-03-26 9:45 ` Peter Ujfalusi
2020-03-26 12:03 ` Andy Shevchenko
2020-03-26 13:45 ` Grant Likely [this message]
2020-03-26 14:23 ` Andy Shevchenko
2020-03-26 11:57 ` Andy Shevchenko
2020-03-26 13:48 ` Grant Likely
2020-03-26 18:45 ` Saravana Kannan
2020-03-26 11:54 ` Andy Shevchenko
2020-03-26 14:46 ` Grant Likely
2020-03-26 19:55 ` Saravana Kannan
2020-03-26 15:01 ` Grant Likely
2020-03-26 15:20 ` Grant Likely
2020-03-26 16:31 ` Andy Shevchenko
2020-03-26 16:39 ` Greg KH
2020-03-26 18:06 ` Grant Likely
2020-03-27 8:03 ` Greg KH
2020-03-27 12:37 ` Grant Likely
2020-03-27 12:51 ` Greg KH
2020-06-08 9:17 ` Marco Felsch
2020-06-08 11:11 ` Andrzej Hajda
2020-06-09 6:45 ` Marco Felsch
2020-06-09 7:30 ` Saravana Kannan
2020-06-09 9:27 ` Andrzej Hajda
2020-06-09 12:10 ` Marco Felsch
2020-06-09 13:02 ` Andrzej Hajda
2020-06-09 13:16 ` Mark Brown
2020-06-08 11:13 ` Andy Shevchenko
2020-06-08 11:59 ` Marco Felsch
2020-06-08 12:11 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c04af00-adc8-6be2-b7fd-b4a875524563@arm.com \
--to=grant.likely@arm.com \
--cc=a.hajda@samsung.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=balbi@kernel.org \
--cc=broonie@kernel.org \
--cc=fntoth@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nd@arm.com \
--cc=peter.ujfalusi@ti.com \
--cc=rafael@kernel.org \
--cc=saravanak@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®