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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 70967C433EF for ; Mon, 16 May 2022 13:49:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1743540B5E; Mon, 16 May 2022 13:49:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2zrbbMjHAJV; Mon, 16 May 2022 13:49:23 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id ED56D40283; Mon, 16 May 2022 13:49:22 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id C34B6C0039; Mon, 16 May 2022 13:49:22 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5E96EC002D for ; Mon, 16 May 2022 13:49:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 59D4F402C9 for ; Mon, 16 May 2022 13:49:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=kernel.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 X68YyR_NnJ6T for ; Mon, 16 May 2022 13:49:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by smtp4.osuosl.org (Postfix) with ESMTPS id 11E6C408DA for ; Mon, 16 May 2022 13:49:19 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9D96361403 for ; Mon, 16 May 2022 13:49:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 838D0C3411E for ; Mon, 16 May 2022 13:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652708957; bh=Z1XATC9uFabr/cJUUJjAm1EmvJAVsCV0ZzQGqjrP+zA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Z+GBZ3HlMnS5S30k9vIXcOgsZZ9s2NTFIiE1HhvkWvPHy1bjZ00LgZTijr0M8KGmr STXCnHM85F+TIeIvpPTpG9lJp1vA2Dm/Llye5llcupfFc3DrhRP+8bTa1WAu66TGeA j/DsK4XK2TUXXSmd4/EUmmfxHNWV6eBhb+iN8YrybsUGbavpI8spHpzmskqUGIvWti bNesjElLh27daCKCjj83GRo5P9odygoLEUSbXWLeoVpn5VGXa0/BMtY5u5Z+8Zq3Yz Dxa7iXnhmdyqASNVfz96SqOorM96PaPLHL4R1RBqW+eHT3/L6di0va0g0SOjYdn1qn w4pbcCKlq/PAQ== Received: by mail-ed1-f42.google.com with SMTP id j28so4370553eda.13 for ; Mon, 16 May 2022 06:49:17 -0700 (PDT) X-Gm-Message-State: AOAM5312Fb0FFdDoPdSFKjuXcquIuvYYGCmvvPtxmzzmiJhuonMoEwlX Y60nx3caVRKRmzuDOBPAkZcuZjqFLtCizMI/QA== X-Google-Smtp-Source: ABdhPJzHJM/87Poo6lwZbFjNTMwh5WnjP4kK2zZNYqsvkYOJYJ8e9tfRTKjYaXJU+LODgXXZ2NtySTJTP3q9QRcur+c= X-Received: by 2002:a05:6402:35c7:b0:427:d231:3740 with SMTP id z7-20020a05640235c700b00427d2313740mr13373747edc.40.1652708955614; Mon, 16 May 2022 06:49:15 -0700 (PDT) MIME-Version: 1.0 References: <20220429220933.1350374-1-saravanak@google.com> In-Reply-To: From: Rob Herring Date: Mon, 16 May 2022 08:49:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration To: Saravana Kannan Cc: Ulf Hansson , Android Kernel Team , Linux Doc Mailing List , "Rafael J. Wysocki" , Greg Kroah-Hartman , Linus Walleij , Jonathan Corbet , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Paul Kocialkowski , Kevin Hilman , Linux IOMMU , Mark Brown , Geert Uytterhoeven , Pavel Machek , "open list:GPIO SUBSYSTEM" , "open list:THERMAL" , Thierry Reding , Will Deacon 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 Fri, May 13, 2022 at 12:26 PM Saravana Kannan wrote: > > On Fri, May 13, 2022 at 6:58 AM Rob Herring wrote: > > > > On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan wrote: > > > > > > The deferred probe timer that's used for this currently starts at > > > late_initcall and runs for driver_deferred_probe_timeout seconds. The > > > assumption being that all available drivers would be loaded and > > > registered before the timer expires. This means, the > > > driver_deferred_probe_timeout has to be pretty large for it to cover the > > > worst case. But if we set the default value for it to cover the worst > > > case, it would significantly slow down the average case. For this > > > reason, the default value is set to 0. > > > > > > Also, with CONFIG_MODULES=y and the current default values of > > > driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing > > > drivers will cause their consumer devices to always defer their probes. > > > This is because device links created by fw_devlink defer the probe even > > > before the consumer driver's probe() is called. > > > > > > Instead of a fixed timeout, if we extend an unexpired deferred probe > > > timer on every successful driver registration, with the expectation more > > > modules would be loaded in the near future, then the default value of > > > driver_deferred_probe_timeout only needs to be as long as the worst case > > > time difference between two consecutive module loads. > > > > > > So let's implement that and set the default value to 10 seconds when > > > CONFIG_MODULES=y. > > > > We had to revert a non-zero timeout before (issue with NFS root IIRC). > > Does fw_devlink=on somehow fix that? > > If it's the one where ip autoconfig was timing out, then John Stultz > fixed it by fixing wait_for_device_probe(). > https://lore.kernel.org/all/20200422203245.83244-4-john.stultz@linaro.org/ Yeah, that was it. Acked-by: Rob Herring _______________________________________________ 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 949EBC433EF for ; Mon, 16 May 2022 13:51:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244685AbiEPNve (ORCPT ); Mon, 16 May 2022 09:51:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240567AbiEPNuS (ORCPT ); Mon, 16 May 2022 09:50:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F9F13A5DA; Mon, 16 May 2022 06:49:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A62F9B81216; Mon, 16 May 2022 13:49:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 618BAC3411A; Mon, 16 May 2022 13:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652708957; bh=Z1XATC9uFabr/cJUUJjAm1EmvJAVsCV0ZzQGqjrP+zA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Z+GBZ3HlMnS5S30k9vIXcOgsZZ9s2NTFIiE1HhvkWvPHy1bjZ00LgZTijr0M8KGmr STXCnHM85F+TIeIvpPTpG9lJp1vA2Dm/Llye5llcupfFc3DrhRP+8bTa1WAu66TGeA j/DsK4XK2TUXXSmd4/EUmmfxHNWV6eBhb+iN8YrybsUGbavpI8spHpzmskqUGIvWti bNesjElLh27daCKCjj83GRo5P9odygoLEUSbXWLeoVpn5VGXa0/BMtY5u5Z+8Zq3Yz Dxa7iXnhmdyqASNVfz96SqOorM96PaPLHL4R1RBqW+eHT3/L6di0va0g0SOjYdn1qn w4pbcCKlq/PAQ== Received: by mail-ed1-f51.google.com with SMTP id y21so18436156edo.2; Mon, 16 May 2022 06:49:17 -0700 (PDT) X-Gm-Message-State: AOAM533ImvKH7a3KRENUQ2DkkfvR+4Qv5+fQI6y0XwDSBU7tzQraS5D/ fUWvmZXYcs/aGL6LLJerI/dYOGPh3kc0naJ5Jw== X-Google-Smtp-Source: ABdhPJzHJM/87Poo6lwZbFjNTMwh5WnjP4kK2zZNYqsvkYOJYJ8e9tfRTKjYaXJU+LODgXXZ2NtySTJTP3q9QRcur+c= X-Received: by 2002:a05:6402:35c7:b0:427:d231:3740 with SMTP id z7-20020a05640235c700b00427d2313740mr13373747edc.40.1652708955614; Mon, 16 May 2022 06:49:15 -0700 (PDT) MIME-Version: 1.0 References: <20220429220933.1350374-1-saravanak@google.com> In-Reply-To: From: Rob Herring Date: Mon, 16 May 2022 08:49:03 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration To: Saravana Kannan Cc: Jonathan Corbet , Greg Kroah-Hartman , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linus Walleij , Will Deacon , Ulf Hansson , Kevin Hilman , Thierry Reding , Mark Brown , Pavel Machek , Geert Uytterhoeven , Yoshihiro Shimoda , Paul Kocialkowski , "open list:GPIO SUBSYSTEM" , "open list:THERMAL" , Linux IOMMU , Android Kernel Team , Linux Doc Mailing List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, May 13, 2022 at 12:26 PM Saravana Kannan wrote: > > On Fri, May 13, 2022 at 6:58 AM Rob Herring wrote: > > > > On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan wrote: > > > > > > The deferred probe timer that's used for this currently starts at > > > late_initcall and runs for driver_deferred_probe_timeout seconds. The > > > assumption being that all available drivers would be loaded and > > > registered before the timer expires. This means, the > > > driver_deferred_probe_timeout has to be pretty large for it to cover the > > > worst case. But if we set the default value for it to cover the worst > > > case, it would significantly slow down the average case. For this > > > reason, the default value is set to 0. > > > > > > Also, with CONFIG_MODULES=y and the current default values of > > > driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing > > > drivers will cause their consumer devices to always defer their probes. > > > This is because device links created by fw_devlink defer the probe even > > > before the consumer driver's probe() is called. > > > > > > Instead of a fixed timeout, if we extend an unexpired deferred probe > > > timer on every successful driver registration, with the expectation more > > > modules would be loaded in the near future, then the default value of > > > driver_deferred_probe_timeout only needs to be as long as the worst case > > > time difference between two consecutive module loads. > > > > > > So let's implement that and set the default value to 10 seconds when > > > CONFIG_MODULES=y. > > > > We had to revert a non-zero timeout before (issue with NFS root IIRC). > > Does fw_devlink=on somehow fix that? > > If it's the one where ip autoconfig was timing out, then John Stultz > fixed it by fixing wait_for_device_probe(). > https://lore.kernel.org/all/20200422203245.83244-4-john.stultz@linaro.org/ Yeah, that was it. Acked-by: Rob Herring