ACPI / video: Add an acpi_video_unregister_backlight function

Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.

Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:

acpi_video_dmi_promote_vendor();
acpi_video_unregister();

The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.

This leads to the following 2 interesting scenarios:

 a) intel gfx:
  1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
     and i915)
  2) acpi-video does NOT call acpi_video_register()
  3) acpi_vendor loads (lets assume it loads before i915), calls
     acpi_video_dmi_promote_vendor(); which sets
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
  4) calls acpi_video_unregister -> not registered, nop
  5) i915 loads, calls acpi_video_register
  6) acpi_video_register registers the acpi_notifier for the hotkeys,
     does NOT register a backlight device because of
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR

 b) non intel gfx
  1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
  2) acpi-video calls acpi_video_register()
  3) acpi_video_register registers the acpi_notifier for the hotkeys,
     and a backlight device
  4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
  5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
     for the hotkeys AND the backlight device

So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.

Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!

So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

drivers/acpi/video.c

@@ -2078,6 +2078,20 @@ void acpi_video_unregister(void)
 }
 EXPORT_SYMBOL(acpi_video_unregister);
 
+void acpi_video_unregister_backlight(void)
+{
+	struct acpi_video_bus *video;
+
+	if (!register_count)
+		return;
+
+	mutex_lock(&video_list_lock);
+	list_for_each_entry(video, &video_bus_head, entry)
+		acpi_video_bus_unregister_backlight(video);
+	mutex_unlock(&video_list_lock);
+}
+EXPORT_SYMBOL(acpi_video_unregister_backlight);
+
 /*
  * This is kind of nasty. Hardware using Intel chipsets may require
  * the video opregion code to be run first in order to initialise

include/acpi/video.h

@@ -19,11 +19,13 @@ struct acpi_device;
 #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
 extern int acpi_video_register(void);
 extern void acpi_video_unregister(void);
+extern void acpi_video_unregister_backlight(void);
 extern int acpi_video_get_edid(struct acpi_device *device, int type,
 			       int device_id, void **edid);
 #else
 static inline int acpi_video_register(void) { return 0; }
 static inline void acpi_video_unregister(void) { return; }
+static inline void acpi_video_unregister_backlight(void) { return; }
 static inline int acpi_video_get_edid(struct acpi_device *device, int type,
 				      int device_id, void **edid)
 {