Change the first input parameter in mlxreg_hotplug_device_create to the
pointer to mlxreg_hotplug private data in order to use the fields from
the private data structure.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
[dvhart: Cleaned up commit message]
Signed-off-by: Darren 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: Vadim Pasternak <vadimp@mellanox.com>
[dvhart: rewrite commit message more concisely]
Signed-off-by: Darren 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: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.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: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren 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: Darren 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: Darren 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: Darren 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: Darren 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: Mario Limonciello <mario.limonciello@dell.com>
[dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
Signed-off-by: Darren 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: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Darren 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: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Darren 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: Joe Perches <joe@perches.com>
Signed-off-by: Darren 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Some laptops such as the XPS 9360 support the intel-vbtn INT33D6
interface but don't initialize the bit that intel-vbtn uses to
represent switching tablet mode.

By running this only on real 2-in-1's it shouldn't cause false
positives.

Fixes: 30323fb6 ("Support tablet mode switch")
Reported-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Tested-by: Jeremy Cline <jeremy@jcline.org>
Tested-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Align all constant values defined in the module to a common indentation.
Rename ACPI_FUJITSU_NOTIFY_CODE1 to ACPI_FUJITSU_NOTIFY_CODE as there is
only one ACPI notification code used throughout the driver.  Define all
bitmasks using the BIT() macro.  Clean up comments.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Use named constants instead of integers in call_fext_func() invocations
related to backlight power control in order to more clearly convey the
intent of each call.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Do not include linux/slab.h as all module code now uses managed memory
allocations and thus neither k*alloc() nor kfree() is used.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

In order to improve code clarity, move declarations of variables that
are module parameters higher up and add a comment.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Replace the last few lines of acpi_fujitsu_bl_add() with a simple return
in order to improve code readability without changing the logic.

As acpi_fujitsu_laptop_add() uses a managed memory allocation for
device-specific data, it is fine to just return immediately upon kfifo
allocation failure.  Do that instead of jumping to the end of the
function to improve code readability.  Running out of memory while
allocating the kfifo does not seem probable enough to warrant logging an
error message, so do not do it.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Only register input devices after the device-specific data structures
they access are fully initialized.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

Different functions in the module use varying names (error, result,
status) for a local variable storing the return value of a function call
that has to be checked for errors.  Use a common name (ret) for all
these local variables to improve code consistency.  Merge integer
variable declarations in acpi_fujitsu_laptop_add() into one line.
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>

The I.T.Works TW701 7" tablet is a differently branded version of the
same generic 7" Windows tablet as the Trekstor ST70416-6. Add a DMI
match-table entry for it pointing to the Trekstor's touchscreen info.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Replace verbatim GPLv2 license copy with SPDX identifier.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Add myself as an author of the driver.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Topstar U931 laptops provide a LED synced with the WLAN adapter
hard-blocking state. Unfortunately, some models seem to be defective,
making impossible to hard-block the adapter with the WLAN switch and
thus the LED is useless.

An ACPI method is available to programmatically control this switch and
it indirectly allows to control the LED.

This commit registers the LED within the corresponding subsystem, making
possible for instance to use an rfkill-based trigger to synchronize the
LED with the device state.

This workaround is enabled automatically for Topstar U931/RVP7 laptops
based on a DMI check.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

* add a platform device to support further addition of a led subsystem,

* register the existing input device to this platform device.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

* get the `acpi_device` from the `topstar_laptop` struct,

* split input registering and `sparse_keymap` events from ACPI events
handling,

* use notify, init and exit functions for ACPI and input handling
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

* use module prefix naming scheme for functions and programming
constructs,

* consistent label names
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Revert commit
  15165594 ("topstar-laptop: convert to module_acpi_driver()")
to later add a platform device.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

In all cases list_for_each() followed by list_entry(),
so, replace them by list_for_each_entry() macro.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org>

kasprintf() does the job of two: kmalloc() and sprintf().
Replace two calls with one.
Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

On systems supporting HWP (Hardware P-States) mode, we expected to
enumerate core priority via ACPI-CPPC tables. Unfortunately deployment of
TURBO 3.0 didn't use this method to show core priority. So users are not
able to utilize this feature in HWP mode.

So remove the loading restriction of this driver for HWP enabled systems.
Even if there are some systems, which are providing the core priority via
ACPI CPPC, this shouldn't cause any conflict as the source of priority
definition is same.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reported-and-tested-and-reviewed-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Trivial fix to spelling mistake in MODULE_PARM_DESC text and remove
unnecessary hyphen.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Fixed a mistake in which several entries were duplicated in the DMI list
from the below commit
fe486138 platform/x86: dell-laptop: Add 2-in-1 devices to the DMI whitelist
Signed-off-by: Alexander Abrosimov <alexander.n.abrosimov@gmail.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Commit 9862b436 ("platform/x86: dell-laptop: Allocate buffer on heap
rather than globally")
broke one request, changed it back to the original value.

Tested on a Dell E6540, backlight came back.

Fixes: 9862b436 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally")
Signed-off-by: Laszlo Toth <laszlth@gmail.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Lenovo E41-20 needs more time than 100ms to read VPC,
the funtion keys always failed responding.
Increase timeout to get the value from VPC, then
the funtion keys like mic mute key work well.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

wmi_dev_probe() allocates one byte less than necessary, thus
subsequent sprintf() call writes trailing zero past the end
of the 'buf':

    BUG: KASAN: slab-out-of-bounds in vsnprintf+0xda4/0x1240
    Write of size 1 at addr ffff880423529caf by task kworker/1:1/32

    Call Trace:
     dump_stack+0xb3/0x14d
     print_address_description+0xd7/0x380
     kasan_report+0x166/0x2b0
     vsnprintf+0xda4/0x1240
     sprintf+0x9b/0xd0
     wmi_dev_probe+0x1c3/0x400
     driver_probe_device+0x5d1/0x990
     bus_for_each_drv+0x109/0x190
     __device_attach+0x217/0x360
     bus_probe_device+0x1ad/0x260
     deferred_probe_work_func+0x10f/0x5d0
     process_one_work+0xa8b/0x1dc0
     worker_thread+0x20d/0x17d0
     kthread+0x311/0x3d0
     ret_from_fork+0x3a/0x50

    Allocated by task 32:
     kasan_kmalloc+0xa0/0xd0
     __kmalloc+0x14f/0x3e0
     wmi_dev_probe+0x182/0x400
     driver_probe_device+0x5d1/0x990
     bus_for_each_drv+0x109/0x190
     __device_attach+0x217/0x360
     bus_probe_device+0x1ad/0x260
     deferred_probe_work_func+0x10f/0x5d0
     process_one_work+0xa8b/0x1dc0
     worker_thread+0x20d/0x17d0
     kthread+0x311/0x3d0
     ret_from_fork+0x3a/0x50

Increment allocation size to fix this.

Fixes: 44b6b766 ("platform/x86: wmi: create userspace interface for drivers")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

except, again, POLLFREE and POLL_BUSY_LOOP.

With this, we finally get to the promised end result:

 - POLL{IN,OUT,...} are plain integers and *not* in __poll_t, so any
   stray instances of ->poll() still using those will be caught by
   sparse.

 - eventpoll.c and select.c warning-free wrt __poll_t

 - no more kernel-side definitions of POLL... - userland ones are
   visible through the entire kernel (and used pretty much only for
   mangle/demangle)

 - same behavior as after the first series (i.e. sparc et.al. epoll(2)
   working correctly).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>