[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200903142127.26182.david-b@pacbell.net>
Date: Sat, 14 Mar 2009 21:27:26 -0700
From: David Brownell <david-b@...bell.net>
To: Mark Brown <broonie@...ena.org.uk>
Cc: Liam Girdwood <lrg@...mlogic.co.uk>,
lkml <linux-kernel@...r.kernel.org>,
OMAP <linux-omap@...r.kernel.org>
Subject: Re: [patch 2.6.29-rc7 regulator-next] regulator: refcount fixes
On Saturday 14 March 2009, Mark Brown wrote:
> Looking at things from the point of view of the consumer I just don't
> find that it makes any difference since as far as the consumer is
> concerned it's all opaque objects manipulated via an API.
These put()/get() calls are not refcount calls. They're
what might be called alloc()/free() calls instead.
> foo = foo_get(dev, name);
The normal idiom is
bar = foo_get(foo)
which just increments a refcount. Then if "bar" were handed
to something else ("baz") right here, and "baz" needed to keep a
copy of that reference, it would be expected to grab its own
refcount via foo_get(bar), and later release via foo_put(bar).
> foo_enable(foo);
> foo_disable(foo);
> foo_put(foo);
Until "baz" called foo_put(bar), that reference would still be
usable. But ... regulator_put(foo) does a kfree, it's not
just updating refcounts.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists