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 Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 034B6C43334 for ; Thu, 23 Jun 2022 17:22:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7C40D42527; Thu, 23 Jun 2022 17:22:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7C40D42527 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICBM68moUQel; Thu, 23 Jun 2022 17:22:47 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id E5428424F5; Thu, 23 Jun 2022 17:22:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E5428424F5 Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9FC1C0039; Thu, 23 Jun 2022 17:22:46 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C05DEC002D for ; Thu, 23 Jun 2022 17:22:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9391060B05 for ; Thu, 23 Jun 2022 17:22:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9391060B05 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_aGYjpwUkQT for ; Thu, 23 Jun 2022 17:22:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E40C960A9D Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by smtp3.osuosl.org (Postfix) with ESMTPS id E40C960A9D for ; Thu, 23 Jun 2022 17:22:44 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id i7so150092ybe.11 for ; Thu, 23 Jun 2022 10:22:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QzySQcL24GEYxXoJc82RsC0c2BhGDpj4k4DOkY9xrS0=; b=NIfJ+QBjXIp/hvGTsTNjkwTIbssODiHgeq3YKSbFMelS9hXW1v1uJYyxgvhp7en0W9 0Uy9yIzcntEBj45tM6pRN9WmBf7/yOf9h3GYnoh8yWDzAo7JjfPjVduMJqzUrOBRY1Lh o4j0flZVzBde0ZEaSkmVkI9edlkxk/tPQuIcftZyttPrt7RuQHH8BzCYA/vT9iBP3qIn 3F45/xch0Y1m4C1hg5z73iwwuAq4rTkaQeciz9RcvtsueskZ3s2Cap9c61PlPUQw8UNW NbXirjGmzcDdwE84Y71SkFZuiI2eQ2/yQ+OB/oWnv1b75gz4KxNdlkwD0PBgrBes8Ss6 3Vcg== X-Gm-Message-State: AJIora8y7CGQ0OMGB3Ga/tpGDZEI3ekw3xFqMHRz5+KhY5eNKw163Ea1 hDhkk281Jb8Ip9W1kRX/8yP5ozWfo+UuD88nSeU= X-Google-Smtp-Source: AGRyM1vlR+G3ynXaQ+rOy9k5hMBPieUkqHmh9QChAgpgAs7VODTNv3swHyAeiQ4sYXpc/+o+j6AcUnENYWlbLbMDoS8= X-Received: by 2002:a05:6902:1141:b0:669:3f2a:c6bb with SMTP id p1-20020a056902114100b006693f2ac6bbmr10551083ybu.365.1656004963776; Thu, 23 Jun 2022 10:22:43 -0700 (PDT) MIME-Version: 1.0 References: <20220623080344.783549-1-saravanak@google.com> <20220623080344.783549-3-saravanak@google.com> <20220623100421.GY1615@pengutronix.de> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 23 Jun 2022 19:22:32 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1 To: Andy Shevchenko Cc: andrew lunn , peng fan , Heikki Krogerus , "Rafael J. Wysocki" , linus walleij , ulf hansson , eric dumazet , pavel machek , will deacon , sascha hauer , Saravana Kannan , kevin hilman , Frank Rowand , russell king , ACPI Devel Maling List , jakub kicinski , paolo abeni , "Cc: Android Kernel" , Len Brown , len brown , Sascha Hauer , Linux PM , "open list:GPIO SUBSYSTEM" , Rob Herring , hideaki yoshifuji , Greg Kroah-Hartman , david ahern , Linux Kernel Mailing List , Daniel Scally , "open list:AMD IOMMU \(AMD-VI\)" , Sakari Ailus , netdev , "david s. miller" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , heiner kallweit X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, Jun 23, 2022 at 6:39 PM Andy Shevchenko wrote: > > 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). There is one graph, or it wouldn't be possible to shut down the system orderly. The problem is that this graph is generally dynamic, especially during system init, and following dependencies in transient states is generally hard. Device links allow the already known dependencies to be recorded and taken into account later, so we already have a graph for those. The unknown dependencies obviously cannot be used for creating a graph of any sort, though, and here we are in the business of guessing what the unknown dependencies may be IIUC. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C76D1C43334 for ; Thu, 23 Jun 2022 18:17:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236758AbiFWSQz (ORCPT ); Thu, 23 Jun 2022 14:16:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236778AbiFWSQg (ORCPT ); Thu, 23 Jun 2022 14:16:36 -0400 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A06B25DF35; Thu, 23 Jun 2022 10:22:44 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id u9so219638ybq.3; Thu, 23 Jun 2022 10:22:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QzySQcL24GEYxXoJc82RsC0c2BhGDpj4k4DOkY9xrS0=; b=EA9QO/BQU35unKlx6FbkmO5/gPZgmhdZgoPbgFC6ffBaA9VooOcc0BRLOU39xQVF5u oCQBgnLZoYCyzVFx7UIoZDv9EQX6dTDh4Rgq+u/q19CS8XJPMXCMbOzr/wvoN8a+JJEX n+dfZAHFvr9Z2RZB/XL9H/844Gm0m5QrkH2LAFi2Edlk952DPNVmyNwpHEo0zDEgttH/ rh/cvmHqXZv3hq9jo2fuvJWXhzak+RaB6VSTOM7wwmz9+vUeiVyRW9eHndW02UhCqfSG zciotoAlnfZ/mSNthxa1kW0Dqxa+aopjSNJbaqDfEBibkC99qnrZLbTwsBuiL8Fdv7Fv iS+g== X-Gm-Message-State: AJIora8hjXpF/oHWli0PfCcSNJcgeSauYfwdswID16swkOdq45TP3wEt BttImfYagxBaZOWbKf9rxILcTsZ7uMFC93gcX1A= X-Google-Smtp-Source: AGRyM1vlR+G3ynXaQ+rOy9k5hMBPieUkqHmh9QChAgpgAs7VODTNv3swHyAeiQ4sYXpc/+o+j6AcUnENYWlbLbMDoS8= X-Received: by 2002:a05:6902:1141:b0:669:3f2a:c6bb with SMTP id p1-20020a056902114100b006693f2ac6bbmr10551083ybu.365.1656004963776; Thu, 23 Jun 2022 10:22:43 -0700 (PDT) MIME-Version: 1.0 References: <20220623080344.783549-1-saravanak@google.com> <20220623080344.783549-3-saravanak@google.com> <20220623100421.GY1615@pengutronix.de> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 23 Jun 2022 19:22:32 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1 To: Andy Shevchenko Cc: sascha hauer , 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 , "Cc: Android Kernel" , Linux Kernel Mailing List , Linux PM , "open list:AMD IOMMU (AMD-VI)" , netdev , "open list:GPIO SUBSYSTEM" , Sascha Hauer , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , ACPI Devel Maling List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, Jun 23, 2022 at 6:39 PM Andy Shevchenko wrote: > > 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). There is one graph, or it wouldn't be possible to shut down the system orderly. The problem is that this graph is generally dynamic, especially during system init, and following dependencies in transient states is generally hard. Device links allow the already known dependencies to be recorded and taken into account later, so we already have a graph for those. The unknown dependencies obviously cannot be used for creating a graph of any sort, though, and here we are in the business of guessing what the unknown dependencies may be IIUC.