From: Scott Wood <scottwood@freescale.com>
To: Rivera Jose-B46482 <German.Rivera@freescale.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"agraf@suse.de" <agraf@suse.de>, "arnd@arndb.de" <arnd@arndb.de>,
Sharma Bhupesh-B45370 <bhupesh.sharma@freescale.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yoder Stuart-B08248 <stuart.yoder@freescale.com>,
Erez Nir-RM30794 <nir.erez@freescale.com>,
"katz Itai-RM05202" <itai.katz@freescale.com>,
Hamciuc Bogdan-BHAMCIU1 <bhamciu1@freescale.com>,
Marginean Alexandru-R89243 <R89243@freescale.com>,
Schmitt Richard-B43082 <richard.schmitt@freescale.com>
Subject: Re: [PATCH 1/7] staging: fsl-mc: MC bus IRQ support
Date: Tue, 5 May 2015 14:42:29 -0500 [thread overview]
Message-ID: <1430854949.16357.240.camel@freescale.com> (raw)
In-Reply-To: <DM2PR0301MB1309A6F411B54A6A1626E78EFED10@DM2PR0301MB1309.namprd03.prod.outlook.com>
On Tue, 2015-05-05 at 11:08 -0500, Rivera Jose-B46482 wrote:
> > > > to read what "goto error;" does. The error handling here calls
> > > > devm_kfree() which is not needed... devm_ functions automatically
> > > > clean up after themselves. This seems a pattern throughout. Do a
> > > > search for
> > > > devm_free() and see which ones are really needed or not.
> > > >
> > > I know that memory allocated with devm_kzalloc() is freed at the end
> > > of the lifetime of the device it is attached to. However, in error
> > > paths, why wait until the device is destroyed? Why not free the memory
> > > earlier so that it can be used for other purposes?
> >
> Why then do the devm_kfree() function exist?
>
> I will not remove the devm_free() calls unless the upstream maintainer
> requires me to do so.
The whole point of devm is to simplify (often poorly tested) error
paths. You're trying to optimize the error path instead of simplify it,
which doesn't make sense.
devm_kfree() is for the uncommon case when you want to free the memory
in a situation where the device isn't being unbound any time soon, but
you still want the memory to be handled by devm for some reason.
Most users of devm_kzalloc() do not use devm_kfree():
scott@snotra:~/fsl/git/linux/upstream$ git grep devm_kzalloc|wc -l
2750
scott@snotra:~/fsl/git/linux/upstream$ git grep devm_kfree|wc -l
118
-Scott
next prev parent reply other threads:[~2015-05-05 19:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 17:39 [PATCH 0/7] staging: fsl-mc: New functionality to the MC bus driver J. German Rivera
2015-04-28 17:39 ` [PATCH 1/7] staging: fsl-mc: MC bus IRQ support J. German Rivera
2015-04-30 11:49 ` Dan Carpenter
2015-05-04 22:09 ` Jose Rivera
2015-05-05 8:48 ` Dan Carpenter
2015-05-05 16:08 ` Jose Rivera
2015-05-05 16:40 ` Dan Carpenter
2015-05-05 19:56 ` Scott Wood
2015-05-05 20:22 ` Jose Rivera
2015-05-05 20:40 ` Scott Wood
2015-05-06 6:42 ` Dan Carpenter
2015-05-05 19:42 ` Scott Wood [this message]
2015-05-05 20:26 ` Jose Rivera
2015-04-28 17:39 ` [PATCH 2/7] staging: fsl_-mc: add device binding path 'driver_override' J. German Rivera
2015-04-28 17:39 ` [PATCH 3/7] staging: fsl-mc: Propagate driver_override for a child DPRC's children J. German Rivera
2015-04-28 17:39 ` [PATCH 4/7] staging: fsl-mc: Upgraded MC bus driver to match MC fw 7.0.0 J. German Rivera
2015-04-30 12:12 ` Dan Carpenter
2015-05-04 23:58 ` Jose Rivera
2015-05-05 8:51 ` Dan Carpenter
2015-04-28 17:39 ` [PATCH 5/7] staging: fsl-mc: Allow the MC bus driver to run without GIC support J. German Rivera
2015-04-28 17:39 ` [PATCH 6/7] staging: fsl-mc: Add locking to serialize mc_send_command() calls J. German Rivera
2015-04-30 12:59 ` Dan Carpenter
2015-05-05 16:20 ` Jose Rivera
2015-04-28 17:39 ` [PATCH 7/7] staging: fsl-mc: Use DPMCP IRQ and completion var to wait for MC J. German Rivera
2015-04-30 13:01 ` Dan Carpenter
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=1430854949.16357.240.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=German.Rivera@freescale.com \
--cc=R89243@freescale.com \
--cc=agraf@suse.de \
--cc=arnd@arndb.de \
--cc=bhamciu1@freescale.com \
--cc=bhupesh.sharma@freescale.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=itai.katz@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nir.erez@freescale.com \
--cc=richard.schmitt@freescale.com \
--cc=stuart.yoder@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox