Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6023816iog; Thu, 23 Jun 2022 09:46:18 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vUhsL0M75VuSeGqPpsYhDo/hVqFqeH1SD/MsMOJdjyvKpGgvTvLcDQagmZXH0Vr3RIYPY0 X-Received: by 2002:a63:914a:0:b0:40c:f778:9bf with SMTP id l71-20020a63914a000000b0040cf77809bfmr8181148pge.526.1656002778310; Thu, 23 Jun 2022 09:46:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656002778; cv=none; d=google.com; s=arc-20160816; b=B2CXwAkUeF4KmFWg+/T1bUmWB3Q8mgepujVgez1POgE18UdJlew3BuNyHjc+xmCKB6 o7pLk/t3FB5l1TTZ1rmDRxivaHg17S+V6o5UlU/wiG6TNlbws8oZmstk0haIDB9ZOz3Y dMNeVmUREDlhjwAdqJYsJbKfNTtTuzuXkbt03DbCSLkpyKRMliZw5fEF4BLvt/Splvz8 HccrkKUM4r1iKMYkgN7fZAkptVUSccLK+B7Og0aOrHVJEfDQZUyGvNU0RaHCtFOD1zqD yz8CbkDOUzf6qQu8PIQAeRQf7VgozhbWXsB70WxEPH/IJ3rH9TGuMW97CnPWqJBwAp// TPxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=V4/dQ1jGn65R49376KGIs8QgjWfZw67Vgrd3Bo2+HUo=; b=HKnRDX0c5QtbK8LE5ZyvwkyUGW1sTJfQ1g65lqvgOXTfOYQunQ5JDRI/8rTWeVBt78 p5TaBkRdKAxVL2SZAbiIHjQ2oHFxeYQ6WscXM12VYDFpxNfpF6ydftGWq4rZoTGdvP+Q laBuFjlxxPG8sjeauWq0cNUFqRIDyw5VVp4FLWEBQhhFF0E8zIq1eMQUtRVWre2afQuL quc1/LPiAalOgrNIRUudbU1LLpjZXFZTbiie75Hp+t/1PeTIF7cYQ6zx6FYWKLRGZjd8 xw5h7TU62gBgjpioHSqXb4UGjXLqnCjbG0AGPFCdsRazPP/cRuzG4ZRrCoLOC/AEz4sZ +IYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=B0H4jhAw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n18-20020a170902d2d200b0016360b6cec1si58979plc.230.2022.06.23.09.46.06; Thu, 23 Jun 2022 09:46:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=B0H4jhAw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232027AbiFWQjW (ORCPT + 99 others); Thu, 23 Jun 2022 12:39:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbiFWQjV (ORCPT ); Thu, 23 Jun 2022 12:39:21 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9471E48E62; Thu, 23 Jun 2022 09:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656002359; x=1687538359; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EI+QQ+/jwbwz1xOCAJK7+a2mr8/Kd1EZs7K/UPWhtF4=; b=B0H4jhAwT9yCuhl5RKUj+DgehXTWyTO13dtL+RzviDUf49Eqwagc4mY1 e+6KS7drkldGFz6RD73L6/G5Mi6jFD8u0GrrTx0hon1VzXGA6w/wvuLlr PDGNSzSRPQXgSMDeveGU1Rqt5x7ut5fRpHIYxY7r0JyQ8nlTDa9S2eXWL HBYIy1n90+z7GqSUobqfkCRuefsC2hyDkQdCNzwkawFu3vfKwl2E6OTRm 0/3xis/GfyDVqIUX6CLvGLqnivMc9ZpxuSPRp1H1v+l++btgtn5hIJg0C hgzFtZDX5OquyljzLAe0eBpbvo6klCjvhZFPluvLBE7mkvt6b64BGdz7j A==; X-IronPort-AV: E=McAfee;i="6400,9594,10386"; a="342455606" X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="342455606" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2022 09:39:19 -0700 X-IronPort-AV: E=Sophos;i="5.92,216,1650956400"; d="scan'208";a="834715838" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2022 09:39:11 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1o4PrG-000tDS-Q2; Thu, 23 Jun 2022 19:39:06 +0300 Date: Thu, 23 Jun 2022 19:39:06 +0300 From: Andy Shevchenko To: sascha hauer Cc: Saravana Kannan , Greg Kroah-Hartman , "Rafael J. Wysocki" , Rob Herring , Frank Rowand , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , peng fan , kevin hilman , ulf hansson , len brown , pavel machek , joerg roedel , will deacon , andrew lunn , heiner kallweit , russell king , "david s. miller" , eric dumazet , jakub kicinski , paolo abeni , linus walleij , hideaki yoshifuji , david ahern , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, iommu@lists.linux-foundation.org, netdev@vger.kernel.org, linux-gpio@vger.kernel.org, kernel@pengutronix.de, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1 Message-ID: References: <20220623080344.783549-1-saravanak@google.com> <20220623080344.783549-3-saravanak@google.com> <20220623100421.GY1615@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220623100421.GY1615@pengutronix.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote: > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: ... > I wonder if it wouldn't be a better approach to just probe all devices > and record the device(node) they are waiting on. Then you know that you > don't need to probe them again until the device they are waiting for > is available. There may be no device, but resource. And we become again to the something like deferred probe ugly hack. The real solution is to rework device driver model in the kernel that it will create a graph of dependencies and then simply follow it. But actually it should be more than 1 graph, because there are resources and there are power, clock and resets that may be orthogonal to the higher dependencies (like driver X provides a resource to driver Y). -- With Best Regards, Andy Shevchenko