From: Julia Lawall <julia.lawall@lip6.fr>
To: Mark Brown <broonie@kernel.org>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
Fabio Estevam <festevam@gmail.com>,
"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>,
Himangi Saraogi <himangi774@gmail.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Use devm_ functions
Date: Wed, 9 Jul 2014 07:30:40 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.02.1407090727410.2022@localhost6.localdomain6> (raw)
In-Reply-To: <20140708145249.GX30458@sirena.org.uk>
On Tue, 8 Jul 2014, Mark Brown wrote:
> On Tue, Jul 08, 2014 at 10:15:20AM +0200, Julia Lawall wrote:
> > On Tue, 8 Jul 2014, Mark Brown wrote:
>
> > > It should be fairly clear given what they do I'd have thought - the
> > > devm_ functions tie the deallocation of a resource to the unbinding of
> > > a driver from a device so they can only be used to replace things that
> > > get cleaned up in a device model unbind path. There's not usually a
> > > great deal of indirection going on in those.
>
> > It is completely clear what they do. What is not clear is what device
> > libraries are set up to call the freeing functions at what point. For
> > example, I know that that platform drivers are set up for this, but once I
> > tried to find the lines of code that would justify that, but I could not.
> > Perhaps I was not patient enough or missed something.
>
> All devices do this - it's done as part of the driver model core code so
> there is no need for individual buses to do anything.
How should one realize that this does not apply to the original file
under discussion, sound/soc/codecs/sgtl5000.c? The associated structure
is snd_soc_codec_driver. What code could one look for at the call sites
of the probe and remove functions to know that managed memory can be used?
thanks,
julia
next prev parent reply other threads:[~2014-07-09 5:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-06 7:08 Himangi Saraogi
2014-07-07 14:48 ` Mark Brown
2014-07-07 14:58 ` Julia Lawall
2014-07-07 15:20 ` [alsa-devel] " Fabio Estevam
2014-07-07 15:23 ` Julia Lawall
2014-07-07 15:34 ` Lars-Peter Clausen
2014-07-08 8:02 ` Mark Brown
2014-07-08 8:15 ` Julia Lawall
2014-07-08 14:52 ` Mark Brown
2014-07-09 5:30 ` Julia Lawall [this message]
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=alpine.DEB.2.02.1407090727410.2022@localhost6.localdomain6 \
--to=julia.lawall@lip6.fr \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=festevam@gmail.com \
--cc=himangi774@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®