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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 85815C433F5 for ; Tue, 21 Sep 2021 16:36:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D3716115A for ; Tue, 21 Sep 2021 16:36:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229596AbhIUQhg (ORCPT ); Tue, 21 Sep 2021 12:37:36 -0400 Received: from mail-ot1-f49.google.com ([209.85.210.49]:44649 "EHLO mail-ot1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbhIUQhg (ORCPT ); Tue, 21 Sep 2021 12:37:36 -0400 Received: by mail-ot1-f49.google.com with SMTP id h9-20020a9d2f09000000b005453f95356cso2371650otb.11; Tue, 21 Sep 2021 09:36:07 -0700 (PDT) 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=ccB1TqgPixwZOMJX7Se8DC8OOCVRgEfUWG7yso7W/K8=; b=JwSJlRsQP0FOL36BrYuAV0qM15O3vlQxzEwsAe1QrZwD78YOc9R7DIEUDm1t+HbAmn Nh5Baz0AWXA7V6NQ+O2+Ultvc3SQ6c0f5hKJCOb+cVcghFAUoMgAM2GNvLHoAd3v9ATP lLujX3Hrexvzloymd8wPZbdKCrSGc2or5WsyfWHC1zJS5DCL0nODn5KKQ+4rwWSwJlYY 8M+lZjMdaC0IazArYkZ/YLtb+Wx2GFT3C+BfOKr2WZUl+V8ocjuHig2p6fab0BMtN6V+ IdsjY20aG9IDY6pJ5zvsfs0B7wqL13MbY64QAoNsCUFG1elqf87N3zlq6ManBQDzMQ7U 8Bgg== X-Gm-Message-State: AOAM531N/oz+6xON0JAY/2mm6lkmIvjn54b4k8rxq+M9rV1eyZ/hXYgl a0tz+l6Sk7SlmDIiF/nr3iFwQJSchWy/khfoDMQ= X-Google-Smtp-Source: ABdhPJzbsXQsAVFtgj2PK5PgTyv3N2S44oY7GakTwTV8/siQewoWIlssIu5Eft0pmceiGMbOr0Gyxjdz4mh3drq36iA= X-Received: by 2002:a05:6830:165a:: with SMTP id h26mr1735296otr.301.1632242167433; Tue, 21 Sep 2021 09:36:07 -0700 (PDT) MIME-Version: 1.0 References: <20210915170940.617415-1-saravanak@google.com> <20210915170940.617415-3-saravanak@google.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 21 Sep 2021 18:35:56 +0200 Message-ID: Subject: Re: [PATCH v3 2/3] driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD To: Greg Kroah-Hartman Cc: Andrew Lunn , "Rafael J. Wysocki" , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, Sep 21, 2021 at 6:15 PM Greg Kroah-Hartman wrote: > > On Sun, Sep 19, 2021 at 03:16:34AM +0200, Andrew Lunn wrote: > > > > diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h > > > > index 59828516ebaf..9f4ad719bfe3 100644 > > > > --- a/include/linux/fwnode.h > > > > +++ b/include/linux/fwnode.h > > > > @@ -22,10 +22,15 @@ struct device; > > > > * LINKS_ADDED: The fwnode has already be parsed to add fwnode links. > > > > * NOT_DEVICE: The fwnode will never be populated as a struct device. > > > > * INITIALIZED: The hardware corresponding to fwnode has been initialized. > > > > + * NEEDS_CHILD_BOUND_ON_ADD: For this fwnode/device to probe successfully, its > > > > + * driver needs its child devices to be bound with > > > > + * their respective drivers as soon as they are > > > > + * added. > > > > > > The fact that this requires so much comment text here is a clear > > > band-aid indication to me. > > > > This whole patchset is a band aid, but it is for stable, to fix things > > which are currently broken. So we need to answer the question, is a > > bad aid good enough for stable, with the assumption a real fix will > > come along later? > > Fix it properly first, don't worry about stable. > > But what is wrong with this as-is? What needs to be done that is not > happening here that you feels still needs to be addressed? 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?) and that's the source of the underlying issue (self-inflicted circular dependencies that cause devices to wait for a deferred probe forever) which this patchest attempts to avoid by adding an extra flag to the driver core and expecting specific drivers to mark their devices as "special". And that's "until we have a real fix".