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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 411A9C433FE for ; Tue, 21 Sep 2021 19:50:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 26E5E60E09 for ; Tue, 21 Sep 2021 19:50:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233478AbhIUTwX (ORCPT ); Tue, 21 Sep 2021 15:52:23 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:52762 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbhIUTwU (ORCPT ); Tue, 21 Sep 2021 15:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=O9CGNGP4t9JA5zm1++wpSRXbAdCGi6yyb4Rj0rHTtFU=; b=EiwGD6Cn+SsHEE9zYFgNhbdBRd tHGS5foxfsqOLuhg2hx6m08wrscsYqJZ2SR+pK/T3dpo+lhGtVldmboqHkRtmMEnGhrTrHFMdpxVB Jf8zPGmaPRHV4yozBGlDCYGAuOKJNOJlvaONXow/OvmHt2jDqlwpn8X38zt3GthqGE30=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mSlmq-007g8m-VV; Tue, 21 Sep 2021 21:50:40 +0200 Date: Tue, 21 Sep 2021 21:50:40 +0200 From: Andrew Lunn To: "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Saravana Kannan , Heiner Kallweit , Russell King , "David S. Miller" , Jakub Kicinski , Len Brown , Geert Uytterhoeven , Vladimir Oltean , "Cc: Android Kernel" , Linux Kernel Mailing List , netdev , ACPI Devel Maling List Subject: Re: [PATCH v3 2/3] driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD Message-ID: References: <20210915170940.617415-1-saravanak@google.com> <20210915170940.617415-3-saravanak@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > It works at a device level, so it doesn't know about resources. The > only information it has is of the "this device may depend on that > other device" type and it uses that information to figure out a usable > probe ordering for drivers. And that simplification is the problem. A phandle does not point to a device, it points to a resource of a device. It should really be doing what the driver would do, follow the phandle to the resource and see if it exists yet. If it does not exist then yes it can defer the probe. If the resource does exist, allow the driver to probe. > Also if the probe has already started, it may still return > -EPROBE_DEFER at any time in theory Sure it can, and does. And any driver which is not broken will unregister its resources on the error path. And that causes users of the resources to release them. It all nicely unravels, and then tries again later. This all works, it is what these drivers do. > However, making children wait for their parents to complete probing is > generally artificial, especially in the cases when the children are > registered by the parent's driver. So waiting should be an exception > in these cases, not a rule. So are you suggesting that fw_devlink core needs to change, recognise the dependency on a parent, and allow the probe? Works for me. Gets us back to before fw_devlink. Andrew