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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DF1CEC38142 for ; Fri, 27 Jan 2023 09:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bbQdwTz56XDwNMqzyn1ajEoyZR22C1DSwjzhMLaYR4A=; b=GALB/q8NiFHnyx y7x8OltxJwnJcMbUujxk8wd5kVsiQMdqny2qPFmZ1eXb4ORInG49OonmhY42wQXIIRMtbKk/ndU5i dmlvKrFCVfiUi+fmWajVum0zSr6/L3oNJkPFROSqABEV7D7NWBHRIG+QF0KXSPMAPFm64gFuFM7bD Rg5lHQrXqtbQKUl13nX5zNzrIzWVVWxsF0aPTdqXjJJEBqbvyfEOw+uwptWOwsdskCrqsgEW8QH6B AFFRy66BlUvYeigzB7EBdMwVPMve3JXlFXzCVEAsUfSq0Ljqpt+syqg58h80C+4NiXI9a9gSl9dac lCTewAXvzdUjjASEYX8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLKyo-00DdjP-It; Fri, 27 Jan 2023 09:25:07 +0000 Received: from mga18.intel.com ([134.134.136.126]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLKwA-00DcXO-Jn for linux-arm-kernel@lists.infradead.org; Fri, 27 Jan 2023 09:22:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674811342; x=1706347342; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=7L/axu+05lgRV1B7k83rTdiEnNvSos+SJ26ckkwltXU=; b=ML5YkUOkGP7AGcsMWPeYQty32e2OJsQiWtiMc/IjUHStSNjgeywdKWN5 BckzU9UuJzqBbs4gIjivGgEUO2PDFVPQ2e3oPhRhZGvsv+QdGj2+2+e46 +MVtNeBEJSq5WMTeGky/LvWUxgaZclRiBfdOJFRRaiD0qFXpYV9lsTxGd 5Zqoxg4UOVy1dDq0mUV697UwFDHzTYVgSG1b7RAPuxgXbym0haKkD4EgW KLx/ChjImnQAH8Zyn5dXiGQeRsqdWoaTyzgxNnK4Wqp4ubKLfTL9/beE+ LYvOoNDnOOG9ZcLJpWi/anHL36c9w5CSNOublG8BcAgqi/V+ABOAsaJ+y w==; X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="310672038" X-IronPort-AV: E=Sophos;i="5.97,250,1669104000"; d="scan'208";a="310672038" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 01:22:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10602"; a="656541888" X-IronPort-AV: E=Sophos;i="5.97,250,1669104000"; d="scan'208";a="656541888" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 27 Jan 2023 01:22:00 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pLKvk-00FtO1-00; Fri, 27 Jan 2023 11:21:56 +0200 Date: Fri, 27 Jan 2023 11:21:55 +0200 From: Andy Shevchenko To: Saravana Kannan Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , Cristian Marussi , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rob Herring , Frank Rowand , Geert Uytterhoeven , Magnus Damm , Len Brown , Daniel Scally , Heikki Krogerus , Sakari Ailus , Tony Lindgren , Linux Kernel Functional Testing , Naresh Kamboju , Abel Vesa , Alexander Stein , Geert Uytterhoeven , John Stultz , Doug Anderson , Guenter Roeck , Dmitry Baryshkov , Maxim Kiselev , Maxim Kochetkov , Miquel Raynal , Luca Weiss , Colin Foster , Martin Kepplinger , Jean-Philippe Brucker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v2 01/11] driver core: fw_devlink: Don't purge child fwnode's consumer links Message-ID: References: <20230127001141.407071-1-saravanak@google.com> <20230127001141.407071-2-saravanak@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230127001141.407071-2-saravanak@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230127_012222_820986_BC51CEB0 X-CRM114-Status: GOOD ( 25.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 26, 2023 at 04:11:28PM -0800, Saravana Kannan wrote: > When a device X is bound successfully to a driver, if it has a child > firmware node Y that doesn't have a struct device created by then, we > delete fwnode links where the child firmware node Y is the supplier. We > did this to avoid blocking the consumers of the child firmware node Y > from deferring probe indefinitely. > > While that a step in the right direction, it's better to make the > consumers of the child firmware node Y to be consumers of the device X > because device X is probably implementing whatever functionality is > represented by child firmware node Y. By doing this, we capture the > device dependencies more accurately and ensure better > probe/suspend/resume ordering. ... > static unsigned int defer_sync_state_count = 1; > static DEFINE_MUTEX(fwnode_link_lock); > static bool fw_devlink_is_permissive(void); > +static void __fw_devlink_link_to_consumers(struct device *dev); > static bool fw_devlink_drv_reg_done; > static bool fw_devlink_best_effort; I'm wondering if may avoid adding more forward declarations... Perhaps it's a sign that devlink code should be split to its own module? ... > -int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > +static int __fwnode_link_add(struct fwnode_handle *con, > + struct fwnode_handle *sup) I believe we tolerate a bit longer lines, so you may still have it on a single line. ... > +int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > +{ > + int ret = 0; Redundant assignment. > + mutex_lock(&fwnode_link_lock); > + ret = __fwnode_link_add(con, sup); > + mutex_unlock(&fwnode_link_lock); > return ret; > } ... > if (dev->fwnode && dev->fwnode->dev == dev) { You may have above something like fwnode = dev_fwnode(dev); if (fwnode && fwnode->dev == dev) { > struct fwnode_handle *child; > fwnode_links_purge_suppliers(dev->fwnode); > + mutex_lock(&fwnode_link_lock); > fwnode_for_each_available_child_node(dev->fwnode, child) > - fw_devlink_purge_absent_suppliers(child); > + __fw_devlink_pickup_dangling_consumers(child, > + dev->fwnode); __fw_devlink_pickup_dangling_consumers(child, fwnode); > + __fw_devlink_link_to_consumers(dev); > + mutex_unlock(&fwnode_link_lock); > } -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel