All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Driver core: add new device to bus's list before probing
Date: Fri, 31 Jul 2009 09:05:44 -0700	[thread overview]
Message-ID: <20090731160544.GA3430@kroah.com> (raw)
In-Reply-To: <ac3eb2510907301357j43189388lae6ec5d4e6ad365e@mail.gmail.com>

On Thu, Jul 30, 2009 at 04:57:06PM -0400, Kay Sievers wrote:
> On Thu, Jul 30, 2009 at 15:27, Alan Stern<stern@rowland.harvard.edu> wrote:
> > This patch (as1271) affects when new devices get linked into their
> > bus's list of devices.  Currently this happens after probing, and it
> > doesn't happen at all if probing fails.  Clearly this is wrong,
> > because at that point quite a few symbolic links have already been
> > created in sysfs.  We are committed to adding the device, so it should
> > be linked into the bus's list regardless.
> >
> > In addition, this needs to happen before the uevent announcing the new
> > device gets issued.  Otherwise user programs might try to access the
> > device before it has been added to the bus.
> >
> > To fix both these problems, the patch moves the call to
> > klist_add_tail() forward from bus_attach_device() to bus_add_device().
> > Since bus_attach_device() now does nothing but probe for drivers, it
> > has been renamed to bus_probe_device().  And lastly, the kerneldoc is
> > updated.
> 
> Thanks for doing this that quickly. You are doing a really great job.
> 
> > Kay, do you want this merged into 2.6.31 or are you okay with waiting
> > for 2.6.32-rc1?  It changes a major core routine.  On the other hand,
> > the problem it fixes does affect real users.
> 
> I think it should go into -next and we wait a few days. It seems like
> the proper fix, but we should make sure, we didn't miss something.
> 
> After that, it would be nice if we can get that into 2.6.31, as we
> have several problems already, which are likely solved by this.

But as this isn't a regression (it's how things always have worked,
right?), I'm a bit leary of pushing it to .31 right now, so late in the
release cycle.  How about it goes to Linus for .32, and we backport it
to -stable if it looks ok?

thanks,

greg k-h

  reply	other threads:[~2009-07-31 16:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30 19:27 [PATCH] Driver core: add new device to bus's list before probing Alan Stern
2009-07-30 20:57 ` Kay Sievers
2009-07-31 16:05   ` Greg KH [this message]
2009-07-31 16:30     ` Kay Sievers
2009-07-31 16:41       ` 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=20090731160544.GA3430@kroah.com \
    --to=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.