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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 53011E6F093 for ; Tue, 23 Dec 2025 14:24:06 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4dbHLr6GN6z2yF1; Wed, 24 Dec 2025 01:24:04 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=172.234.252.31 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1766499844; cv=none; b=da6aXIq8nudZMvNvMtOQM/21IBKj9eZvceqCQC7sb/sB/irqgc8eKFTtWpQ0Yr1BLW1ah0QCm7yylsMI0WyimdFpArLyI+btPvxBs0CxvYgUoIMrJgeLNOAbq6kUMlxiok+uYvzWB5SzxXheO0uPEhlFn0p+SoX79WwPyeC1CruzT3cfdfEt6uhmNz23NY6VPEbVoJRgvLUX7P8gj8zdR8y39hxxOPT68ZwCRpyGlUOeHpUOS08+CeTkkQgK0f/nEHDf8dBXV4OU8XPTgkA17cXThhH+hiAtKfN3iXKXDUg9YdjikbTr3fydGGX+rdmnkATqr/+6KXNWHs55VKQZUw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1766499844; c=relaxed/relaxed; bh=ICmam0m9XXB2moqNxOPa2+pC0cmBSXKD1nCIxD4Mx1U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EA0KiaySDyVBHBWxoGXLAriRMxd+xtHPUjAp0nRjeP4Ds5/T5LnCHlypddLthfW6/BT6KPbl6oa2FE5wPhqjOrTpShusuDBtKPZQOvfiY0P2MuPI7W5JmDTNXGgpUGfTCct32zYwCRnDYGcvuEkVgbjMJf8PO72w2kduz49iH5Pe4r7yBeqrdSu9BOstP7dP+E5AQKHov8B2hOKzYbgM8SmiNCNPpnvFhDaGakXjsixDqvC+sbCNgL93luKEmFYNk96aJ1+P2+YKPTzPdftUV9l6w+XkvYgJfZZrCuAYdOV3hNvTWoGi7F9Pt9N99NZG1zI8iblPqZhRULuQr96vEg== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=T2BqBSVE; dkim-atps=neutral; spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=johan@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=T2BqBSVE; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=johan@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4dbHLr0g77z2xlP for ; Wed, 24 Dec 2025 01:24:04 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 93A0640806; Tue, 23 Dec 2025 14:24:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67551C113D0; Tue, 23 Dec 2025 14:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766499841; bh=LVIPzMudx/3KFt0kpQO0KjKHpoGH1y/OUS9xlATtlVo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=T2BqBSVEvD8+egd2DKh0M7CRaA07nAPvAIGKjOh7dXuv92V35/4lUGDfIix3vJJOH czLv1diFXWHMpuNqZOAhFZChYdIuHY+tDBVVzzZgV5ZlNznGxvTOBj6gQ1HZL+1RRn ciFQUYyqf9ZKutUfnwb+tzowRzQc7rx3Dnlf3nyXGwKLfaDfs8gstN7zHth8wwAEiH gMsEdVuEdYYz49ksnN/blIurAI7UHMrJ/fUJlv9jQWJ0mwlo0EGyuRVKwHnBJsV5vW 0TnFS3XwiqLf4367PRa9pYG5wOO3w6CGtBH57P6Vvf4JrokPtbdx3aetWFutDVt6nM w0H5zVnptbNpA== Received: from johan by xi.lan with local (Exim 4.98.2) (envelope-from ) id 1vY3Is-0000000036w-41rb; Tue, 23 Dec 2025 15:23:59 +0100 Date: Tue, 23 Dec 2025 15:23:58 +0100 From: Johan Hovold To: Bartosz Golaszewski Cc: Wolfram Sang , 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 , 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, Bartosz Golaszewski Subject: Re: [PATCH 00/12] i2c: add and start using i2c_adapter-specific printk helpers Message-ID: References: <20251223-i2c-printk-helpers-v1-0-46a08306afdb@oss.qualcomm.com> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251223-i2c-printk-helpers-v1-0-46a08306afdb@oss.qualcomm.com> On Tue, Dec 23, 2025 at 11:02:22AM +0100, Bartosz Golaszewski wrote: > It's been another year of discussing the object life-time problems at > conferences. I2C is one of the offenders and its problems are more > complex than those of some other subsystems. It seems the revocable[1] > API may make its way into the kernel this year but even with it in > place, I2C won't be able to use it as there's currently nothing to > *revoke*. The struct device is embedded within the i2c_adapter struct > whose lifetime is tied to the provider device being bound to its driver. > > Fixing this won't be fast and easy but nothing's going to happen if we > don't start chipping away at it. The ultimate goal in order to be able > to use an SRCU-based solution (revocable or otherwise) is to convert the > embedded struct device in struct i2c_adapter into an __rcu pointer that > can be *revoked*. To that end we need to hide all dereferences of > adap->dev in drivers. No, this is not the way to do it. You start with designing and showing what the end result will look like *before* you start rewriting world like you are doing here. We should not be making driver code less readable just to address some really niche corner cases like hot pluggable i2c controllers. But in any case, don't get ahead of things by posting changes that we most likely don't want in the end anyway. > This series addresses the usage of adap->dev in device printk() helpers > (dev_err() et al). It introduces a set of i2c-specific helpers and > starts using them across bus drivers. For now just 12 patches but I'll > keep on doing it if these get accepted. Once these get upstream for > v6.20/7.0, we'll be able to also start converting i2c drivers outside of > drivers/i2c/. Same comment applies to the other two series you posted today. Johan