Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1101641rwb; Wed, 16 Nov 2022 12:05:20 -0800 (PST) X-Google-Smtp-Source: AA0mqf6n4NI2jAee6BguQbIbTGUlXHF1/wDFuXmU0lcm35Yxaj8WYZ5Uc+blMfFys2Rm8SAWSSTX X-Received: by 2002:a17:907:f99:b0:7aa:57c3:3f26 with SMTP id kb25-20020a1709070f9900b007aa57c33f26mr18783769ejc.195.1668629120592; Wed, 16 Nov 2022 12:05:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668629120; cv=none; d=google.com; s=arc-20160816; b=Dr3N8WfLIfarFKvYp9JmzPCsOqwe6Mls8cTFLzCUTSBy65kdDM/30TkoyEJxsO+Piy ibnRHG/SllG3TXz+dmiJvWCc6ItzhcYDycQ1rV9mQnnQHwHuu1jnN2Wi6GBPZ08xfAnS 1Lp3AOTFlfLBERw94sDl6tBFgMCeH0Q7jtPMBJbRV+YjgxUhYLQpKTSWwmmKvpqydCGb OTxx44cNddF0jQfcWhrtZC+x+9b1aQrA7rx5YOWeSQDAT8M2vwGIAReYHz4GRrKr830h Pjp1GxWpWnFa45blLYOwFU3DgAPQPMvYk9jRo2BY54npYSs6i+d+x02Cr2ZQ6FgTfxq9 COyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=lfLRij7l12paP94g1Vl4KJDeYdRaQzDak4ajvEFazKc=; b=RwfQUt5jlaOexswceEVoPKxAa89UwTTihX2F3O4ntvsT81ka5ST0dKdM91lRTQpCDj NmCB0eU0dV2WjGjQ3wie02dSEpTP2UKB+jl25B2r4d81GbgZhKhUBkrbe3hyW8zU0Ot5 qplsIwF3zLVir9EDEDDoMO/eQst6Uo3Sg3+JSJtKp4FfU4C57+khs0cXbVqseLWQmA0X 9GM3D0TqOtRGI5sPYRcQ+q+LV8dN44+Cbwt5riYPxzQu78uoR1sVhGrkQF8r+gEh14Gw vOldCxyfh+MDe9U7m1q5lse+RoSCF/Ce/8dpGbb2lKFfvoqQHbELaAG9GOI4f+x2YBtt M2nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=THjI7SIW; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i5-20020a1709064fc500b007316843d58bsi15276506ejw.925.2022.11.16.12.04.50; Wed, 16 Nov 2022 12:05:20 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=THjI7SIW; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233485AbiKPTQJ (ORCPT + 90 others); Wed, 16 Nov 2022 14:16:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbiKPTQG (ORCPT ); Wed, 16 Nov 2022 14:16:06 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F1DA53EF6 for ; Wed, 16 Nov 2022 11:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668626111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lfLRij7l12paP94g1Vl4KJDeYdRaQzDak4ajvEFazKc=; b=THjI7SIWzny/P5MhSD1J/Uuz66DnmZ3gfurHSZzNaDuCbAUQjfr8PFA88oKU9OHu9PJsjw kdE4hXsKNy2zD21dVuc0oOchCF/N/lD9n/fYvRlYeQOi8bMcVaGAt71UfHD9Ytn9Vjb7i+ lfOePDomOONDR8KGgH/aRC5gk1AvBlA= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-209-dw6OgLidOLeczJD8-Hrdfg-1; Wed, 16 Nov 2022 14:15:10 -0500 X-MC-Unique: dw6OgLidOLeczJD8-Hrdfg-1 Received: by mail-ot1-f71.google.com with SMTP id 33-20020a9d0124000000b0066adf5218b2so9291605otu.10 for ; Wed, 16 Nov 2022 11:15:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lfLRij7l12paP94g1Vl4KJDeYdRaQzDak4ajvEFazKc=; b=65SfmMEowv7mu9WywQyRpBVqOTuzpNspsAPQqMjIahrPnPrk6yFYZOOwZ1Kd7hEPua hD4MmbGD2oh2mbu5dudGBFgAUOE66fK3Mzv41Bh3aZFS9jegZj/NWURD+VIod0lr/QQA wpInV98cABlhDYN4/F8Mnr2CPM9a0esjduaOt51x4sapdE3knTulp6VQ58L6RRMzRQm8 L2vQX906e38+zsoPFr1f3yKZxnPklw7vwVii+IxWW9N/VVWwl/ZmFaDVNmSm+lkUcJ2R 3pP1d4fc975C4r4NfC1Kmv5znQfnF0Fo6kkKolFAkfvGxwiAEXBCzvqIPa4lTMAhxJdf TfYg== X-Gm-Message-State: ANoB5pluYsBkQUMA8dYSGkZZYw6uzo3eMI2KRHROYev74xY+T1ued0jx rR/jJWp0grDGkxlxj3UZzVtenXNbff/+WIKVDnLcLCxQPbVfIPvge5Ghf7fGYKniqem7g9nyY6Z eJ13Uq+GebVwaN4B4ZKfTaszu X-Received: by 2002:a05:6808:64e:b0:359:cfaf:7129 with SMTP id z14-20020a056808064e00b00359cfaf7129mr2441145oih.138.1668626109277; Wed, 16 Nov 2022 11:15:09 -0800 (PST) X-Received: by 2002:a05:6808:64e:b0:359:cfaf:7129 with SMTP id z14-20020a056808064e00b00359cfaf7129mr2441135oih.138.1668626109041; Wed, 16 Nov 2022 11:15:09 -0800 (PST) Received: from halaney-x13s ([2600:1700:1ff0:d0e0::41]) by smtp.gmail.com with ESMTPSA id u64-20020a4a2143000000b0049f9731ae1esm1771053oou.41.2022.11.16.11.15.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 11:15:08 -0800 (PST) Date: Wed, 16 Nov 2022 13:15:05 -0600 From: Andrew Halaney To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Douglas Anderson , Saravana Kannan , Daniel Vetter , linux-arm-msm@vger.kernel.org, John Stultz , Peter Robinson , Steev Klimaszewski , Greg Kroah-Hartman , Enric Balletbo i Serra , Bjorn Andersson , Brian Masney , Rob Herring Subject: Re: [PATCH v2 4/4] driver core: Disable driver deferred probe timeout by default Message-ID: <20221116191505.x6ruzruc3yprp7sx@halaney-x13s> References: <20221116115348.517599-1-javierm@redhat.com> <20221116120236.520017-1-javierm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221116120236.520017-1-javierm@redhat.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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 Wed, Nov 16, 2022 at 01:02:36PM +0100, Javier Martinez Canillas wrote: > The driver_deferred_probe_timeout value has a long history. It was first > set to -1 when was introduced by commit 25b4e70dcce9 ("driver core: allow > stopping deferred probe after init"), meaning that the driver core would > defer the probe forever unless a subsystem would opt-in by checking if the > initcalls where done using the driver_deferred_probe_check_state() helper, > or if a timeout was explicitly set with a "deferred_probe_timeout" param. This or statement here sounds like you either opt-in, or the timeout affects you (at least that's how I read it). A subsystem has to opt-in to get either result by using driver_deferred_probe_check_state()! > > Only the power domain, IOMMU and MDIO subsystems currently opt-in to check > if the initcalls have completed with driver_deferred_probe_check_state(). > > Commit c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() > logic") then changed the driver_deferred_probe_check_state() helper logic, > to take into account whether modules have been enabled or not and also to > return -EPROBE_DEFER if the probe deferred timeout work was still running. > > Then in commit e2cec7d68537 ("driver core: Set deferred_probe_timeout to a > longer default if CONFIG_MODULES is set"), the timeout was increased to 30 > seconds if modules are enabled. Because seems that some of the subsystems > that were opt-in to not return -EPROBE_DEFER after the initcall where done s/where/were/ > could still have dependencies whose drivers were built as a module. > > This commit did a fundamental change to how probe deferral worked though, > since now the default was not to attempt probing for drivers indefinitely > but instead to timeout after 30 seconds, unless a different timeout is set > using the "deferred_probe_timeout" command line parameter. > > The behavior was changed even more with commit ce68929f07de ("driver core: > Revert default driver_deferred_probe_timeout value to 0"), since the value > was set to 0 by default. Meaning that the probe deferral would be disabled > after the initcalls where done. Unless a timeout was set in the cmdline. > > Notice that the commit said that it was reverting the default value to 0, > but this was never 0. The default was -1 at the beginning and then changed > to 30 in a later commit. > > This default value of 0 was reverted again by commit f516d01b9df2 ("Revert > "driver core: Set default deferred_probe_timeout back to 0."") and set to > 10 seconds instead. Which was still less than the 30 seconds that was set > at some point, to allow systems with drivers built as modules and loaded > later by user-land to probe drivers that were still in the deferred list. > > The 10 seconds timeout isn't enough in some cases, for example the Fedora > kernel builds as much drivers as possible as modules. And this leads to an > Snapdragon SC7180 based HP X2 Chromebook to not have display, due the DRM > driver failing to probe if CONFIG_ARM_SMMU=y and CONFIG_SC_GPUCC_7180=m. > > So let's change the default again to -1 as it was at the beginning. That's > how probe deferral always worked. The kernel should try to avoid guessing > when it should be safe to give up on deferred drivers to be probed. > > The reason why the default "deferred_probe_timeout" was changed from -1 to > the other values was to allow drivers that have only optional dependencies > to probe even if the suppliers are not available. > > But now there is a "fw_devlink.timeout" parameter to timeout the links and > allow drivers to probe even when the dependencies are not present. Let's > set the default for that timeout to 10 seconds, to give the same behaviour > as expected by these driver with optional device links. > > Signed-off-by: Javier Martinez Canillas This sounds like a reasonable solution to me: Acked-by: Andrew Halaney > --- > > Changes in v2: > - Mention in the commit messsage the specific machine and drivers that > are affected by the issue (Greg). > - Double check the commit message for accuracy (John). > - Add a second workqueue to timeout the devlink enforcing and allow > drivers to probe even without their optional dependencies available. > > drivers/base/dd.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > index ea448df94d24..5f18cd497850 100644 > --- a/drivers/base/dd.c > +++ b/drivers/base/dd.c > @@ -256,12 +256,8 @@ static int deferred_devs_show(struct seq_file *s, void *data) > } > DEFINE_SHOW_ATTRIBUTE(deferred_devs); > > -#ifdef CONFIG_MODULES > -static int driver_deferred_probe_timeout = 10; > -#else > -static int driver_deferred_probe_timeout; > -#endif > -static int fw_devlink_timeout = -1; > +static int driver_deferred_probe_timeout = -1; > +static int fw_devlink_timeout = 10; > > static int __init deferred_probe_timeout_setup(char *str) > { > -- > 2.38.1 >