Update the initcall ordering to satisfy the following dependency
ordering:

1. DCDBAS, ACPI_WMI
2. DELL_SMBIOS, DELL_RBTN
3. DELL_LAPTOP, DELL_WMI

By assigning them to the following initcall levels:

subsys_initcall: DCDBAS, ACPI_WMI
module_init: DELL_SMBIOS, DELL_RBTN
late_initcall: DELL_LAPTOP, DELL_WMI

Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Mario.Limonciello@dell.com
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The Dell Latitude 5495 has the mic mute key.
Signed-off-by: NShih-Yuan Lee (FourDollars) <sylee@canonical.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This allocation won't fail in the current kernel because it's small but
not checking for kmalloc() failures introduces static checker warnings
so let's fix it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This allocation won't fail in the current kernel because it's small but
not checking for kmalloc() failures introduces static checker warnings
so let's fix it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

dell-wmi and dell-smbios-wmi are dependent upon dell-wmi-descriptor
finishing probe successfully to probe themselves.

Currently if dell-wmi-descriptor fails probing in a non-recoverable way
(such as invalid header) dell-wmi and dell-smbios-wmi will continue to
try to redo probing due to deferred probing.

To solve this have the dependent drivers query the dell-wmi-descriptor
driver whether the descriptor has been determined valid. The possible
results are:
-ENODEV: Descriptor GUID missing from WMI bus
-EPROBE_DEFER: Descriptor not yet probed, dependent driver should wait
 and use deferred probing
< 0: Descriptor probed, invalid.  Dependent driver should return an
 error.
0: Successful descriptor probe, dependent driver can continue

Successful descriptor probe still doesn't mean that the descriptor driver
is necessarily bound at the time of initialization of dependent driver.
Userspace can unbind the driver, so all methods used from driver
should still be verified to return success values otherwise deferred
probing be used.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm

dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.

Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely.  Rather than a single global buffer being allocated
for all drivers, each driver will allocate and be responsible for it's own
buffer. The pointer will be passed to the calling function and each
dispatcher driver will then internally copy it to the proper location to
perform it's call.

Add defines for calls used by these methods in the dell-smbios.h header
for tracking purposes.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.

The information found from the WMI descriptor driver is now exported
for use by other drivers.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is intended to be variable and provided by the platform.
Some platforms this year will be adopting a 32k WMI buffer, so don't
complain when encountering those platforms or any other future changes.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some cases the wrong type was used for errors and checks can be
done more cleanly.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.

If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the data
should not be relied upon.

For the remaining data set vectors, continue to notate a warning
in undefined results, but as those are fields that the descriptor
intended to refer to other applications, don't fail if they're new
values.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The descriptor GUID is not used to indicate that WMI notifications
in the dell-wmi driver work properly.  As such a modalias should
not be present that causes this driver to load on systems with this
GUID.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NPali Pohar <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This converts dell_wmi_check_descriptor_buffer() to the new driver
model interface and puts the interface version in dell_wmi_priv
where it belongs.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When I converted dell-wmi to the new bus infrastructure, I left the
call to dell_wmi_check_descriptor_buffer() in dell_wmi_init().  This
could cause two problems:

 - An error message when loading the driver on a system without
   dell-wmi.  We'd try to read the event descriptor even if the WMI
   GUID wasn't there.

 - A possible race if dell-wmi was loaded manually before wmi was
   fully initialized.

Fix it by moving the call to the probe function where it belongs.

Fixes: bff589be ("platform/x86: dell-wmi: Convert to the WMI bus infrastructure")
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When I converted dell-wmi to the new bus infrastructure, I left the
call to dell_wmi_check_descriptor_buffer() in dell_wmi_init().  This
could cause two problems:

 - An error message when loading the driver on a system without
   dell-wmi.  We'd try to read the event descriptor even if the WMI
   GUID wasn't there.

 - A possible race if dell-wmi was loaded manually before wmi was
   fully initialized.

