public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: David Vrabel <david.vrabel@csr.com>
Cc: Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: device_for_each_child() before device_add() doesn't work
Date: Tue, 14 Apr 2009 22:15:48 -0700	[thread overview]
Message-ID: <20090415051548.GC3462@kroah.com> (raw)
In-Reply-To: <49E4D2FF.8090906@csr.com>

On Tue, Apr 14, 2009 at 07:16:31PM +0100, David Vrabel wrote:
> Greg KH wrote:
> > On Tue, Apr 14, 2009 at 05:54:40PM +0100, David Vrabel wrote:
> >> Calling device_for_each_child() on a device that has yet to be added
> >> (with device_add()) used to work.  UWB subsystem currently tries to do this.
> >>
> >> Since "driver core: move klist_children into private structure"[1] this
> >> no longer works (an oops occurs in device_for_each_chid()).  Is it
> >> something that ought to work? Or should the UWB subsystem be changed to
> >> not do this?
> > 
> > Why would you call device_for_each_child() if you have never added it to
> > the bus?  How would you expect that to work, as there will never be any
> > children for it?
> 
> The children of a UWB radio controller (RC) are it's neighbors.  When 
> assigning a random DevAddr to an RC we need to check that the address is 
>   unique within the beacon group.  We use device_for_each_child() here 
> to check that the generated DevAddr is not used by any of its neighbors.

So the problem is for the first device being added, right?  Can't you
just have a flag for this?

> This address must be assigned during initialization and during normal 
> operation and in the past we didn't need to special case the address 
> assignment during initialization.

Does the patch below fix the problem for you?

thanks,

greg k-h

---------------

 drivers/base/core.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1142,6 +1142,9 @@ int device_for_each_child(struct device 
 	struct device *child;
 	int error = 0;
 
+	if (!parent->p)
+		return 0;
+
 	klist_iter_init(&parent->p->klist_children, &i);
 	while ((child = next_device(&i)) && !error)
 		error = fn(child, data);

  reply	other threads:[~2009-04-15  5:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 16:54 device_for_each_child() before device_add() doesn't work David Vrabel
2009-04-14 16:59 ` Greg KH
2009-04-14 18:16   ` David Vrabel
2009-04-15  5:15     ` Greg KH [this message]
2009-04-15 14:51       ` David Vrabel
2009-04-16  2:48         ` Greg KH

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=20090415051548.GC3462@kroah.com \
    --to=greg@kroah.com \
    --cc=david.vrabel@csr.com \
    --cc=linux-kernel@vger.kernel.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