From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE72EC2D0E8 for ; Thu, 26 Mar 2020 12:03:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91B1E20714 for ; Thu, 26 Mar 2020 12:03:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728183AbgCZMD0 (ORCPT ); Thu, 26 Mar 2020 08:03:26 -0400 Received: from mga01.intel.com ([192.55.52.88]:26764 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727948AbgCZMDZ (ORCPT ); Thu, 26 Mar 2020 08:03:25 -0400 IronPort-SDR: GlmTAE/R0+1phTpNdWPJyZjfDeErfT9k0JmRuEQDn3wUzWAcheNigLCoSwVaQbmVg3pAAwkHSt +SVaTND35Z3A== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 05:03:25 -0700 IronPort-SDR: 1ZJ4EORQxCkoT3ZSs5x1mOpeth8srErLVF3TqCGJGWpnCWMMeoDRPepsNMJTyyavBRQQWPc1xE raRstNqCwxAA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,308,1580803200"; d="scan'208";a="326543337" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga001.jf.intel.com with ESMTP; 26 Mar 2020 05:03:21 -0700 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1jHREJ-00D70Q-N2; Thu, 26 Mar 2020 14:03:23 +0200 Date: Thu, 26 Mar 2020 14:03:23 +0200 From: Andy Shevchenko To: Peter Ujfalusi Cc: "Rafael J. Wysocki" , Saravana Kannan , Andrzej Hajda , Artem Bityutskiy , Felipe Balbi , Mark Brown , Ferry Toth , grant.likely@arm.com, Greg Kroah-Hartman , LKML , Linux PM , Android Kernel Team Subject: Re: [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied Message-ID: <20200326120323.GR1922688@smile.fi.intel.com> References: <20200324175719.62496-1-andriy.shevchenko@linux.intel.com> <20200325032901.29551-1-saravanak@google.com> <20200325125120.GX1922688@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > >> On Wed, Mar 25, 2020 at 5:51 AM Andy Shevchenko > >> 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