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 97E7AC433EF for ; Tue, 21 Sep 2021 17:56:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78E0461131 for ; Tue, 21 Sep 2021 17:56:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232019AbhIUR6F (ORCPT ); Tue, 21 Sep 2021 13:58:05 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:52636 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232045AbhIUR5v (ORCPT ); Tue, 21 Sep 2021 13:57:51 -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=WzMEbwZn/Z6/zvDtk3KGoyjHTKqZpd6tQKW8PKGbAzE=; b=aOncr7W3PxHOWmrkANHYEEQqdx xIz8Wfe54f9/eDgqxOyW0GTLeFKnOpacmt5Bq/CblT/26RN0JCZbmYtkZC+jTyeseksXVLQFRUXFq cFGFX905tLsZuSKBfcH4ovWrZYqNib8fcCzWEtn1yJb/LaXRB1mTNfch4cTF/GRDTYrA=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mSk00-007f8J-HX; Tue, 21 Sep 2021 19:56:08 +0200 Date: Tue, 21 Sep 2021 19:56:08 +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 > The existing code attempts to "enforce" device links where the > supplier is a direct ancestor of the consumer (e.g. its parent), which > is questionable by itself (why do that?) In this case, we have an Ethernet switch as the parent device. It registers an interrupt controller, to the interrupt subsystem. It also registers an MDIO controller to the MDIO subsystem. The MDIO subsystem finds the Ethernet PHYs on the MDIO bus, and registers the PHYs to the PHY subsystem. Device tree is then used to glue all the parts together. The PHY has an interrupt output which is connected to the interrupt controller, and a standard DT property is used to connect the two. The MACs in the switch are connected to the PHYs, and standard DT properties are used to connect them together. So we have a loop. But the driver model does not have a problem with this, at least not until fw_devlink came along. As soon as a resource is registered with a subsystem, it can be used. Where as fw_devlink seems to assume a resource cannot be used until the driver providing it completes probe. Now, we could ignore all these subsystems, re-invent the wheels inside the switch driver, and then not have suppliers and consumers at all, it is all internal. But that seems like a bad idea, more wheels, more bugs. So for me, the real fix is that fw_devlink learns that resources are available as soon as they are registered, not when the provider device completes probe. Andrew