On Wednesday 23 September 2009, Dmitry Torokhov wrote: > >> __devexit? > > [MA] According to comments from David Brownell to the first version of > > this patch the __exit should be used. > > > > " - Use platform_driver_probe() and __exit/__exit_p(); > > there's no point in keeping that code around in > > typical configs, it'd just waste memory. " > > I am afraid David is wrong here. No, you're just pointing out a bug introduced in some unrelated code. Such bugs happen when folk ignore the code bloat issues. (And didn't Linus recently point out how such code bloat is becoming an issue?) > Even when we register driver with > platform_driver_probe() we still have "unbind" attribute in sysfs which > may be used to unbind the device from driver. If code is __exit then > such attempts will cause oops. That would be a bug in the unbind() code, which doesn't currently recognize that not every driver or bus supports hotplugging. It should probably check for a null release() pointer in the driver, and politely fail in that case. That's just about the only place that a third party (neither the driver nor its hotplug-aware bus framework) will try to decouple device and driver ... and it's doing it wrong. So it's unlikely such bugs will be elsewhere. It's *ALWAYS* been legit to have a NULL pointer in the remove() methods. That's why the __exit_p() -- or for hotpluggable drivers, __devexit_p() -- macros exist: for that particular case. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
