On Fri, Mar 6, 2026 at 4:39 PM Johan Hovold <[email protected]> wrote:
>
> On Wed, Mar 04, 2026 at 01:55:14AM -0800, Bartosz Golaszewski wrote:
> > On Tue, Mar 3, 2026 at 4:57 PM Johan Hovold <[email protected]> wrote:
> > >
> > > On Mon, Mar 02, 2026 at 12:03:19PM -0600, Bartosz Golaszewski wrote:
> > > > On Fri, Feb 27, 2026 at 5:41 PM Johan Hovold <[email protected]> wrote:
> > > > >
> > > > > On Fri, Feb 27, 2026 at 04:42:09PM +0100, Bartosz Golaszewski wrote:
> > > > > > On Fri, Feb 27, 2026 at 11:06 AM Johan Hovold <[email protected]>
> > > > > > 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.
> > > >
> > > > I wouldn't say it's *the* standard way. There are at least several
> > > > different
> > > > ways driver subsystems handle resource ownership. And even so: the fact
> > > > that
> > > > something's done a lot does not make it automatically correct.
> > >
> > > It's the way the driver model works.
> >
> > No, it does not impose any specific pattern to use for subsystems other than
> > requiring each device that's been *initialized* to provide a .release()
> > callback
> > called when the last reference is dropped.
>
> Reference counting is a core part of the driver model and this is
> reflected in the way subsystems manage lifetime.
>
Seems like we've reached an agreement and can stop arguing but you
make it sound here like I'm somehow against reference counting. I've
never said anything like that and here, I just explained how reference
counting works and what it imposes on users.
> > > > I'm advocating for a hard split between the subsystem data
> > > > (reference-counted)
> > > > and driver data (living from probe() until remove()). A logical struct
> > > > device
> > > > managed entirely by the subsystem should live in a separate structure
> > > > than
> > > > driver data and be allocated - and freed - by the subsystem module.
> > >
> > > It doesn't really matter what you think. You can't just go around
> > > making up new subsystem specific rules at your whim. The linux driver
> > > model uses reference counting and that's what developers expect to be
> > > used.
> > >
> >
> > And I've never said that it should not use reference counting. I'm not sure
> > what you're implying here.
>
> 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.
> > > > Let's put aside kernel code for a minute and work with an abstract C
> > > > example,
> > > > where the equivalent of what you're proposing would look like this:
> > > >
> > > > struct bar {
> > > > struct foo foo;
> > > > ...
> > > > };
> > > >
> > > > struct bar *bar = malloc(sizeof(*bar));
> > > >
> > > > ret = foo_register(&bar->foo);
> > > >
> > > > And the corresponding free() lives who knows where because
> > > > foo_register()
> > > > automagically introduces reference counting (nevermind the need to
> > > > calculate
> > > > where bar is in relations to foo).
> > >
> > > No, that's not what I'm suggesting here, but it would be compatible with
> > > the driver model (ever heard of struct device which works exactly like
> > > this?).
> >
> > I know how struct device works. I'm pointing out that this is a bad API
> > (just
> > to be absolutely clear: not the reference counting of struct device itself
> > but
> > using it in a way tha looks like it's not refcounted but becomes so after an
> > API call) because it's confusing. I'm not buying the argument that if it
> > confuses you then you should not be doing kernel development because it's
> > not
> > the goal of API design to make it as complex and confusing as possible -
> > quite
> > the contrary. And it *is* confusing given the amount of misuse present. I've
> > heard Greg KH say on multiple occasions during his talks that we try to
> > offload
> > complex code to subsystems so that drivers can remain fairly simple. I agree
> > with that.
>
> 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.
Bartosz
