From: Lars-Peter Clausen <lars@metafoo.de>
To: Julia Lawall <julia.lawall@lip6.fr>, Fabio Estevam <festevam@gmail.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Takashi Iwai <tiwai@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Himangi Saraogi <himangi774@gmail.com>
Subject: Re: [PATCH] ASoC: sgtl5000: Use devm_ functions
Date: Mon, 07 Jul 2014 17:34:14 +0200 [thread overview]
Message-ID: <53BABDF6.4090400@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.10.1407071721270.4757@hadrien>
On 07/07/2014 05:23 PM, Julia Lawall wrote:
>
>
> On Mon, 7 Jul 2014, Fabio Estevam wrote:
>
>> On Mon, Jul 7, 2014 at 11:58 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>>
>>> Nevertheless, there is already a call to devm_regulator_bulk_get in
>>> sgtl5000_enable_regulators which calls sgtl5000_replace_vddd_with_ldo
>>> which calls ldo_regulator_register. That call was introduced by
>>>
>>> commit 63e54cd9caa3ce03635810608519e2b37d8bc706
>>> Author: Fabio Estevam <fabio.estevam@freescale.com>
>>> Date: Thu Apr 24 14:13:08 2014 -0300
>>>
>>> It seems that that patch should be reverted?
>>
>> I think so. Russell also reported a kernel oops when unbinding this
>> module, so I will prepare a patch reverting it.
>
> There is documentation about what kinds of devm functions exist, but it is
> too bad that there is no documentation about where they can be used.
> Often there are several levels of function pointers involved, so it can be
> hard to figure out whether they can be used just by looking at the code.
> I have only taken the strategy of using them in kinds of functions where
> someone else has alreadyy figured out that they can be used.
Yes, it is probably a bit underdocumented. The rule of thumb is don't use it
anywhere else except for device probe callbacks (and functions that are only
called from a device probe function) and only for the device that is being
probed. There are probably a couple of instances in the kernel where the
manged resource allocators are used in places where they shouldn't be used.
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: Lars-Peter Clausen <lars@metafoo.de>
To: Julia Lawall <julia.lawall@lip6.fr>, Fabio Estevam <festevam@gmail.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Takashi Iwai <tiwai@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Himangi Saraogi <himangi774@gmail.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Use devm_ functions
Date: Mon, 07 Jul 2014 17:34:14 +0200 [thread overview]
Message-ID: <53BABDF6.4090400@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.10.1407071721270.4757@hadrien>
On 07/07/2014 05:23 PM, Julia Lawall wrote:
>
>
> On Mon, 7 Jul 2014, Fabio Estevam wrote:
>
>> On Mon, Jul 7, 2014 at 11:58 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>>
>>> Nevertheless, there is already a call to devm_regulator_bulk_get in
>>> sgtl5000_enable_regulators which calls sgtl5000_replace_vddd_with_ldo
>>> which calls ldo_regulator_register. That call was introduced by
>>>
>>> commit 63e54cd9caa3ce03635810608519e2b37d8bc706
>>> Author: Fabio Estevam <fabio.estevam@freescale.com>
>>> Date: Thu Apr 24 14:13:08 2014 -0300
>>>
>>> It seems that that patch should be reverted?
>>
>> I think so. Russell also reported a kernel oops when unbinding this
>> module, so I will prepare a patch reverting it.
>
> There is documentation about what kinds of devm functions exist, but it is
> too bad that there is no documentation about where they can be used.
> Often there are several levels of function pointers involved, so it can be
> hard to figure out whether they can be used just by looking at the code.
> I have only taken the strategy of using them in kinds of functions where
> someone else has alreadyy figured out that they can be used.
Yes, it is probably a bit underdocumented. The rule of thumb is don't use it
anywhere else except for device probe callbacks (and functions that are only
called from a device probe function) and only for the device that is being
probed. There are probably a couple of instances in the kernel where the
manged resource allocators are used in places where they shouldn't be used.
- Lars
next prev parent reply other threads:[~2014-07-07 15:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-06 7:08 [PATCH] ASoC: sgtl5000: Use devm_ functions Himangi Saraogi
2014-07-07 14:48 ` Mark Brown
2014-07-07 14:58 ` Julia Lawall
2014-07-07 15:20 ` Fabio Estevam
2014-07-07 15:20 ` [alsa-devel] " Fabio Estevam
2014-07-07 15:23 ` Julia Lawall
2014-07-07 15:34 ` Lars-Peter Clausen [this message]
2014-07-07 15:34 ` Lars-Peter Clausen
2014-07-08 8:02 ` Mark Brown
2014-07-08 8:02 ` [alsa-devel] " Mark Brown
2014-07-08 8:15 ` Julia Lawall
2014-07-08 14:52 ` Mark Brown
2014-07-09 5:30 ` Julia Lawall
2014-07-09 8:01 ` Mark Brown
2014-07-09 8:10 ` Julia Lawall
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=53BABDF6.4090400@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=festevam@gmail.com \
--cc=himangi774@gmail.com \
--cc=julia.lawall@lip6.fr \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/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.