From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2E5B9346E5E; Fri, 27 Feb 2026 16:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772210469; cv=none; b=A+71L1tYFrNlABoONSE8HOY1Iq8106hwzXaDKXtbOV+7BJ03wt45rlfrrbYr9WNG/7wTlKBNVI0M88nX9BuwYzvM1nwkeHOPU733kgk11ax045/qszBOUjHWl1PQzKCUVQSxd1zUrCToqQ7eUFeiKyX77512H/KPqhPEUL+4J+g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772210469; c=relaxed/simple; bh=Ra4gGeTukVvl+IUi3kpBx/h8Xrcr5tcq4BLIbbsXf6c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WHlze4E1QJRgwKf1fTjgP47QJPTVdB/DQcbGBgQRZV1NMS1EG3Bbx+rJcSzuWd2b756gPhdJM7zylyR2A9z1xVbWncYgB1vtF+lAkXLL5PF4ktT4oOL1ibKdZTAqNLr/WXmb/ylFGmuIHX14jINS8KDylLpSFEJOvqUHpcXtbQU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kaYFALf4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kaYFALf4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9A9DC116C6; Fri, 27 Feb 2026 16:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772210468; bh=Ra4gGeTukVvl+IUi3kpBx/h8Xrcr5tcq4BLIbbsXf6c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kaYFALf4xSZVQAbA312F7K02ns0zy5kcaOvWHFJNWY9AvATt7pUW+bvMJKbdtChtm tH2uUwehXsL2Hj8fdwwpVCcWuHdDsb63uUFJP2cMF43xNCJTDSxZcHpwvTLSu1U7Sl M2FUvnb6mDY3PWKJMno+e3SWOYvxG8KKG8vxw4MEn6hOq41EUPBH23+RINiw2vhX+e FbHp3qUfZvbZuE+CnrnSZvs5NqaaWkofdWxMYqTtE/Z0RbEfnkD+zmDgc1t+2WJ5x1 9nBJrTX+Zzefz1LyUgn8uO+y6uQ40gkpU5G5jKsZVOMPxB3x2051Wg3WzGAPsaffSQ nrMMZp0t1q53A== Received: from johan by xi.lan with local (Exim 4.98.2) (envelope-from ) id 1vw0tB-000000002TD-2FBk; Fri, 27 Feb 2026 17:40:29 +0100 Date: Fri, 27 Feb 2026 17:40:29 +0100 From: Johan Hovold To: Bartosz Golaszewski Cc: Wolfram Sang , Bartosz Golaszewski , Andi Shyti , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Khalil Blaiech , Asmaa Mnebhi , Jean Delvare , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Andreas =?utf-8?Q?F=C3=A4rber?= , Manivannan Sadhasivam , Mauro Carvalho Chehab , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-actions@lists.infradead.org, linux-media@vger.kernel.org Subject: Re: [PATCH v2 00/13] i2c: add and start using i2c_adapter-specific printk helpers Message-ID: References: <20260223-i2c-printk-helpers-v2-0-13b2a97762af@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-media@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: On Fri, Feb 27, 2026 at 04:42:09PM +0100, Bartosz Golaszewski wrote: > On Fri, Feb 27, 2026 at 11:06 AM Johan Hovold wrote: > > It seems all that is needed is to decouple the struct i2c_adapter from > > the driver data and have core manage the lifetime of the former using > > the reference count of the embedded struct device. > This is a weird pattern you sometimes see where a driver allocates > something and passes the ownership to the subsystem. It's not weird at all, this is the standard way to handle this. We have these things called reference counts for a reason. > This often > causes confusion among driver authors, who logically assume that if > you allocate something, you are responsible for freeing it.Since this > is C and not Rust (where such things are tracked by the compiler), I > strongly believe we should strive to keep ownership consistent: the > driver should free resources it allocated within the bounds of the > lifetime of the device it controls. The subsystem should manage the > data it allocated - in this case the i2c adapter struct device. Drivers are responsible for dropping *their* reference, it doesn't mean that the resource is necessarily freed immediately as someone else may be holding a reference. Anyone surprised by this should not be doing kernel development. > I know there are a lot of places where this is done in the kernel but > let's not introduce new ones. This is a bad pattern. No, it's not. It's literally the standard way of doing this. > But even if you decided this is the way to go, I fail to see how it > would be easier than what I'm trying to do. You would have to modify > *all* I2C bus drivers as opposed to only modifying those that access > the underlying struct device. Or am I missing something? Yes, you have to update the allocation and replace container_of() with dev_get_drvdata() but it's a straight-forward transformation that brings the i2c subsystem more in line with the driver model (unlike whatever it is you're trying to do). Johan