Fix it by moving the call to the probe function where it belongs.

Fixes: bff589be ("platform/x86: dell-wmi: Convert to the WMI bus infrastructure")
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Move some initialization out of _init and into _probe.
Update signatures and logic to use the wmi bus and device structures.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
[dvhart: drop deprecated sparse_keymap_free, order declarations, add commit msg]
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is based on Mario's explanation and observation of my laptop.
Suggested-by: N"Pali Rohár" <pali.rohar@gmail.com>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The hotkey table is 0xb2, add a comment for clarity.
Suggested-by: NDarren Hart <dvhart@infradead.org>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Make dell-wmi notify on hotkey kbd brightness changes, listen for this
in dell-laptop and call led_classdev_notify_brightness_hw_changed.

This will allow userspace to monitor (poll) for brightness changes on
these LEDs caused by the hotkey.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

As sparse_keymap_setup() now uses a managed memory allocation for the
keymap copy it creates, the latter is freed automatically.  Remove all
calls to sparse_keymap_free().

As this reduces dell_wmi_input_destroy() to one line, replace all calls
to that function with direct calls to input_unregister_device().
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3)
and a detachable keyboard/mouse dock.
Signed-off-by: NMario Limonciello <mario_limonciello@dell.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Wifi catcher is a slider switch, that when slid past the on position
will emit an event that is intended for launching a wifi application
or applet when the machine is turned on.
Signed-off-by: NMario Limonciello <mario_limonciello@dell.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

WMI event 0xe00e is received when battery was removed or inserted.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Some new Dell AIO systems have a button that generates a WMI event to
turn the LCD on/off.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

This patch reworks code for generating sparse keymap and processing WMI
events. It unifies procedure for generating sparse keymap and also unifies
big switch code for processing WMI events of different types. After this
patch dell-wmi driver does not differ between "old" and "new" hotkey type.

It constructs sparse keymap table with all WMI codes. It is because on some
laptops (e.g. Dell Latitude E6440) ACPI/firmware send both event types (old
and new).

Each WMI code in sparse keymap table is prefixed by 16bit event type, so it
does not change functionality on laptops with "old" hotkey support (those
without scancodes in DMI).

This allow us to distinguish between same WMI codes with different types in
sparse keymap. Thanks to this WMI events of type 0x0011 were moved from big
switch into sparse keymap table too.

This patch also fixes possible bug in parsing WMI event buffer introduced
in commit 5ea25597 ("dell-wmi: Add support for new Dell systems"). That
commit changed buffer type from int* to u16* without fixing code. More at:
http://lkml.iu.edu/hypermail/linux/kernel/1507.0/01950.htmlSigned-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

ACPI DSDT tables have defined other WMI codes, but does not contain any
description when those codes are emitted. Some other codes can be found in
logs on internet. In this patch are all which I saw, but lot of them are
not tested properly (e.g. for duplicate events with AT keyboard). Now we
have all WMI event codes at one place and in future after proper testing
those codes can be correctly enabled or disabled...
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

For better readability of keymap table, sort events by codes and also
update comments for events to be more informative.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

