On Mon, 06 Nov 2006, Richard Purdie wrote: > that other devices would have a similar set of constraints (all the > existing users at the time did). On such hardware, deinitialising > anything you initialised is the norm and makes sense but the PC/ACPI > world is different. Yes, and we don't *init* the hardware with the backlight class either in ACPI drivers... AFAIK, anyway. > Setting backlightdevice->props->update_status = NULL before > unregistering is a horrible idea and I don't want to see hacks like that > so yes, lets move it back into the drivers. Sure thing. I am not at all interested into having such a horrible hack in my local version of ibm-acpi for a second longer than strictly needed, so I will help if I am able to. > > Since the commit that introduced this behaviour (commit > > 6ca017658b1f902c9bba2cc1017e301581f7728d) apparently did so because the > > corgi_bl.c driver powered off the backlight, the attached patch also makes > > sure that the corgi_bl.c driver will not have its behaviour changed. > > Those commits were designed to standardise several behaviours amongst > several drivers and this specific case was added to the core rather than > coding it in each of several drivers. We therefore really need to update > those other drivers too (locomo at the very least). Do you have a list of them? I can try to produce (untested) patches for the ones in-tree, if you want me to. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
