Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754508AbZJBJCz (ORCPT ); Fri, 2 Oct 2009 05:02:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753087AbZJBJCy (ORCPT ); Fri, 2 Oct 2009 05:02:54 -0400 Received: from cantor.suse.de ([195.135.220.2]:59423 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752608AbZJBJCx (ORCPT ); Fri, 2 Oct 2009 05:02:53 -0400 Date: Fri, 02 Oct 2009 11:02:56 +0200 Message-ID: From: Takashi Iwai To: Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= Cc: linux-kernel@vger.kernel.org, Sam Ravnborg , Andrew Morton , Jaroslav Kysela , alsa-devel@alsa-project.org Subject: Re: [PATCH 06/34] don't use __devexit_p to wrap hal2_remove In-Reply-To: <20091001085355.GD2181@pengutronix.de> References: <20091001082607.GA2181@pengutronix.de> <1254385718-14254-6-git-send-email-u.kleine-koenig@pengutronix.de> <20091001085355.GD2181@pengutronix.de> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1336 Lines: 36 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/