[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hzl8agocf.wl%tiwai@suse.de>
Date: Fri, 02 Oct 2009 11:02:56 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Cc: linux-kernel@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jaroslav Kysela <perex@...ex.cz>, alsa-devel@...a-project.org
Subject: Re: [PATCH 06/34] don't use __devexit_p to wrap hal2_remove
At Thu, 1 Oct 2009 10:53:55 +0200,
Uwe Kleine-König wrote:
>
> On Thu, Oct 01, 2009 at 10:36:59AM +0200, Takashi Iwai wrote:
> > At Thu, 1 Oct 2009 10:28:10 +0200,
> > Uwe Kleine-König wrote:
> > >
> > > The function hal2_remove is defined using __exit, so don't use __devexit_p
> > > but __exit_p to wrap it.
> >
> > I think it's the other way round. We should replace __exit with __devexit.
> > Ditto for sound/mips/sgio2audio.c.
> Actually both ways are possible. I choosed the alternative that doesn't
> add bloat to the kernel. The cost is that the device isn't hotplugable,
> but you can still unload the module to unbind the driver.
Hm, is it really safe to set remove=NULL although the driver needs
some work at unbinding? It looks like that unbind is allowed no
matter whether remove is NULL or not. So, it would jus keeps stray
resources, and it might conflict at the next bind.
> I don't care much, but prefer slightly my approach as changing the patch
> is work for me :-)
I prefer rather symmetry and safety :)
I'm going to change to __devexit.
thanks,
Takashi
--
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