The microphone mute key is missing from sparse keymap. It is present on
FX505GM and possibly other laptops. Add the missing code.

Also, comment on the fan mode switch key, which has the same code as the
already used key.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Event codes are expected to be retrieved from a queue on at least some
models. Specifically, very likely the ACPI WMI devices with _UID ATK are
queued whereas those with ASUSWMI are not [1].

The WMI event codes are pushed into a circular buffer queue. After the INIT
method is called, ACPI code is allowed to push events into this buffer.
The INIT method cannot be reverted. If the module is unloaded and an event
(such as hotkey press) gets emitted before inserting it back the events get
processed delayed by one or if the queue overflows, additionally delayed by
about 3 seconds.

It might be considered a minor issue and no normal user would likely
observe this (there is little reason unloading the driver), but it does
significantly frustrate a developer who is unlucky enough to encounter
this. Therefore, the fallback to unqueued behavior occurs whenever
something unexpected happens.

The fix flushes the old key codes out of the queue on load. After receiving
event the queue is read until either ..FFFF or 1 is encountered. Also as
noted in [1] it is checked whether notify code is equal to 0xFF before
enabling queue processing in WMI notify handler.

DSDT examples:

FX505GM
Device (ATKD)
{ ..
    Name (ATKQ, Package (0x10)
    {
        0xFFFFFFFF, ..
    }

    Method (IANQ, 1, Serialized)
    {
        If ((AQNO >= 0x10))
        {
            Local0 = 0x64
            While ((Local0 && (AQNO >= 0x10)))
            {
                Local0--
                Sleep (0x0A)
            }
            ...
        ..
        AQTI++
        AQTI &= 0x0F
        ATKQ [AQTI] = Arg0
        ...
    }

    Method (GANQ, 0, Serialized)
    {
        ..
        If (AQNO)
        {
            ...
            Local0 = DerefOf (ATKQ [AQHI])
            AQHI++
            AQHI &= 0x0F
            Return (Local0)
        }

        Return (One)
    }

This code is almost identical to K54C, which does return Ones on empty
queue.

K54C:
Method (GANQ, 0, Serialized)
{
    If (AQNO)
    {
        ...
        Return (Local0)
    }

    Return (Ones)
}

[1] Link: https://lkml.org/lkml/2019/4/12/104Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Suggested-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Refactor WMI event handling into separate functions for getting the event
code and handling the retrieved event code as a preparation for
introduction of WMI event queue support.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The DSTS method detection mistakenly selects DCTS instead of DSTS if
nothing is returned when the method ID is not defined in WMNB. As a result,
the control of keyboard backlight is not functional for TUF Gaming series
laptops. Implement detection based on _UID of the WMI device instead.

There is evidence that DCTS is handled by ACPI WMI devices that have _UID
ASUSWMI, whereas none of the devices without ASUSWMI respond to DCTS and
DSTS is used instead [1].

DSDT examples:

FX505GM (_UID ATK):
Method (WMNB, 3, Serialized)
{ ...
    If ((Local0 == 0x53545344))
    {
        ...
        Return (Zero)
    }
    ...
    // No return
}

K54C (_UID ATK):
Method (WMNB, 3, Serialized)
{ ...
    If ((Local0 == 0x53545344))
    {
        ...
        Return (0x02)
    }
    ...
    Return (0xFFFFFFFE)
}

[1] Link: https://lkml.org/lkml/2019/4/11/322Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Suggested-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add a new function to acpi.h / wmi.c that returns _UID of the ACPI WMI
device. For example, it returns "ATK" for the following declaration in
DSDT:
Device (ATKD)
{
    Name (_HID, "PNP0C14" /* Windows Management Instrumentation Device */)
      // _HID: Hardware ID
    Name (_UID, "ATK")  // _UID: Unique ID
    ..

Generally, it is possible that multiple PNP0C14 ACPI devices are present in
the system as mentioned in the commit message of commit bff431e4
("ACPI: WMI: Add ACPI-WMI mapping driver").

Therefore the _UID is returned for a specific ACPI device that declares the
given GUID, to which it is also mapped by other methods of wmi module.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The asus-nb-wmi driver is matched by WMI alias but fails to load on TUF
Gaming series laptops producing multiple ACPI errors in the kernel log.

The input buffer for WMI method invocation size is 2 dwords, whereas
3 are expected by this model.

FX505GM:
..
Method (WMNB, 3, Serialized)
{
    P8XH (Zero, 0x11)
    CreateDWordField (Arg2, Zero, IIA0)
    CreateDWordField (Arg2, 0x04, IIA1)
    CreateDWordField (Arg2, 0x08, IIA2)
    Local0 = (Arg1 & 0xFFFFFFFF)
    ...

Compare with older K54C:
...
Method (WMNB, 3, NotSerialized)
{
    CreateDWordField (Arg2, 0x00, IIA0)
    CreateDWordField (Arg2, 0x04, IIA1)
    Local0 = (Arg1 & 0xFFFFFFFF)
    ...

Increase buffer size to 3 dwords. No negative consequences of this change
are expected, as the input buffer size is not verified. The original
function is replaced by a wrapper for a new method passing value 0 for the
last parameter. The new function will be used to control RGB keyboard
backlight.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The error code and return value are mixed up. The intensity is always set
to 0 on load as kbd_led_read returns either 0 or negative value. To
reproduce set backlight to maximum, reload driver and try to increase it
using keyboard hotkey, the intensity will drop as a result. Correct the
implementation.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The driver does not clean up the hwmon device on exit or error. To
reproduce the bug, repeat rmmod, insmod to verify that device number
/sys/devices/platform/asus-nb-wmi/hwmon/hwmon?? grows every time. Replace
call for registering device with devm_* version that unregisters it
automatically.
Signed-off-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
Cc: "David E. Box" <david.e.box@linux.intel.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Ike Panhc <ike.pan@canonical.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: acpi4asus-user@lists.sourceforge.net
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Also, because there is no need to save the file dentry, remove the
variable that was saving it and just recursively delete the whole
directory.

Cc: "Lee, Chun-Yi" <jlee@suse.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

HP ProBook 450 G0 needs a non-standard mapping (x_inverted).
Signed-off-by: NColin Sindle <csindle@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Fix sparse warnings:

drivers/platform/x86/pcengines-apuv2.c:80:27: warning: symbol 'gpios_led_table' was not declared. Should it be static?
drivers/platform/x86/pcengines-apuv2.c:113:27: warning: symbol 'gpios_key_table' was not declared. Should it be static?
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Acked-By: NEnrico Weigelt, metux IT consult <info@metux.net>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Fix a null pointer deference by acpi_driver_data() if device is
null (dereference before check). We should only set cdev and check
this is OK after we are sure device is not null.
Signed-off-by: NYoung Xiao <92siuyang@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The CONFIG_BACKLIGHT_LCD_SUPPORT was removed in commit 8c5dc8d9
("video: backlight: Remove useless BACKLIGHT_LCD_SUPPORT kernel
symbol"). Options protected by CONFIG_BACKLIGHT_LCD_SUPPORT are now
available directly.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Added touch screen info for CHUWI Hi10 Plus tablet.
Signed-off-by: NDaniel Smith <danct12@disroot.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add devm_free_irq() call to mlxreg-hotplug remove() for clean release
of devices irq resource. Fix debugobjects warning triggered by rmmod
It prevents of use-after-free memory, related to
mlxreg_hotplug_work_handler.

Issue has been reported as debugobjects warning triggered by
'rmmod mlxtreg-hotplug' flow, while running kernel with
CONFIG_DEBUG_OBJECTS* options.

[ 2489.623551] ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler+0x0/0x7f0 [mlxreg_hotplug]
[ 2489.637097] WARNING: CPU: 5 PID: 3924 at lib/debugobjects.c:328 debug_print_object+0xfe/0x180
[ 2489.637165] RIP: 0010:debug_print_object+0xfe/0x180
?
[ 2489.637214] Call Trace:
[ 2489.637225]  __debug_check_no_obj_freed+0x25e/0x320
[ 2489.637231]  kfree+0x82/0x110
[ 2489.637238]  release_nodes+0x33c/0x4e0
[ 2489.637242]  ? devres_remove_group+0x1b0/0x1b0
[ 2489.637247]  device_release_driver_internal+0x146/0x270
[ 2489.637251]  driver_detach+0x73/0xe0
[ 2489.637254]  bus_remove_driver+0xa1/0x170
[ 2489.637261]  __x64_sys_delete_module+0x29e/0x320
[ 2489.637265]  ? __ia32_sys_delete_module+0x320/0x320
[ 2489.637268]  ? blkcg_exit_queue+0x20/0x20
[ 2489.637273]  ? task_work_run+0x7d/0x100
[ 2489.637278]  ? exit_to_usermode_loop+0x5b/0xf0
[ 2489.637281]  do_syscall_64+0x73/0x160
[ 2489.637287]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2489.637290] RIP: 0033:0x7f95c3596fd7

The difference in release flow with and with no devm_free_irq is listed
below:

bus: 'platform': remove driver mlxreg-hotplug
 mlxreg_hotplug_remove(start)
					-> devm_free_irq (with new code)
 mlxreg_hotplug_remove (end)
 release_nodes (start)
  mlxreg-hotplug: DEVRES REL devm_hwmon_release (8 bytes)
  device: 'hwmon3': device_unregister
  PM: Removing info for No Bus:hwmon3
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (88 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (6 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
  mlxreg-hotplug: DEVRES REL devm_irq_release (16 bytes) (no new code)
  mlxreg-hotplug: DEVRES REL devm_kzalloc_release (1376 bytes)
   ------------[ cut here ]------------ (no new code):
   ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler

 release_nodes(end)
driver: 'mlxreg-hotplug': driver_release

Fixes: 1f976f69 ("platform/x86: Move Mellanox platform hotplug driver to platform/mellanox")
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Fix the issue found while running kernel with the option
CONFIG_DEBUG_TEST_DRIVER_REMOVE.
Driver 'mlx-platform' registers 'i2c_mlxcpld' device and then registers
few underlying 'i2c-mux-reg' devices:
	priv->pdev_i2c = platform_device_register_simple("i2c_mlxcpld", nr,
							 NULL, 0);
	...
	for (i = 0; i < ARRAY_SIZE(mlxplat_mux_data); i++) {
		priv->pdev_mux[i] = platform_device_register_resndata(
						&mlxplat_dev->dev,
						"i2c-mux-reg", i, NULL,
						0, &mlxplat_mux_data[i],
						sizeof(mlxplat_mux_data[i]));

But actual parent of "i2c-mux-reg" device is priv->pdev_i2c->dev and
not mlxplat_dev->dev.
Patch fixes parent device parameter in a call to
platform_device_register_resndata() for "i2c-mux-reg".

It solves the race during initialization flow while 'i2c_mlxcpld.1' is
removing after probe, while 'i2c-mux-reg.0' is still in probing flow:
'i2c_mlxcpld.1'	flow:	probe -> remove -> probe.
'i2c-mux-reg.0'	flow:		  probe -> ...

[   12:621096] Registering platform device 'i2c_mlxcpld.1'. Parent at platform
[   12:621117] device: 'i2c_mlxcpld.1': device_add
[   12:621155] bus: 'platform': add device i2c_mlxcpld.1
[   12:621384] Registering platform device 'i2c-mux-reg.0'. Parent at mlxplat
[   12:621395] device: 'i2c-mux-reg.0': device_add
[   12:621425] bus: 'platform': add device i2c-mux-reg.0
[   12:621806] Registering platform device 'i2c-mux-reg.1'. Parent at mlxplat
[   12:621828] device: 'i2c-mux-reg.1': device_add
[   12:621892] bus: 'platform': add device i2c-mux-reg.1
[   12:621906] bus: 'platform': add driver i2c_mlxcpld
[   12:621996] bus: 'platform': driver_probe_device: matched device i2c_mlxcpld.1 with driver i2c_mlxcpld
[   12:622003] bus: 'platform': really_probe: probing driver i2c_mlxcpld with device i2c_mlxcpld.1
[   12:622100] i2c_mlxcpld i2c_mlxcpld.1: no default pinctrl state
[   12:622293] device: 'i2c-1': device_add
[   12:627280] bus: 'i2c': add device i2c-1
[   12:627692] device: 'i2c-1': device_add
[   12.629639] bus: 'platform': add driver i2c-mux-reg
[   12.629718] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
[   12.629723] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
[   12.629818] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[   12.629981] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral
[   12.629986] platform i2c-mux-reg.0: Added to deferred list
[   12.629992] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg
[   12.629997] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1
[   12.630091] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[   12.630247] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral
[   12.630252] platform i2c-mux-reg.1: Added to deferred list
[   12.640892] devices_kset: Moving i2c-mux-reg.0 to end of list
[   12.640900] platform i2c-mux-reg.0: Retrying from deferred list
[   12.640911] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
[   12.640919] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
[   12.640999] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[   12.641177] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral
[   12.641187] platform i2c-mux-reg.0: Added to deferred list
[   12.641198] devices_kset: Moving i2c-mux-reg.1 to end of list
[   12.641219] platform i2c-mux-reg.1: Retrying from deferred list
[   12.641237] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg
[   12.641247] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1
[   12.641331] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
[   12.641465] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral
[   12.641469] platform i2c-mux-reg.1: Added to deferred list
[   12.646427] device: 'i2c-1': device_add
[   12.646647] bus: 'i2c': add device i2c-1
[   12.647104] device: 'i2c-1': device_add
[   12.669231] devices_kset: Moving i2c-mux-reg.0 to end of list
[   12.669240] platform i2c-mux-reg.0: Retrying from deferred list
[   12.669258] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
[   12.669263] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
[   12.669343] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
[   12.669585] device: 'i2c-2': device_add
[   12.669795] bus: 'i2c': add device i2c-2
[   12.670201] device: 'i2c-2': device_add
[   12.671427] i2c i2c-1: Added multiplexed i2c bus 2
[   12.671514] device: 'i2c-3': device_add
[   12.671724] bus: 'i2c': add device i2c-3
[   12.672136] device: 'i2c-3': device_add
[   12.673378] i2c i2c-1: Added multiplexed i2c bus 3
[   12.673472] device: 'i2c-4': device_add
[   12.673676] bus: 'i2c': add device i2c-4
[   12.674060] device: 'i2c-4': device_add
[   12.675861] i2c i2c-1: Added multiplexed i2c bus 4
[   12.675941] device: 'i2c-5': device_add
[   12.676150] bus: 'i2c': add device i2c-5
[   12.676550] device: 'i2c-5': device_add
[   12.678103] i2c i2c-1: Added multiplexed i2c bus 5
[   12.678193] device: 'i2c-6': device_add
[   12.678395] bus: 'i2c': add device i2c-6
[   12.678774] device: 'i2c-6': device_add
[   12.679969] i2c i2c-1: Added multiplexed i2c bus 6
[   12.680065] device: 'i2c-7': device_add
[   12.680275] bus: 'i2c': add device i2c-7
[   12.680913] device: 'i2c-7': device_add
[   12.682506] i2c i2c-1: Added multiplexed i2c bus 7
[   12.682600] device: 'i2c-8': device_add
[   12.682808] bus: 'i2c': add device i2c-8
[   12.683189] device: 'i2c-8': device_add
[   12.683907] device: 'i2c-1': device_unregister
[   12.683945] device: 'i2c-1': device_unregister
[   12.684387] device: 'i2c-1': device_create_release
[   12.684536] bus: 'i2c': remove device i2c-1
[   12.686019] i2c i2c-8: Failed to create compatibility class link
[   12.686086] ------------[ cut here ]------------
[   12.686087] can't create symlink to mux device
[   12.686224] Workqueue: events deferred_probe_work_func
[   12.686135] WARNING: CPU: 7 PID: 436 at drivers/i2c/i2c-mux.c:416 i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux]
[   12.686232] RIP: 0010:i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux]
[   0x190/0x190 [i2c_mux]
[   12.686300]  ? i2c_mux_alloc+0xac/0x110 [i2c_mux]
[   12.686306]  ? i2c_mux_reg_set+0x200/0x200 [i2c_mux_reg]
[   12.686313]  i2c_mux_reg_probe+0x22c/0x731 [i2c_mux_reg]
[   12.686322]  ? i2c_mux_reg_deselect+0x60/0x60 [i2c_mux_reg]
[   12.686346]  platform_drv_probe+0xa8/0x110
[   12.686351]  really_probe+0x185/0x720
[   12.686358]  driver_probe_device+0xdf/0x1f0
...
[   12.686522] i2c i2c-1: Added multiplexed i2c bus 8
[   12.686621] device: 'i2c-9': device_add
[   12.686626] kobject_add_internal failed for i2c-9 (error: -2 parent: i2c-1)
[   12.694729] i2c-core: adapter 'i2c-1-mux (chan_id 8)': can't register device (-2)
[   12.705726] i2c i2c-1: failed to add mux-adapter 8 as bus 9 (error=-2)
[   12.714494] device: 'i2c-8': device_unregister
[   12.714537] device: 'i2c-8': device_unregister

Fixes: 6613d18e ("platform/x86: mlx-platform: Move module from arch/x86")
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When a switch event, such as tablet mode/laptop mode or docked/undocked,
wakes a device make sure that the value of the swich is reported.
Without when a device is put in tablet mode from laptop mode when it is
suspended or vice versa the device will wake up but mode will be
incorrect.

Tested by suspending a device in laptop mode and putting it in tablet
mode, the device resumes and is in tablet mode. When suspending the
device in tablet mode and putting it in laptop mode the device resumes
and is in laptop mode.
Signed-off-by: NMathew King <mathewk@chromium.org>
Reviewed-by: NJett Rink <jettrink@chromium.org>
Reviewed-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Commit 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will
handle the display off hotkey") causes the backlight to be permanently off
on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC
1015BX, Asus EeePC 1025C).

The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added
by that commit is made conditional in this commit and only enabled in
the quirk_entry structs in the asus-nb-wmi driver fixing the broken
display / backlight on various EeePC laptop models.

Cc: João Paulo Rechi Vita <jprvita@endlessm.com>
Fixes: 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Randy Dunlap says:

  drivers/platform/olpc/Kconfig needs to use "menuconfig" like all of the
  other Kconfig files in drivers/platform/ so that its menu is listed in
  the correct place in *config interfaces.

Otherwise he's sad.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

ERROR: "power_supply_put" [drivers/platform/olpc/olpc-xo175-ec.ko] undefined!
  ERROR: "power_supply_changed" [drivers/platform/olpc/olpc-xo175-ec.ko] undefined!
  ERROR: "power_supply_get_by_name" [drivers/platform/olpc/olpc-xo175-ec.ko] undefined!

Adding the dependency seems like a more reasonable thing compared to
ifdef-ing the bits, as if one has an XO-1.75 they almost certainly want
a baterry and AC adapter support.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Reset the ret variable to make sure it olpc_xo175_ec_cmd() ends up
returning zero on success.

Fixes: 0c3d931b ("Platform: OLPC: Add XO-1.75 EC driver")
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Addresses a kbuild warning:

  >> WARNING: vmlinux.o(.text+0x3b764): Section mismatch in reference from
              the function olpc_dt_compatible_match() to the function
              .init.text:olpc_dt_getproperty()
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reported-by: Nkbuild test robot <lkp@intel.com>
Fixes: a7a9bacb (x86/platform/olpc: Use a correct version when making up a battery node)
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Building with CONFIG_INPUT set to m:

drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_complete':
olpc-xo175-ec.c:(.text+0x75d): undefined reference to `input_event'
olpc-xo175-ec.c:(.text+0x76f): undefined reference to `input_event'
olpc-xo175-ec.c:(.text+0x787): undefined reference to `input_event'
olpc-xo175-ec.c:(.text+0x799): undefined reference to `input_event'
drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_probe':
olpc-xo175-ec.c:(.text+0x8d5): undefined reference to `devm_input_allocate_device'
olpc-xo175-ec.c:(.text+0x910): undefined reference to `input_set_capability'
olpc-xo175-ec.c:(.text+0x91c): undefined reference to `input_register_device'

This patch add INPUT dependencies to fix this.
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: 0c3d931b ("Platform: OLPC: Add XO-1.75 EC driver")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Fix gcc build error while CONFIG_SPI is not set

drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_remove':
olpc-xo175-ec.c:(.text+0x190): undefined reference to `spi_slave_abort'
drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_send_command':
olpc-xo175-ec.c:(.text+0x374): undefined reference to `spi_async'
drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_cmd':
olpc-xo175-ec.c:(.text+0x8a0): undefined reference to `spi_slave_abort'
drivers/platform/olpc/olpc-xo175-ec.o: In function `olpc_xo175_ec_spi_driver_init':
olpc-xo175-ec.c:(.init.text+0x14): undefined reference to `__spi_register_driver'

We should depends on CONFIG_SPI_SLAVE other than directly select it.
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: 0c3d931b ("Platform: OLPC: Add XO-1.75 EC driver")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

With the recent changes to the driver and addition of OLPC XO-1.75 EC
driver it is possible to use this driver on ARM-based XO laptops as
well.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

All OLPC ECs are able to turn the power to the DCON on an off. Use the
regulator framework to expose the functionality.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

It's based off the driver from the OLPC kernel sources. Somewhat
modernized and cleaned up, for better or worse.

Modified to plug into the olpc-ec driver infrastructure (so that battery
interface and debugfs could be reused) and the SPI slave framework.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Just a cosmetic tidy-up.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Just return EPROBE_DEFER, so that whoever attempted to use the EC call can
defer their work.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Move the olpc-ec driver away from the X86 OLPC platform so that it could be
used by the ARM based laptops too. Notably, the driver for the OLPC battery,
which is also used on the ARM models, builds on this driver's interface.

It is actually plaform independent: the OLPC EC commands with their argument
and responses are mostly the same despite the delivery mechanism is
different.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Also, the header is x86 specific, while there are non-x86 OLPC machines.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra
signals for handshaking. It needs to know when is the slave (Linux)
side's TX FIFO ready for transfer (the ready-gpio signal on the SPI
controller node) and when does it wish to respond with a command (the
cmd-gpio property).
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

There are several Beckhoff Automation industrial PC boards which use
pmc_plt_clk* clocks for ethernet controllers. This adds affected boards
to critclk_systems DMI table so the clocks are marked as CLK_CRITICAL and
not turned off.

Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: NSteffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>