linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: gregkh@suse.de (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: tq 2440
Date: Thu, 15 Jul 2010 10:22:18 -0700	[thread overview]
Message-ID: <20100715172218.GA22197@suse.de> (raw)
In-Reply-To: <20100715171029.GK29322@n2100.arm.linux.org.uk>

On Thu, Jul 15, 2010 at 06:10:29PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 15, 2010 at 09:51:41AM -0700, Greg KH wrote:
> > On Thu, Jul 15, 2010 at 05:35:26PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Jul 15, 2010 at 11:16:30PM +0800, Conke Hu wrote:
> > > > ever notice to the following kernel log?
> > > > "Device 's3c2440-nand' does not have a release() function, it is
> > > > broken and must."
> > > > release() function should be implemented  in the platform_device.
> > > 
> > > That's not telling you to provide a release function.  The warning is
> > > telling you that a device is being unregistered which doesn't have a
> > > release function.
> > > 
> > > Consider this point - maybe it doesn't have a release function because
> > > it's not supposed to be unregistered?
> > 
> > Heh, well, it is being unregistered, and at that point in time, the
> > kernel complains.
> 
> The unregistration occurs because platform_register_devices() (which is
> used by arch code to register a block of platform devices) undoes its
> work if one of the devices fails to register.
> 
> I've long since thought, since I created that function, that this probably
> isn't desirable behaviour, and it should continue to register as many
> devices as it possibly can.
> 
> > All kobjects need a release function that actually frees it.  If not,
> > that is a logic bug.  Please see the Documentation/kobject.txt file for
> > details.
> 
> How do you free a statically declared platform device?

You never unregister it :)

Otherwise, you will have problems with the reference counting logic, and
you should make it a dynamic device.  I really want to move to forcing
all devices to be created dynamically, but the platform devices are the
biggest static device users, so I've not been pushing it very hard, due
to other more pressing issues...

thanks,

greg k-h

  reply	other threads:[~2010-07-15 17:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-01  2:31 tq 2440 CoffBeta
2010-07-15 15:16 ` Conke Hu
2010-07-15 16:35   ` Russell King - ARM Linux
2010-07-15 16:51     ` Greg KH
2010-07-15 17:10       ` Russell King - ARM Linux
2010-07-15 17:22         ` Greg KH [this message]
2010-07-15 17:33           ` Russell King - ARM Linux
2010-07-15 20:51             ` Greg KH
2010-07-15 21:09               ` Russell King - ARM Linux
2010-07-16  8:55                 ` Greg KH
2010-07-16  9:07                   ` Russell King - ARM Linux
2010-07-16  5:40     ` Conke Hu

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=20100715172218.GA22197@suse.de \
    --to=gregkh@suse.de \
    --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).