From: Mark Brown <broonie@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
patches@opensource.cirrus.com
Subject: Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs
Date: Tue, 27 Nov 2018 13:30:33 +0000 [thread overview]
Message-ID: <20181127133033.GC3206@sirena.org.uk> (raw)
In-Reply-To: <CACRpkdZKJGFmYFKBHdiayRsA2ona2zWfJ+xckJxD1UBsj39=sA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Mon, Nov 26, 2018 at 10:53:40PM +0100, Linus Walleij wrote:
> The managed resources pretty much assume
> that you tie resources to the device model and let kref inside the
> kobject in struct device do all refcounting and that essentially
> collides with the refcounting inside the regulator core, they both
> want to control this now.
If a driver is handing ownership of an object over to something else
then devm is always unsuitable.
> I suspect maybe the lesser evil is to bite the bullet, invent
> gpiod_get_from_of_node() which is the missing API (we currently
> only have devm_gpiod_get_from_of_node()) and simply
> fix up the converted regulator drivers to avoid devm_*
> retrieveal in the same manner as wm8994 (the already
> queued patch). This will make the regulator core own the
> refcounting as it does today.
You're always going to need unmanaged versions of functions for use with
things like this I think.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-11-27 13:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20181122173037epcas1p39fb96bb168427d58a74a085f42a0ba84@epcas1p3.samsung.com>
2018-11-22 17:30 ` [PATCH 1/3] regulator: wm8994: Revert back to using devres Charles Keepax
2018-11-22 17:30 ` [PATCH 2/3] regulator: Only free GPIOs if the core requested them Charles Keepax
2018-11-22 22:25 ` Linus Walleij
2018-11-23 9:24 ` Marek Szyprowski
2018-11-23 14:25 ` Mark Brown
2018-11-30 22:15 ` Linus Walleij
2018-11-22 17:30 ` [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs Charles Keepax
2018-11-23 9:25 ` Marek Szyprowski
2018-11-23 9:40 ` Linus Walleij
2018-11-23 10:57 ` Charles Keepax
2018-11-23 13:25 ` Mark Brown
2018-11-26 13:00 ` Charles Keepax
2018-11-26 14:09 ` Mark Brown
2018-11-26 14:30 ` Charles Keepax
2018-11-26 14:54 ` Mark Brown
2018-11-26 16:53 ` Charles Keepax
2018-11-26 21:53 ` Linus Walleij
2018-11-27 9:18 ` Charles Keepax
2018-11-27 10:50 ` Linus Walleij
2018-11-27 13:30 ` Mark Brown [this message]
2018-11-23 9:24 ` [PATCH 1/3] regulator: wm8994: Revert back to using devres Marek Szyprowski
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=20181127133033.GC3206@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=patches@opensource.cirrus.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.