Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp5121853iog; Wed, 22 Jun 2022 12:28:18 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tEzpg2kceTci/DQioxpwEw7fCx/Mv45TvodZvet9z84OD8/aFgUuh8Z5zhqeK+v6usAI48 X-Received: by 2002:a05:6a00:2410:b0:522:9837:581f with SMTP id z16-20020a056a00241000b005229837581fmr36693327pfh.11.1655926098676; Wed, 22 Jun 2022 12:28:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655926098; cv=none; d=google.com; s=arc-20160816; b=O9rOhiCq2n60BBhDE/I/YDUOszd/ApE30mVdA7h0jMOCPP+VnT54Jo3cG/c1q57ClG WNKpdaRtMX32QuQ6GCVVHirkis2/wb9SC54sC+GqYt0hoBynTRTocWsizvANaSzeZHmh daQjMkkTvhoW1Zt/Z2msEkpODJn3DBXGrBjlxEJFTFvjq9FIDf/iJ8pOGCLBlfY3Aau5 yxckwvwgeoZ1pS+LUL5Rj7kTbSDaNxi4UNHp/BtKb47Dt/eeTwmimxFBKKoTGDEFVdmR vbDqbF35+yBZ0lvc/GHXjZBjf36GmIwF0WQLCxeQpieeUu05V4Ek3j0B2RBJB7DgM0g6 DKOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=m2EKhR0TRoyufPiu9Flo4efSG9iVQ7Sr7NIfxXnG//E=; b=Byjbe7Q15pNhXFK9wFvSm/2Bcx2n5jjXIZEHbjGXZjuDKvvLhqyv75zOwOL4yUVJ9i M4yxDnnLDGPvZD5EJfXROc+eV8JeNph/QVS2NfbL2ie2RZgkDpPSsQw8DKVzrlbiFBsA dHOhxrHQ8YDIUk4Auf2ZhYecU3xkrIM/6eBhOKzrGoGKOpmT7b2MEW+HqUAd008cbuyf TDYt9NYDWHBqUl9BHTFD/hy0Q3LHjyQtscGdoOa2WhmyEwcrXw3HhluLI496PcikBBTb ae0BJiD0rplO0cgcIGBqkfkEOt4ekjYg/6l9RieDG/bCJn88lQCP/17IYBH0pKz58+Yk XG1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=q0iBpeFz; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z9-20020a170902d54900b0015d168a0c7fsi15539585plf.94.2022.06.22.12.28.05; Wed, 22 Jun 2022 12:28: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=@google.com header.s=20210112 header.b=q0iBpeFz; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377211AbiFVTKM (ORCPT + 99 others); Wed, 22 Jun 2022 15:10:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231178AbiFVTKK (ORCPT ); Wed, 22 Jun 2022 15:10:10 -0400 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4850615806 for ; Wed, 22 Jun 2022 12:10:08 -0700 (PDT) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-317710edb9dso172784277b3.0 for ; Wed, 22 Jun 2022 12:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m2EKhR0TRoyufPiu9Flo4efSG9iVQ7Sr7NIfxXnG//E=; b=q0iBpeFzXmVjuV9RJ2U0tO6ECKKIgXqLxhTrd/XuqGhMkas+He99laUPoyLdnfoNFL +PttCvM62NPrGDH6bN6Tam5nPc4Jt6Lhqq9iRLcdZDXmODHt/VANxFARtdqBpIOWNqbl AatF7ctiFGf72C+0OC82zliefxVYa8dtkAaYmnq0JCPtTgfz1cWUVQ87m5452KZkW/cW SPNNeBKYphGmdKaYImVx82HxgMYh2fon8Z8I1JzFAAU0CLZraMDpT8R9qd8YGH1YLF5l z+/MLbNzdLViy90RdBW0wFmvw6BnGUFs9HZsF90abo3WhbF4Ja8pDA24KBOpYxV847T2 I7ig== 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=m2EKhR0TRoyufPiu9Flo4efSG9iVQ7Sr7NIfxXnG//E=; b=lOIACkrqM7cpDIyQ8GSYHHtzdcsxT01D38YkcEiw2JW1FCw1s6bLLV2Bn81EJplntI w/8q1XW0Mr6UNKo7w1A5SDV7B8BvGrgkWrW2Di47M0PyXY3bGZ3NMO7VjP1W0KCkhJvK VrxGh8VyNtu4obERIMlidbf1Ig4RYJOE+857kCni2Uh5wIhuVQNxudN/+1LbcUtLAh7Z AKH9DgbyQ7oGycE7I2TUtDAhVeD8l8j6bFsOCXysigcnJR5183wRmF30efU0nPcCRCWY EW508TzlUBEPQ+BrAQx12lcWg5nd/L2vBmye5R+wRpmLA7IOTmyy1wfQSzkCGVf9UszI LNoA== X-Gm-Message-State: AJIora9V1MPHCYiocyOA6FBoHxh9lIkKozpGSFFmhyibenQHXd6S6iV1 APSMIHx51Ez3JQCY55fSYkVPzhR9af6X3sJnnnWFvA== X-Received: by 2002:a0d:eace:0:b0:317:87ac:b3a8 with SMTP id t197-20020a0deace000000b0031787acb3a8mr6074480ywe.126.1655925007151; Wed, 22 Jun 2022 12:10:07 -0700 (PDT) MIME-Version: 1.0 References: <20220601070707.3946847-1-saravanak@google.com> <20220601070707.3946847-2-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Wed, 22 Jun 2022 12:09:31 -0700 Message-ID: Subject: Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state() To: Tony Lindgren Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , 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, Geert Uytterhoeven Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > Hi, > > * Saravana Kannan [220621 19:29]: > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > > > > > Hi, > > > > > > * Saravana Kannan [700101 02:00]: > > > > Now that fw_devlink=on by default and fw_devlink supports > > > > "power-domains" property, the execution will never get to the point > > > > where driver_deferred_probe_check_state() is called before the supplier > > > > has probed successfully or before deferred probe timeout has expired. > > > > > > > > So, delete the call and replace it with -ENODEV. > > > > > > Looks like this causes omaps to not boot in Linux next. > > > > Can you please point me to an example DTS I could use for debugging > > this? I'm assuming you are leaving fw_devlink=on and not turning it > > off or putting it in permissive mode. > > Sure, this seems to happen at least with simple-pm-bus as the top > level interconnect with a configured power-domains property: > > $ git grep -A10 "ocp {" arch/arm/boot/dts/*.dtsi | grep -B3 -A4 simple-pm-bus Thanks for the example. I generally start looking from dts (not dtsi) files in case there are some DT property override/additions after the dtsi files are included in the dts file. But I'll assume for now that's not the case. If there's a specific dts file for a board I can look from that'd be helpful to rule out those kinds of issues. For now, I looked at arch/arm/boot/dts/omap4.dtsi. > > This issue is no directly related fw_devlink. It is a side effect of > removing driver_deferred_probe_check_state(). We no longer return > -EPROBE_DEFER at the end of driver_deferred_probe_check_state(). Yes, I understand the issue. But driver_deferred_probe_check_state() was deleted because fw_devlink=on should have short circuited the probe attempt with an -EPROBE_DEFER before reaching the bus/driver probe function and hitting this -ENOENT failure. That's why I was asking the other questions. > > > On platform_probe() genpd_get_from_provider() returns > > > -ENOENT. > > > > This error is with the series I assume? > > On the first probe genpd_get_from_provider() will return -ENOENT in > both cases. The list is empty on the first probe and there are no > genpd providers at this point. > > Earlier with driver_deferred_probe_check_state(), the initial -ENOENT > ends up getting changed to -EPROBE_DEFER at the end of > driver_deferred_probe_check_state(), we are now missing that. Right, I was aware -ENOENT would be returned if we got this far. But the point of this series is that you shouldn't have gotten that far before your pm domain device is ready. Hence my questions from the earlier reply. Can I get answers to rest of my questions in the first reply please? That should help us figure out why fw_devlink let us get this far. Summarize them here to make it easy: * Are you running with fw_devlink=on? * Is the"ti,omap4-prm-inst"/"ti,omap-prm-inst" built-in in this case? * If it's not built-in, can you please try deferred_probe_timeout=0 and deferred_probe_timeout=30 and see if either one of them help? * Can I get the output of "ls -d supplier:*" and "cat supplier:*/status" output from the sysfs dir for the ocp device without this series where it boots properly. Thanks, Saravana