[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0610061338230.8573@tm8103.perex-int.cz>
Date: Fri, 6 Oct 2006 13:46:52 +0200 (CEST)
From: Jaroslav Kysela <perex@...e.cz>
To: Cornelia Huck <cornelia.huck@...ibm.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Andrew Morton <akpm@...l.org>,
ALSA development <alsa-devel@...a-project.org>,
Takashi Iwai <tiwai@...e.de>, Greg KH <gregkh@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Kosina <jikos@...os.cz>,
Castet Matthieu <castet.matthieu@...e.fr>
Subject: Re: [Alsa-devel] [PATCH] Driver core: Don't ignore error returns
from probing
On Fri, 6 Oct 2006, Cornelia Huck wrote:
> On Fri, 6 Oct 2006 11:41:05 +0200 (CEST),
> Jaroslav Kysela <perex@...e.cz> wrote:
>
> > > Hm, I don't think we should call device_release_driver if
> > > bus_attach_device failed (and I think calling bus_remove_device if
> > > bus_attach_device failed is unintuitive). I did a patch that added a
> > > function which undid just the things bus_add_device did (here:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=115816560424389&w=2),
> > > which unfortunately got lost somewhere... (I'll rebase and resend.)
> >
> > Yes, but it might be better to check dev->is_registered flag in
> > bus_remove_device() before device_release_driver() call to save some code,
> > rather than reuse most of code in bus_delete_device().
>
> If we undid things (symlinks et al.) in the order we added them, we can
> factor out bus_delete_device() from bus_remove_device() and avoid both
> code duplication and calling bus_remove_device() if bus_attach_device()
> failed. Something like the patch below (untested).
It looks better, but I think that having only one function with if
(is_registered) saves a few bytes of instruction memory. Anyway, I do not
feel myself to judge what's the best.
Jaroslav
-----
Jaroslav Kysela <perex@...e.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists