Do not consider unknown HKEY events in the 0x6000 range to be thermal
warnings.  Instead, handle them as a generic unknown HKEY event, which
are reported to the kernel log at priority "notice", and do not trigger
a thermal registers state dump to the log.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NJordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

We should not do a thermal sensors state dump to the kernel log just
because the laptop is reporting that it changed into or out of tablet
mode.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: NJordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Demote to debug level one existing thermal-control related event, and
also add two new ones that would otherwise trigger unknown event
warnings.  These events are Windows-only for now.

We do report them to userspace in case they become useful in the future.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: NJordan Glover <Golden_Miller83@protonmail.ch>
Tested-by: NJordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, gmux_get_client_id(), returns an 'int'.

Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

As reported by Randy Dunlap:
>> WARNING: unmet direct dependencies detected for DELL_SMBIOS
>>   Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y]
>>	&& (DCDBAS [=m] ||
>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n)
>>   Selected by [y]:
>>   - DELL_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y]
>> && DMI [=y]
>> && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] ||
>>	ACPI_VIDEO [=n]=n)
>> && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y]
>>

Right now it's possible to set dell laptop to compile in but this
causes dell-smbios to compile in which breaks if dcdbas is a module.

Dell laptop shouldn't select dell-smbios anymore, but depend on it.

Fixes: 32d7b19b (platform/x86: dell-smbios: Resolve dependency error on DCDBAS)
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When the module is removed the led workqueue is destroyed in the remove
callback, before the led device is unregistered from the led subsystem.

This leads to a NULL pointer derefence when the led device is
unregistered automatically later as part of the module removal cleanup.
Bellow is the backtrace showing the problem.

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: __queue_work+0x8c/0x410
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP NOPTI
  Modules linked in: ccm edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 joydev crypto_simd asus_nb_wmi glue_helper uvcvideo snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel asus_wmi snd_hda_codec cryptd snd_hda_core sparse_keymap videobuf2_vmalloc arc4 videobuf2_memops snd_hwdep input_leds videobuf2_v4l2 ath9k psmouse videobuf2_core videodev ath9k_common snd_pcm ath9k_hw media fam15h_power ath k10temp snd_timer mac80211 i2c_piix4 r8169 mii mac_hid cfg80211 asus_wireless(-) snd soundcore wmi shpchp 8250_dw ip_tables x_tables amdkfd amd_iommu_v2 amdgpu radeon chash i2c_algo_bit drm_kms_helper syscopyarea serio_raw sysfillrect sysimgblt fb_sys_fops ahci ttm libahci drm video
  CPU: 3 PID: 2177 Comm: rmmod Not tainted 4.15.0-5-generic #6+dev94.b4287e5bem1-Endless
  Hardware name: ASUSTeK COMPUTER INC. X555DG/X555DG, BIOS 5.011 05/05/2015
  RIP: 0010:__queue_work+0x8c/0x410
  RSP: 0018:ffffbe8cc249fcd8 EFLAGS: 00010086
  RAX: ffff992ac6810800 RBX: 0000000000000000 RCX: 0000000000000008
  RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff992ac6400e18
  RBP: ffffbe8cc249fd18 R08: ffff992ac6400db0 R09: 0000000000000000
  R10: 0000000000000040 R11: ffff992ac6400dd8 R12: 0000000000002000
  R13: ffff992abd762e00 R14: ffff992abd763e38 R15: 000000000001ebe0
  FS:  00007f318203e700(0000) GS:ffff992aced80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 00000001c720e000 CR4: 00000000001406e0
  Call Trace:
   queue_work_on+0x38/0x40
   led_state_set+0x2c/0x40 [asus_wireless]
   led_set_brightness_nopm+0x14/0x40
   led_set_brightness+0x37/0x60
   led_trigger_set+0xfc/0x1d0
   led_classdev_unregister+0x32/0xd0
   devm_led_classdev_release+0x11/0x20
   release_nodes+0x109/0x1f0
   devres_release_all+0x3c/0x50
   device_release_driver_internal+0x16d/0x220
   driver_detach+0x3f/0x80
   bus_remove_driver+0x55/0xd0
   driver_unregister+0x2c/0x40
   acpi_bus_unregister_driver+0x15/0x20
   asus_wireless_driver_exit+0x10/0xb7c [asus_wireless]
   SyS_delete_module+0x1da/0x2b0
   entry_SYSCALL_64_fastpath+0x24/0x87
  RIP: 0033:0x7f3181b65fd7
  RSP: 002b:00007ffe74bcbe18 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
  RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3181b65fd7
  RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000555ea2559258
  RBP: 0000555ea25591f0 R08: 00007ffe74bcad91 R09: 000000000000000a
  R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000003
  R13: 00007ffe74bcae00 R14: 0000000000000000 R15: 0000555ea25591f0
  Code: 01 00 00 02 0f 85 7d 01 00 00 48 63 45 d4 48 c7 c6 00 f4 fa 87 49 8b 9d 08 01 00 00 48 03 1c c6 4c 89 f7 e8 87 fb ff ff 48 85 c0 <48> 8b 3b 0f 84 c5 01 00 00 48 39 f8 0f 84 bc 01 00 00 48 89 c7
  RIP: __queue_work+0x8c/0x410 RSP: ffffbe8cc249fcd8
  CR2: 0000000000000000
  ---[ end trace 7aa4f4a232e9c39c ]---

