From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: Using statically allocated memory for platform_data.
Date: Mon, 2 Nov 2009 16:47:44 +0000 [thread overview]
Message-ID: <20091102164743.GE23772@trinity.fluff.org> (raw)
In-Reply-To: <20091102163701.GD5785@n2100.arm.linux.org.uk>
On Mon, Nov 02, 2009 at 04:37:01PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 02, 2009 at 04:28:39PM +0000, Ben Dooks wrote:
> > On Mon, Nov 02, 2009 at 03:56:25PM +0000, Russell King - ARM Linux wrote:
> > > The reason we have platform_device_add_data() is that people think that
> > > the device data needs to persist for the lifetime of the device. I
> > > personally disagree with that - once you unregister the device, it's
> > > guaranteed that device drivers will have been unregistered, so who's
> > > going to use the platform data?
> >
> > That doesn't make any sense, in the current case of using the
> > platform_device_alloc() and those calls the data is only living
> > for the lifetime of the device, as the release call is tidying up
> > the result.
>
> What I'm saying is that the lifetime of the data finishes once
> the _unregister() call has returned. So:
>
> data = pdev->dev.platform_data;
> platform_device_unregister(pdev);
> kfree(data);
>
> is an entirely valid way of handling the "I allocated my platform
> data" problem - it doesn't need to exist to the point where the
> device itself is freed.
Unforutnately pretty much everyone now assumes that the act of
unregistering the device will get rid of the data that the allocated
by the add functions.
This would mean going around fixing a number of current drivers which
all make that assumption.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
next prev parent reply other threads:[~2009-11-02 16:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 10:23 Using statically allocated memory for platform_data Antonio Ospite
2009-11-02 10:39 ` Uwe Kleine-König
2009-11-02 14:51 ` Ben Dooks
2009-11-02 15:00 ` Ben Dooks
2009-11-02 15:05 ` Russell King - ARM Linux
2009-11-02 15:25 ` Ben Dooks
2009-11-02 15:52 ` Ben Dooks
2009-11-02 15:56 ` Russell King - ARM Linux
2009-11-02 16:28 ` Ben Dooks
2009-11-02 16:37 ` Russell King - ARM Linux
2009-11-02 16:47 ` Ben Dooks [this message]
2009-11-03 17:31 ` Antonio Ospite
2009-11-08 21:24 ` Antonio Ospite
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=20091102164743.GE23772@trinity.fluff.org \
--to=ben-linux@fluff.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).