diff options
author | 2015-06-16 16:27:42 +0200 | |
---|---|---|
committer | 2015-06-19 01:10:08 +0200 | |
commit | a341b8aba13c39fc76aea29fe13ea851df313bd6 (patch) | |
tree | ad191b62977b477c8df1a5d5c7499a16f1160162 /drivers/acpi/video_detect.c | |
parent | samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister (diff) | |
download | wireguard-linux-a341b8aba13c39fc76aea29fe13ea851df313bd6.tar.xz wireguard-linux-a341b8aba13c39fc76aea29fe13ea851df313bd6.zip |
apple-gmux: Stop using acpi_video_dmi_demote_vendor()
acpi_video_dmi_demote_vendor() is going away as part of the cleanup of
the code for determinging which backlight class driver(s) to register.
The call to acpi_video_dmi_demote_vendor() was meant to undo the call to
acpi_video_dmi_promote_vendor() when the gmux device is removed, this is
questionable though since the promote call sets a flag, not a counter, so
the demote call may undo a promoto done elsewhere. Moreover in practice
this is a nop since the gmux device is never removed, and the flag is only
checked when acpi/video.ko gets loaded, so even if the user manually
removes apple-gmux the demote call is still a nop as video.ko will already
have loaded by this time.
Also note that none of the other users of acpi_video_dmi_promote_vendor()
use acpi_video_dmi_demote_vendor().
If we ever encounter a system with a gmux where the acpi-video interface
should be used, then the proper fix would be to dmi-blacklist the gmux
driver on that system.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/acpi/video_detect.c')
0 files changed, 0 insertions, 0 deletions