linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Andi Shyti" <andi.shyti@kernel.org>,
	"Chen-Yu Tsai" <wens@kernel.org>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Khalil Blaiech" <kblaiech@nvidia.com>,
	"Asmaa Mnebhi" <asmaa@nvidia.com>,
	"Jean Delvare" <jdelvare@suse.com>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	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" <brgl@kernel.org>
Subject: Re: [PATCH 00/12] i2c: add and start using i2c_adapter-specific printk helpers
Date: Tue, 23 Dec 2025 15:23:58 +0100	[thread overview]
Message-ID: <aUql_tZisfH8E1bq@hovoldconsulting.com> (raw)
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


  parent reply	other threads:[~2025-12-23 14:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-23 10:02 [PATCH 00/12] i2c: add and start using i2c_adapter-specific printk helpers Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 01/12] i2c: add " Bartosz Golaszewski
2025-12-25 18:30   ` kernel test robot
2025-12-25 19:33   ` kernel test robot
2025-12-23 10:02 ` [PATCH 02/12] i2c: sun6i-p2wi: use " Bartosz Golaszewski
2025-12-23 11:04   ` Chen-Yu Tsai
2025-12-23 10:02 ` [PATCH 03/12] i2c: mlxbf: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 04/12] i2c: isch: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 05/12] i2c: ali1535: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 06/12] i2c: scmi: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 07/12] i2c: ali15x3: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 08/12] i2c: powermac: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 09/12] i2c: owl: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 10/12] i2c: nforce2: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 11/12] i2c: amd756: " Bartosz Golaszewski
2025-12-23 10:02 ` [PATCH 12/12] i2c: piix4: " Bartosz Golaszewski
2025-12-23 14:23 ` Johan Hovold [this message]
2025-12-23 15:11   ` [PATCH 00/12] i2c: add and start using " Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aUql_tZisfH8E1bq@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=afaerber@suse.de \
    --cc=andi.shyti@kernel.org \
    --cc=asmaa@nvidia.com \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brgl@kernel.org \
    --cc=chleroy@kernel.org \
    --cc=jdelvare@suse.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=kblaiech@nvidia.com \
    --cc=linux-actions@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mani@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=samuel@sholland.org \
    --cc=wens@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).