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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 AD7DFC0018C for ; Mon, 7 Dec 2020 19:57:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8AA7C21D7F for ; Mon, 7 Dec 2020 19:57:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726075AbgLGT4y (ORCPT ); Mon, 7 Dec 2020 14:56:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:35770 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbgLGT4y (ORCPT ); Mon, 7 Dec 2020 14:56:54 -0500 Date: Mon, 7 Dec 2020 21:56:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607370973; bh=yPs9QDsuXZBj0AnHJQPLKk5uozke+DFy1FCuNPHFJoo=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=CJywbZ6F2J2n4eSInxwY89uD9zCi+tJPVViTO3691+MbLs7gpFDUgsHVlISgnxaB7 c6Q6Gc5kLSk58ing3N17b3+fDpNAMQNcEZ0S6sBLEcJL1qggNTKcDJAaVRHUZJ7vsn IHEfwaOhAARTvu3xTRQhd3uK9sEWHcVC9XY5ot+uwbbn5OfWMOHrZGpShI+dseMtFb uhdRD/+roWdSMfEkiKVnPn4Zy4BvB1jRTFcgHWd8Ncx9goUulpxSHxOczempw61nn7 MBvtpw3qDK0eSJ7jesv6ALXVKqqjoiF3kFJ04FAQZaTwKNjNtYaJG/+9sV46cHkFZQ vSDpsnS4WsP/A== From: Leon Romanovsky To: Saravana Kannan Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Greg Kroah-Hartman , Ard Biesheuvel , Rob Herring , Frank Rowand , Marc Zyngier , Thomas Gleixner , Tomi Valkeinen , Laurent Pinchart , Grygorii Strashko , Android Kernel Team , ACPI Devel Maling List , LKML , linux-efi , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Subject: Re: [PATCH v2 08/17] driver core: Add fwnode link support Message-ID: <20201207195607.GG693271@unreal> References: <20201121020232.908850-1-saravanak@google.com> <20201121020232.908850-9-saravanak@google.com> <20201206074840.GB687065@unreal> 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-acpi@vger.kernel.org On Mon, Dec 07, 2020 at 11:25:03AM -0800, Saravana Kannan wrote: > On Sat, Dec 5, 2020 at 11:48 PM Leon Romanovsky wrote: > > > > On Fri, Nov 20, 2020 at 06:02:23PM -0800, Saravana Kannan wrote: > > > Add support for creating supplier-consumer links between fwnodes. It is > > > intended for internal use the driver core and generic firmware support > > > code (eg. Device Tree, ACPI), so it is simple by design and the API > > > provided is limited. > > > > > > Signed-off-by: Saravana Kannan > > > --- > > > drivers/base/core.c | 98 ++++++++++++++++++++++++++++++++++++++++++ > > > drivers/of/dynamic.c | 1 + > > > include/linux/fwnode.h | 14 ++++++ > > > 3 files changed, 113 insertions(+) > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > index 401fa7e3505c..e2b246a44d1a 100644 > > > --- a/drivers/base/core.c > > > +++ b/drivers/base/core.c > > > @@ -50,6 +50,104 @@ static LIST_HEAD(wait_for_suppliers); > > > static DEFINE_MUTEX(wfs_lock); > > > static LIST_HEAD(deferred_sync); > > > static unsigned int defer_sync_state_count = 1; > > > +static DEFINE_MUTEX(fwnode_link_lock); > > > + > > > +/** > > > + * fwnode_link_add - Create a link between two fwnode_handles. > > > + * @con: Consumer end of the link. > > > + * @sup: Supplier end of the link. > > > + * > > > + * Create a fwnode link between fwnode handles @con and @sup. The fwnode link > > > + * represents the detail that the firmware lists @sup fwnode as supplying a > > > + * resource to @con. > > > + * > > > + * The driver core will use the fwnode link to create a device link between the > > > + * two device objects corresponding to @con and @sup when they are created. The > > > + * driver core will automatically delete the fwnode link between @con and @sup > > > + * after doing that. > > > + * > > > + * Attempts to create duplicate links between the same pair of fwnode handles > > > + * are ignored and there is no reference counting. > > > > Sorry to ask, but why is that? > > Isn't this a programmer error? > > No, not a programmer error. > > One firmware node can point to the same supplier many times. For > example, the consumer can be using multiple clocks from the same > supplier clock controller. In the context of fw_devlink, there's no > reason to keep track of each clock dependency separately because we'll > be creating only one device link from fwnode link. So multiple fwnode > link attempts between the same two devices are just treated as one > instance of dependency. I hope that clarifies things. Yes, thanks. > > -Saravana