On Wed, 20 Nov 2013, Matthew Garrett wrote: > On Mon, 2013-11-11 at 22:56 -0200, Henrique de Moraes Holschuh wrote: > > On Tue, 12 Nov 2013, Jingoo Han wrote: > > > 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'. > > > Henrique, can we remove it? > > > > Can't you fix this by rate-limiting, or otherwise adding an attribute that > > backlight devices should set when they need to supress change events? > > It looks like this is just to force synchronisation to sysfs when using > the /proc interface? In which case we should probably just kill > the /proc interface. Well, we can remove the thinkpad-acpi /proc interface as far as I'm concerned, and that would do away with the use of BACKLIGHT_UPDATE_SYSFS by thinkpad-acpi. It is a major userspace ABI break, but removing everything under /proc/acpi is one of the very few ABI breaks we actually have the green light to do. However, the patchset is not about this. With this patchset applied, as far as I can tell anything that used to be uevent-driven by the backlight class will break: when a process changes the backlight using sysfs, other processes will not be notified of the change anymore. This patchset seems to break backlight uevent support in such a way that basically renders the entire thing useless and you might as well just remove uevent support entirely. It is also an userspace ABI break, which we do not do lightly. So, as far as I'm concerned, this patchset should be rejected in its present form. IMO, either one that preserves BACKLIGHT_UPDATE_SYSFS and fixes the urgent issue, or one that removes uevent support entirely from the backlight class should be proposed instead. -- "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 platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html