From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 BCFE937C11C; Mon, 29 Jun 2026 16:23:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782750198; cv=none; b=owM4QpLmrkahAVgrqs5JFoR0lFDzgofa/gDYDf4FfGAl2kBA4Yhmi+6cc7jJpielHtMjgKD2XnX1LWnydAAA/MCxUde0ZbjQPY4NrFRVlNoBqkGuhFqnp62wkL2EooWA61OE8arhfFRKh8KD+Xl4Nl1yxJQ3ltJ2Qz5inM4SDGQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782750198; c=relaxed/simple; bh=60Kkhn1S4xFp8KF1ZAF46WPmvC0pF6KOvaZqQh2Mlf4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b8rWrCByepTNYNmoCV7qBk1LFvloGKC6EPVDI2SPteW94xvNHwo6thFWGbCAjpoc39aK4yfXa6nEDDy166aM1kf4/VR5FdVh2I4DcPMWUZuVdD364SOki6U6QZh54vbVaZDt2Jho4KwMcEZWqWo/HpIVa3egFNi8SCIEDlWRgok= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=XUh5lqOG; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="XUh5lqOG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782750197; x=1814286197; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=60Kkhn1S4xFp8KF1ZAF46WPmvC0pF6KOvaZqQh2Mlf4=; b=XUh5lqOG7e40hPihuH2jgk5xQ/GzbvFEk+m2Al0tfQThrr2AJoRATROb pl1/dHkRS+rxWEqhDjD3t+Bctb0rHUJlluhmSenAhd6AFRvO3vfbiPoYg jTzF3a7OAQrGE6BuiXVI3z6L+5R7H4SJhlSgTrVBFV7XaNsP6/OYrz47U FO2Hr9lD+tzP7MjBON94ne4N0yiuex75fYqeLwDn9AuoyWVohKlzgeZ5O RkcadvbYng+4kTIG/WK2u1XooArWAckObng2uOJu2EMMOLg3PzLY5dAiC 0imZlnO1t55X1xaMVfuqg7vb5sf7i0wj90u+q1z48Y3wH9jhzd8ZKpP8w w==; X-CSE-ConnectionGUID: fMrWV1YGS0WgZZhEI/S5Gw== X-CSE-MsgGUID: bHUpvzGsScON9AZIM1DNmA== X-IronPort-AV: E=McAfee;i="6800,10657,11832"; a="83476036" X-IronPort-AV: E=Sophos;i="6.24,232,1774335600"; d="scan'208";a="83476036" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2026 09:23:15 -0700 X-CSE-ConnectionGUID: tfo8W8J/QcSmRxl6mSfrug== X-CSE-MsgGUID: qa+c086/QemtMiZKLSzfAA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,232,1774335600"; d="scan'208";a="256920930" Received: from kniemiec-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.207]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2026 09:23:02 -0700 Date: Mon, 29 Jun 2026 19:23:00 +0300 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Lee Jones , Mark Brown , Thierry Reding , Sebastian Hesselbarth , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Srinivas Kandagatla , Greg Kroah-Hartman , Vinod Koul , "Rafael J. Wysocki" , Danilo Krummrich , Rob Herring , Saravana Kannan , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Andi Shyti , Joerg Roedel , Will Deacon , Robin Murphy , Doug Berger , Florian Fainelli , Broadcom internal kernel review list , Ulf Hansson , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Matthew Brost , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , Rodrigo Vivi , David Airlie , Simona Vetter , Peter Chen , Paul Cercueil , Bin Liu , Philipp Zabel , Maximilian Luz , Hans de Goede , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Krzysztof Kozlowski , Benjamin Herrenschmidt , brgl@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-sound@vger.kernel.org, driver-core@lists.linux.dev, devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-i2c@vger.kernel.org, iommu@lists.linux.dev, linux-pm@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, linux-mips@vger.kernel.org, platform-driver-x86@vger.kernel.org, stable@vger.kernel.org, Wolfram Sang Subject: Re: [PATCH v2 00/19] driver core: count references of the platform device's fwnode, not OF node Message-ID: References: <20260629-pdev-fwnode-ref-v2-0-8abe2513f96e@oss.qualcomm.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260629-pdev-fwnode-ref-v2-0-8abe2513f96e@oss.qualcomm.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Mon, Jun 29, 2026 at 11:12:23AM +0200, Bartosz Golaszewski wrote: > Platform device core provides helper interfaces for dealing with > dynamically created platform devices. Most users should use > platform_device_register_full() which encapsulates most of the > operations but some modules will want to use the split approach of > calling platform_device_alloc() + platform_device_add() separately for > various reasons. > > With many platform devices now using dynamic software nodes as their > primary firmware nodes and with the platform device interface being > extended to also better cover the use-cases of secondary software nodes, > I believe it makes sense to switch to counting the references of all > kinds of firmware nodes. > > To that end, I identified all users of platform_device_alloc() that also > assign dev.of_node or dev.fwnode manually. I noticed five cases where > the references are not increased as they should (patches 1-5 fix these > users) and provided three new functions in platform_device.h that now > become the preferred interfaces for assigning firmware nodes to dynamic > platform devices (in line with platform_device_add_data(), > platform_device_add_resources(), etc.). The bulk of the patches in this > series are small driver conversions to port all users to going through > the new functions that now encapsulate the refcount logic. With that > done, the final patch seamlessly switches to counting the references of > all firmware node types. > > This effort is prerequisite of removing platform_device_release_full() > and unifying the release path for dynamic platform devices using > unmanaged software nodes. > > Merging strategy: The entire series should go through the driver core > tree, possibly with an immutable branch provided to solve any potential > conflicts though these are rather unlikely. Reviewed-by: Andy Shevchenko for patches 2-4 assuming they will be accompanied with patch 19 at the same time. -- With Best Regards, Andy Shevchenko