All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Kay Sievers <Kay.Sievers@vrfy.org>
Subject: Re: [PATCH] fix error handling in bus_add_device
Date: Wed, 18 May 2005 00:32:30 -0700	[thread overview]
Message-ID: <20050518073230.GA12155@kroah.com> (raw)
In-Reply-To: <428AEC89.5040301@suse.de>

On Wed, May 18, 2005 at 09:19:37AM +0200, Hannes Reinecke wrote:
> Greg KH wrote:
> > On Thu, May 12, 2005 at 04:19:24PM +0200, Hannes Reinecke wrote:
> >>Hi Greg,
> >>
> >>this patch fixes the error handling in bus_add_device() and
> >>device_attach(). Previously it was 'interesting'.
> >>And totally confusing to boot.
> > 
> > I agree, that's why it has been rewritten in the -mm tree :)
> > 
> > Anyway, your patch doesn't take into account that device_attach()'s
> > return value is tested in the bus_rescan_devices_helper(), so if you
> > change the return value, that also needs to be changed.
> > 
> > But even in the -mm tree, the bus_add_devices() function has not had the
> > error handling added to it that you provided, is there any devices that
> > you are seeing that need this?
> > 
> Not yet :-)
> 
> I'm just doing some cleanups here which me and Kay Sievers will be
> exploiting in the near future.
> My main point is:
> either we do an error check in bus_add_device and return a proper
> status, or we don't and fix bus_add_device to be of type 'void'.
> And as some functions called by bus_add_device may fail I thought it
> reasonable to evaluate the return status properly.
> Unless you tell me that bus_add_device is a fire-and-forget procedure
> and we don't care at all for any failures. But then we should at least
> set the type of bus_add_device() to 'void'.
> You're the maintainer, you have to decide :-).
> I don't care either way, I just want to have it consistent.
> 
> But you're correct about the bus_rescan_devices_helper. Fixed and new
> patch attached.

Ok, I agree that we should have error checks in there.  Now, could you
make your patch against the latest -mm tree instead due to all of the
changes involved in that area in my trees?  That way I can apply it :)

thanks,

greg k-h

  reply	other threads:[~2005-05-18  7:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-12 14:19 [PATCH] fix error handling in bus_add_device Hannes Reinecke
2005-05-18  5:56 ` Greg KH
2005-05-18  7:19   ` Hannes Reinecke
2005-05-18  7:32     ` Greg KH [this message]
2005-05-18  8:42       ` Hannes Reinecke

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=20050518073230.GA12155@kroah.com \
    --to=greg@kroah.com \
    --cc=Kay.Sievers@vrfy.org \
    --cc=akpm@osdl.org \
    --cc=hare@suse.de \
    --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 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.