Unregistering the led device on the remove callback before destroying the
workqueue avoids this problem.

https://bugzilla.kernel.org/show_bug.cgi?id=196097Reported-by: NDun Hum <bitter.taste@gmx.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Sergey reported that some much older Dell systems don't support
the OEM string "Dell System" but instead supported www.dell.com
in OEM strings.

Match both of these to indicate that this driver is running on
a Dell system.
Reported-by: NSergey Kubushyn <ksi@koi8.net>
Tested-by: NSergey Kubushyn <ksi@koi8.net>
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
[dvhart: Simplify DMI logic and eliminate unnecessary variables]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

intel_scu_ipc_i2c_cntrl() calls mutex_lock(), which indicates
this function is not called in atomic context.

Despite never getting called from atomic context,
intel_scu_ipc_i2c_cntrl() calls mdelay to busily wait.
This is not necessary and can be replaced with usleep_range to
avoid busy waiting.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The hardcoded BIT(X) used in the soft key handling can be confusing and
prone to errors.

Instead, use the status FLAG_* defines for the sparse keymap index.
Rather than check for each known bit, use a bitmask to filter for all
known soft keys, and use the for_each_set_bit iterator.

Cc: Jan-Marek Glogowski <glogow@fbihome.de>
Cc: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The Thinkpad P50 has 2 fans. Add the 2FAN quirk so the tpacpi driver
properly reports both fan speeds.
Because the P50 doesn't report the version of its EC controller,
we need to identify it by BIOS version (N1).
Signed-off-by: NAlexander Kappner <agk@godking.net>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
[andy: renamed macro, massaged changelog]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

We're freeing "value_name" which is NULL, so that's a no-op, but we
intended to free "location_name" instead.  And then we don't free the
names in token_location_attrs[0] and token_value_attrs[0].

Fixes: 33b9ca1e ("platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

KEY_ROTATE_LOCK_TOGGLE is introduced in 4.16 rc1 and this key event is
emitted on Wacom MobileStudio Pro 13.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Co-developed-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Removed unused header files and sorted them alphabetically. No
functional changes are made.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add an entry with touchscreen info for the Yours Y8W81 8" tablet.

This tablet has the same case and mostly the same internals as the Chuwi
Vi8. Both seem to be from an ODM called inet-tek. Both are labelled:
"INET-I86M-REVxx" on the PCB, with the Chuwi Vi8 being REV03 (and having
an ALC5640 audio codec) and the Yours Y8W81 being REV21 (and having an
ALC5651 audio codec). The wifi, accelerometer and touchscreen are
identical on both.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Some functions definitions have either the initial open brace and/or
the closing brace outside of column 1.

Move those braces to column 1.

This allows various function analyzers like gnu complexity to work
properly for these modified functions.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NPaul Moore <paul@paul-moore.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Generate input events for hotkeys present in Fujitsu Lifebook
U727 and U757 laptops:
  - Fn+F1 (KEY_MICMUTE)
  - Fn+F5 (KEY_RFKILL)
Signed-off-by: NJan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

mlx-platform does not provide a bus number to i2c-mlxcpld, assuming it
is always one. On some x86 systems, other i2c drivers may probe before
i2c-mlxcpld, causing bus one to be busy.

Make mlx-platform determine which adapter number is free prior to
activating i2c-mlxpld, adjusting the mux base numbers accordingly.
Update the mlxreg-hotplug pdata similarly.

This adds an explicit mlx-platform build dependency on I2C, update the
Kconfig accordingly. Add the missing REGMAP dependency while we're at
it.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
[dvhart: Rewrite commit message more concisely]
[dvhart: Add build dependencies]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

mlx-platform activates i2c-mux-reg, which creates buses needed by
mlxreg-hotplug. If the mlxreg-hotplug probe runs before the i2c-mux-reg
probe completes, it may attempt to connect a device to an adapter number
that has not been created yet, and fail.

Make mlx-platform driver record the highest bus number in mlxreg-hotplug
platform data and defer mlxreg-hotplug probe until all the buses are
created.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
[dvhart: rewrite commit message more concisely]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Add define for the channels number for mux device, instead of using
hardcoded value inside the code in order to improve code readability.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

We need to add device-connections for the Type-C mux/switch and usb-role
code to be able to find the PI3USB30532 Type-C cross-switch and the
device/host role-switch integrated in the CHT SoC.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UNSUPPORTED_CMD was previously 0x80000000 (int), but commit 819cddae
("platform/x86: fujitsu-laptop: Clean up constants") changed it into an
unsigned long due to BIT() being used to define it.  As call_fext_func()
returns an int, 0x80000000 would get type promoted when compared to an
unsigned long, which on a 64-bit system would cause it to become
0xffffffff80000000 due to sign extension.  This causes one logical
condition in fujitsu-laptop to always be true and another one to always
be false on 64-bit systems.  Fix this by reverting UNSUPPORTED_CMD back
to an int.

This patch fixes the following smatch warnings:

drivers/platform/x86/fujitsu-laptop.c:763 acpi_fujitsu_laptop_leds_register() warn: always true condition '(call_fext_func(device, ((1 << (12)) | (1 << (0))), 2, (1 << (16)), 0) != (1 << (31))) => (s32min-s32max != 2147483648)'
drivers/platform/x86/fujitsu-laptop.c:816 acpi_fujitsu_laptop_add() warn: impossible condition '(priv->flags_supported == (1 << (31))) => (0-2147483647,18446744071562067968-u64max == 2147483648)'

Fixes: 819cddae ("platform/x86: fujitsu-laptop: Clean up constants")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

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>

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled,
DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends lines to
prevent a configuration where DELL_SMBIOS=y and either backend
dependency =m. Update the comment accordingly.

Cc: Mario Limonciello <mario.limonciello@dell.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

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>

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled,
DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends lines to
prevent a configuration where DELL_SMBIOS=y and either backend
dependency =m. Update the comment accordingly.

Cc: Mario Limonciello <mario.limonciello@dell.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
depends on DELL_DCDBAS, and we must avoid the situation where
DELL_SMBIOS=y and DCDBAS=m.

Adding the conditional dependency to DELL_SMBIOS such as:

depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)

