From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEBB9145B36; Fri, 12 Apr 2024 14:54:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712933657; cv=none; b=aku2LWtGaiOA4OMlfCqO+sOtYv6HLeGG37hziF2iMjGH5mMu6axqJvED27eh1Ln+Sv/Ur7GTm41TsokzEXQ7/3aHjJGvHre8lqbi6VNhMnW4TYPup6UpiO1NADK6sz07XB1t3H6UNfE1/HmM1NP3880lr4ElOnrGxCOKl3VMs9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712933657; c=relaxed/simple; bh=in6s0CayvsuzQeqaiNyjVowzPqlZrAQVR/B3bv4tggk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m4BU6hTSz0iODNBmRxJzExBXNEXjrWG6ihQeOuEaivSuUOY9fBsUfAeqf5cwVM2ka8Bo6Lr18b7Sy8vDM1kYGZ93iSF1fy7wwuDyfVi9cpEwnXmkHEtNSnX81/D1/eJK2ABSmqB42fth85RB4pcSPWi2qembERwJ4wtjYieDCnE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PZ+7TOIl; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PZ+7TOIl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712933656; x=1744469656; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=in6s0CayvsuzQeqaiNyjVowzPqlZrAQVR/B3bv4tggk=; b=PZ+7TOIl3IMkcVwvngqbigo3519xjbImb4htVZ5I/Ae5SO2umBr1U6cZ ZoFxJMp7/lvDcoit1zc/mkZxZQfo94VDm09Ct0CrK8nof70cAcvPnZwKK 1JC4jwA3j8vw9fjKW3ZsfUpaFON6m2s5371j85RR4Lx78TrfdWf2DX79F wv9dPSnuo3KTGXIjTcKJYCrH4KIthUS+qqKUEiRqGppfV97CYQVUe9ZzH FfPNpuj6n3pRu2OBBVT9H6ozBsk5Ksap3v8ROVsMFPAHnYmktRQXBvvk/ ZsBBEqDCcu8jWcocQ+RpCZp0pCn917AhYFkfF9jGQnhmpCSVonjp0fcKh A==; X-CSE-ConnectionGUID: EtnHBXRSSiGavd3eXC5xmw== X-CSE-MsgGUID: ZzY2kez7SpGHngCwWB3tDQ== X-IronPort-AV: E=McAfee;i="6600,9927,11042"; a="8249778" X-IronPort-AV: E=Sophos;i="6.07,196,1708416000"; d="scan'208";a="8249778" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2024 07:54:15 -0700 X-CSE-ConnectionGUID: 6fFYUjUFQBanhxX5HwRLfw== X-CSE-MsgGUID: 167iCC+KQkS2JkX98wu9pQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,196,1708416000"; d="scan'208";a="21238596" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.54]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2024 07:54:09 -0700 Received: from andy by smile with local (Exim 4.97) (envelope-from ) id 1rvHtF-00000003eRB-20ZW; Fri, 12 Apr 2024 17:28:29 +0300 Date: Fri, 12 Apr 2024 17:28:29 +0300 From: Andy Shevchenko To: Rob Herring Cc: Saravana Kannan , Herve Codina , Greg Kroah-Hartman , "Rafael J. Wysocki" , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Wolfram Sang , Mark Brown , Len Brown , Daniel Scally , Heikki Krogerus , Sakari Ailus , Geert Uytterhoeven , kernel-team@android.com, Wolfram Sang , linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-spi@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v3 2/2] of: dynamic: Fix overlayed devices not probing because of fw_devlink Message-ID: References: <20240411235623.1260061-1-saravanak@google.com> <20240411235623.1260061-3-saravanak@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Fri, Apr 12, 2024 at 07:54:32AM -0500, Rob Herring wrote: > On Thu, Apr 11, 2024 at 6:56 PM Saravana Kannan wrote: > I think it is better to not have this wrapper. We want it to be clear > when we're acquiring a ref. I know get_device() does that, but I have > to look up what get_dev_from_fwnode() does exactly. > > Side note: I didn't know fwnode has a ptr to the struct device. I > wonder if we can kill off of_find_device_by_node() using that. That's > for platform devices though. I don't like the idea because we already have a big design issue with fwnode that is used in struct device. Ideally, fwnode has to be a node in the linked list, head of which is provided by the user (struct device, for example). When it's done, it will be easy to handle. Have you read the comment in the struct fwnode_handle definition? -- With Best Regards, Andy Shevchenko