linux-kernel - Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Use devm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1407090727410.2022@localhost6.localdomain6>
Date:	Wed, 9 Jul 2014 07:30:40 +0200 (CEST)
From:	Julia Lawall <julia.lawall@...6.fr>
To:	Mark Brown <broonie@...nel.org>
cc:	Julia Lawall <julia.lawall@...6.fr>,
	Fabio Estevam <festevam@...il.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Takashi Iwai <tiwai@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Himangi Saraogi <himangi774@...il.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Use devm_ functions



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
--
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/