At Fri, 2 Oct 2009 11:20:25 +0200, Uwe Kleine-König wrote:
Hello,
On Fri, Oct 02, 2009 at 11:02:56AM +0200, Takashi Iwai wrote:
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 just tried that and you're right. IMHO that's a bug. Greg?
I suppose it's a bug of the driver, not the core :) If the driver doesn't need to release resources, it would work fine with remove = NULL. Also, the bus can provide a common remove callback (even it's over the driver's remove callback). So, in theory, it can be NULL.
But, it must be really rare, and non-NULL remove is very likely a bug if the driver is built with CONFIG_HOTPLUG=y...
thanks,
Takashi