results in the Kconfig tooling complaining about a circular dependency,
although it appears to work in practice.

Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
suggestion).

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

Avoid accidental configurations by setting default y for DELL_SMBIOS
backends. Avoid this impacting the default build size, by making them
dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
manually selected, or by DELL_LAPTOP or DELL_WMI.

While DELL_SMBIOS does have a prompt, it does not have any dependencies.
Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
backends, which would otherwise appear to float without context within
the menu.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some race conditions were raised due to dell-smbios and its backends
not being ready by the time that a consumer would call one of the
exported methods.

To avoid this problem, guarantee that all initialization has been
done by linking them all together and running init for them all.

As part of this change the Kconfig needs to be adjusted so that
CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean
rather than modules.

CONFIG_DELL_SMBIOS is a visually selectable option again and both
CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
[dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is being done to faciliate a later change to link all the dell-smbios
drivers together.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

WARNING: function definition argument 'struct calling_interface_buffer *'
should also have an identifier name
+       int (*call_fn)(struct calling_interface_buffer *);

WARNING: Block comments use * on subsequent lines
+       /* 4 bytes of table header, plus 7 bytes of Dell header,
	plus at least
+          6 bytes of entry */

WARNING: Block comments use a trailing */ on a separate line
+          6 bytes of entry */
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
depends on DELL_DCDBAS, and we must avoid the situation where
DELL_SMBIOS=y and DCDBAS=m.

Adding the conditional dependency to DELL_SMBIOS such as:

depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)

results in the Kconfig tooling complaining about a circular dependency,
although it appears to work in practice.

Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
suggestion).

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

Avoid accidental configurations by setting default y for DELL_SMBIOS
backends. Avoid this impacting the default build size, by making them
dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
manually selected, or by DELL_LAPTOP or DELL_WMI.

While DELL_SMBIOS does have a prompt, it does not have any dependencies.
Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
backends, which would otherwise appear to float without context within
the menu.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some race conditions were raised due to dell-smbios and its backends
not being ready by the time that a consumer would call one of the
exported methods.

To avoid this problem, guarantee that all initialization has been
done by linking them all together and running init for them all.

As part of this change the Kconfig needs to be adjusted so that
CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean
rather than modules.

CONFIG_DELL_SMBIOS is a visually selectable option again and both
CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
[dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is being done to faciliate a later change to link all the dell-smbios
drivers together.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

WARNING: function definition argument 'struct calling_interface_buffer *'
should also have an identifier name
+       int (*call_fn)(struct calling_interface_buffer *);

WARNING: Block comments use * on subsequent lines
+       /* 4 bytes of table header, plus 7 bytes of Dell header,
	plus at least
+          6 bytes of entry */

WARNING: Block comments use a trailing */ on a separate line
+          6 bytes of entry */
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

%pULL doesn't officially exist but %pUL does.

Miscellanea:

o Add missing newlines to a couple logging messages
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

%pULL doesn't officially exist but %pUL does.

Miscellanea:

o Add missing newlines to a couple logging messages
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The intel-hid device will not be able to wake up the system any more
after removing the notify handler provided by its driver, so make
its sysfs attributes reflect that.

Fixes: ef884112 (platform: x86: intel-hid: Wake up the system from suspend-to-idle)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The intel-vbtn device will not be able to wake up the system any more
after removing the notify handler provided by its driver, so make
its sysfs attributes reflect that.

Fixes: 91f9e850 (platform: x86: intel-vbtn: Wake up the system from suspend-to-idle)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>