From: Johan Hovold <johan@kernel•org>
To: Bartosz Golaszewski <brgl@kernel•org>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering•com>,
"Bartosz Golaszewski" <bartosz.golaszewski@oss•qualcomm.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>,
"Mauro Carvalho Chehab" <mchehab@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, linux-media@vger•kernel.org
Subject: Re: [PATCH v2 00/13] i2c: add and start using i2c_adapter-specific printk helpers
Date: Mon, 9 Mar 2026 11:31:13 +0100 [thread overview]
Message-ID: <aa6hcT7MROZqxF1j@hovoldconsulting.com> (raw)
In-Reply-To: <CAMRc=Mcv+ZMGaC_MD8WRH113rDuuxdiZXuW5JAXWga1V7vM_ng@mail.gmail.com>
On Fri, Mar 06, 2026 at 06:34:43PM +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 6, 2026 at 4:39 PM Johan Hovold <johan@kernel•org> wrote:
> > You have posted changes that will prevent driver from accessing the
> > struct device of core i2c structures. This is unexpected, non-idiomatic
> > and subsystem specific and therefore a bad idea.
>
> That's not true, the changes provide a helper to that end.
That was supposed to say "prevent drivers from accessing the struct
device *directly*".
> > Again, this is a core feature of the driver model. You can't just ignore
> > it and come up with random ways to work around just because you disagree
> > with design decisions that were made 25 years ago.
>
> It absolutely *can* be done differently. There's nothing that imposes
> a certain API design on susbsystems. If you design the subsystem code
> well, provider drivers don't need more than one reference (taken in
> probe(), released in remove(), for instance via the
> register()/unregister() pair) so the counting can be hidden within the
> subsystems that control them.
Yes, there is nothing preventing you from diverting from the idiomatic
way of doing things. But my point is that that's not a good idea.
Johan
next prev parent reply other threads:[~2026-03-09 10:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 8:59 [PATCH v2 00/13] i2c: add and start using i2c_adapter-specific printk helpers Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 01/13] media: saa7134: rename i2c_dbg() to saa7134_i2c_dbg() Bartosz Golaszewski
2026-03-16 8:29 ` Hans Verkuil
2026-03-16 8:38 ` Wolfram Sang
2026-03-16 8:42 ` Hans Verkuil
2026-02-23 8:59 ` [PATCH v2 02/13] i2c: add i2c_adapter-specific printk helpers Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 03/13] i2c: sun6i-p2wi: use " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 04/13] i2c: mlxbf: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 05/13] i2c: isch: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 06/13] i2c: ali1535: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 07/13] i2c: scmi: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 08/13] i2c: ali15x3: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 09/13] i2c: powermac: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 10/13] i2c: owl: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 11/13] i2c: nforce2: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 12/13] i2c: amd756: " Bartosz Golaszewski
2026-02-23 8:59 ` [PATCH v2 13/13] i2c: piix4: " Bartosz Golaszewski
2026-02-26 20:21 ` [PATCH v2 00/13] i2c: add and start using " Wolfram Sang
2026-02-27 8:38 ` Bartosz Golaszewski
2026-02-27 8:54 ` Wolfram Sang
2026-02-27 8:58 ` Johan Hovold
2026-02-27 9:08 ` Wolfram Sang
2026-02-27 10:05 ` Johan Hovold
2026-02-27 15:42 ` Bartosz Golaszewski
2026-02-27 16:40 ` Johan Hovold
2026-03-02 18:03 ` Bartosz Golaszewski
2026-03-03 15:57 ` Johan Hovold
2026-03-04 9:55 ` Bartosz Golaszewski
2026-03-04 11:07 ` Wolfram Sang
2026-03-06 15:50 ` Johan Hovold
2026-03-06 17:20 ` Bartosz Golaszewski
2026-03-09 11:51 ` Wolfram Sang
2026-03-06 15:39 ` Johan Hovold
2026-03-06 17:34 ` Bartosz Golaszewski
2026-03-09 10:31 ` Johan Hovold [this message]
2026-03-10 9:28 ` Bartosz Golaszewski
2026-03-17 10:28 ` Johan Hovold
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=aa6hcT7MROZqxF1j@hovoldconsulting.com \
--to=johan@kernel$(echo .)org \
--cc=afaerber@suse$(echo .)de \
--cc=andi.shyti@kernel$(echo .)org \
--cc=asmaa@nvidia$(echo .)com \
--cc=bartosz.golaszewski@oss$(echo .)qualcomm.com \
--cc=brgl@kernel$(echo .)org \
--cc=chleroy@kernel$(echo .)org \
--cc=jdelvare@suse$(echo .)com \
--cc=jernej.skrabec@gmail$(echo .)com \
--cc=kblaiech@nvidia$(echo .)com \
--cc=linux-actions@lists$(echo .)infradead.org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-i2c@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-media@vger$(echo .)kernel.org \
--cc=linux-sunxi@lists$(echo .)linux.dev \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=maddy@linux$(echo .)ibm.com \
--cc=mani@kernel$(echo .)org \
--cc=mchehab@kernel$(echo .)org \
--cc=mpe@ellerman$(echo .)id.au \
--cc=npiggin@gmail$(echo .)com \
--cc=samuel@sholland$(echo .)org \
--cc=wens@kernel$(echo .)org \
--cc=wsa+renesas@sang-engineering$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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