Before this commit, the following would happen:

 a) acpi_video_get_backlight_type() gets called
 b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
 c) acpi_video_init_backlight_type() locks its function static init_mutex
 d) acpi_video_init_backlight_type() calls backlight_register_notifier()
 e) backlight_register_notifier() takes its notifier-chain lock

And when the backlight notifier chain gets called we've:

 1) blocking_notifier_call_chain() gets called
 2) blocking_notifier_call_chain() takes the notifier-chain lock
 3) blocking_notifier_call_chain() calls acpi_video_backlight_notify()
 4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type()
 5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
 6) acpi_video_init_backlight_type() locks its function static init_mutex

So in the first call sequence we have:

 a) init_mutex gets locked
 b) notifier-chain gets locked

and in the second call sequence we have:

 1) notifier-chain gets locked
 2) init_mutex gets locked

And we've a circular locking dependency. This specific locking dependency
is fixable without using the big hammer otherwise known as a workqueue,
but further analysis shows a similar problem with the backlight notifier
chain lock vs register_count_mutex from drivers/acpi/acpi_video.c,
and fixing that becomes problematic.

So this commit simply fixes this with the big hammer, performance
wise this is a non issue as we expect the work to get scheduled
exactly zero or one times during normal system use.

Fixes: 93a291df (ACPI / video: Move backlight notifier to video_detect.c)
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reported-and-tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>