>From Dell we know that WMI event code 0xe045 is for Num Lock key, but it is
unclear due to message in commit 0b3f6109 ("dell-wmi: new driver for
hotkey control").
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: NMichał Kępień <kernel@kempniu.pl>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Link: https://lkml.org/lkml/2015/7/7/830Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Similarly to Dell Vostro V131, Dell Inspiron M5110 also requires an
SMBIOS request to be issued in order for WMI events to be generated and
does not raise an i8042 interrupt when the Dell Instant Launch hotkey is
pressed.  However, the event code for that hotkey on this machine is
0xe029, so add it to the legacy keymap.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NDarek Stojaczyk <darek.stojaczyk@gmail.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

On models on which an SMBIOS request needs to be issued in order for WMI
events to be generated, pressing the Dell Instant Launch hotkey does not
raise an i8042 interrupt - only a WMI event is generated (0xe025 on Dell
Vostro V131).  As that WMI event is the only way the kernel will be
notified about pressing the Dell Instant Launch hotkey on such machines,
the relevant keymap entry has to be changed to a KE_KEY one.  However,
the same WMI event should still be ignored on machines which do not
require an SMBIOS request for enabling WMI, so filter it conditionally
in dell_wmi_process_key().
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

On some laptop models (e.g. Dell Vostro V131), WMI events are not
generated until a specific SMBIOS request is issued to register an event
listener [1].  As there seems to be no ACPI method or SMBIOS request to
determine without possible side effects whether a given machine needs to
issue this SMBIOS request in order to receive WMI events, DMI matching
is used to whitelist the models which need it.

[1] https://lists.us.dell.com/pipermail/libsmbios-devel/2015-July/000612.htmlSigned-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The XPS 13 9350 sends WMI keypress events that aren't enumerated in
the DMI table.  Add a table listing them.  To avoid breaking things
that worked before, these un-enumerated hotkeys won't be used if the
DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we
might want to rethink how we handle events in general.  As an
example, a whole lot of things map to KEY_PROG3 via the DMI table.

This doesn't send keypress events for any of the new events.  They
appear to all be handled by other means (keyboard illumination is
handled automatically and rfkill is handled by intel-hid).
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Checking the table for a minimum size of 7 bytes makes no sense: any valid
hotkey table has a size that's a multiple of 4.

Clean this up: replace the hardcoded header length with a sizeof and
change the check to ignore an empty hotkey table.  The only behavior
change is that a 7-byte table (which is nonsensical) will now be
treated as absent instead of as valid but empty.
Reported-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

The dmi_walk function maps the DMI table, walks it, and unmaps it.
This means that the dell_bios_hotkey_table that find_hk_type stores
points to unmapped memory by the time it gets read.

I've been able to trigger crashes caused by the stale pointer a
couple of times, but never on a stock kernel.

Fix it by generating the keymap in the dmi_walk callback instead of
storing a pointer.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

BIOS/ACPI on devices with WMI interface version 0 does not clear buffer
before filling it. So next time when BIOS/ACPI send WMI event which is
smaller as previous then it contains garbage in buffer from previous event.

BIOS/ACPI on devices with WMI interface version 1 clears buffer and
sometimes send more events in buffer at one call.

Since commit 83fc44c3 ("dell-wmi: Update code for processing WMI
events") dell-wmi process all events in buffer (and not just first).

To prevent reading garbage from the buffer we process only the first
event on devices with WMI interface version 0.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

After examining existing DSDT ACPI tables of more laptops and looking
into Dell WMI document mentioned in ML dicussion archived at
http://www.spinics.net/lists/platform-driver-x86/msg07220.html we will
parse and check WMI descriptor if contains expected data. It is because
WMI descriptor contains interface version number and it is needed to
know in next commit.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

If DMI lists a hotkey that we don't recognize, log and ignore it
instead of trying to map it to keycode 0.  I haven't seen this happen,
but it will help maintain the key map in the future and it will help
avoid sending bogus events.

This also improves the message that we log when we get an unknown key
event.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
[dvhart: remove BUILD_BUG_ON per mutual agreement on list]
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Use the new acpi_video_handles_brightness_key_presses function to check
if we should report brightness key-presses.

This makes the code both easier to read and makes it properly report
key-presses when acpi-video is not reporting them for reasons other
then the backlight type being vendor.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It's currently hard to follow what maps to what, and it's hard to edit
the array.  Redo it as a C99-style array.

I generated this using emacs regexes and a python one-liner.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Keyboard illumination level changes are performed by the BIOS, so no
events should be reported on keypress. This is already done on systems
using the legacy keymap, do it also for systems that don't use it.
Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>