public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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