Fix return code check for "max brightness" ACPI call.
The Dell laptop ACPI video brightness control is not present on dell
laptops anymore, but was present in older kernel versions.
The code that checks the return value is incorrect since the SMM
refactoring.
The old code was:
if (buffer->output[0] == 0)
Which was changed to:
ret = dell_send_request(...)
if (ret)
However, dell_send_request() will return 0 if buffer->output[0] == 0,
so we must change the check to:
if (ret == 0)
This issue was found on a Dell M4800 laptop, and the fix tested on it
as well.
Fixes: 549b4930f0 ("dell-smbios: Introduce dispatcher for SMM calls")
Signed-off-by: Damien Thébault <damien@dtbo.net>
Tested-by: Damien Thébault <damien@dtbo.net>
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>
As files move around, their previous links break. Fix the
references for them.
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Several incremental improvements including new keycodes, new models, new
quirks, and related documentation. Adds LED platform driver activation
for Mellanox systems. Some minor optimizations and cleanups. Includes
several bug fixes, message silencing, mostly minor.
The following commits were previously merged during the 4.17 RC cycle:
- 06b8b00b33 platform/x86: asus-wireless: Fix NULL pointer dereference
- 6ed66c3ce0 platform/x86: Kconfig: Fix dell-laptop dependency chain.
- 74783c99bf platform/x86: DELL_WMI use depends on instead of select for DELL_SMBIOS
- cf48bf9eee platform/x86: asus-wmi: Fix NULL pointer dereference
The following is an automated git shortlog grouped by driver:
acer-wmi:
- add another KEY_POWER keycode
apple-gmux:
- fix gmux_get_client_id()'s return type
asus-laptop:
- Simplify getting .drvdata
asus-wireless:
- Fix format specifier
dell-laptop:
- Fix keyboard backlight timeout on XPS 13 9370
dell-smbios:
- Match on www.dell.com in OEM strings too
dell-wmi:
- Ignore new rfkill and fn-lock events
- Set correct keycode for Fn + left arrow
fujitsu-laptop:
- Simplify soft key handling
ideapad-laptop:
- Add E42-80 to no_hw_rfkill
- Add fn-lock setting
- Add MIIX 720-12IKB to no_hw_rfkill
lib/string_helpers:
- Add missed declaration of struct task_struct
intel_scu_ipc:
- Replace mdelay with usleep_range in intel_scu_ipc_i2c_cntrl
mlx-platform:
- Add LED platform driver activation
platform/mellanox:
- Add new ODM system types to mlx-platform
- mlxreg-hotplug: add extra cycle for hotplug work queue
- mlxreg-hotplug: Document fixes for hotplug private data
platform_data/mlxreg:
- Document fixes for hotplug device
silead_dmi:
- Add entry for Chuwi Hi8 tablet touchscreen
- Add touchscreen info for the Onda V891w tablet
- Add info for the PoV mobii TAB-P800W (v2.0)
- Add touchscreen info for the Jumper EZpad 6 Pro
thinkpad_acpi:
- silence false-positive-prone pr_warn
- do not report thermal sensor state for tablet mode switch
- silence HKEY 0x6032, 0x60f0, 0x6030
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbIFzqAAoJEKbMaAwKp3644JcIAJ8iBMobacNWjIJvPJ8ytwLE
NUP7/W/8NUXkwnxXzURorlnoO6Uj4+54c+QfO+HQV/+Y46fJaX9x2tWRtcEkpJU3
L6c59kYAMlu5rN5ekCcQex4FKL8Pd7q6QpF8KZtP8gw2ujUEeGA1m/qcTmUlkOQF
AFfbSFJtmMOinbL5ufkaW7Gu91EVFhuvgIoK/XdOhwAbyYAPEbtttKlUjkZGx6GU
iJbpimcmdtfXBqMzvpOHw/4EUXLwgDVr1F8PdGmvEHyK45SHIZcK936Ihiq+CjVA
USFKZhMMYU4sifI77pIP9Trftm+FdaLnPumGVj836OMp1+k10YBy1hDIGwI6i68=
=+O74
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v4.18-1' of git://git.infradead.org/linux-platform-drivers-x86
Pull x86 platform driver updates from Darren Hart:
"Several incremental improvements including new keycodes, new models,
new quirks, and related documentation. Adds LED platform driver
activation for Mellanox systems. Some minor optimizations and
cleanups. Includes several bug fixes, message silencing, mostly minor
Automated summary:
acer-wmi:
- add another KEY_POWER keycode
apple-gmux:
- fix gmux_get_client_id()'s return type
asus-laptop:
- Simplify getting .drvdata
asus-wireless:
- Fix format specifier
dell-laptop:
- Fix keyboard backlight timeout on XPS 13 9370
dell-smbios:
- Match on www.dell.com in OEM strings too
dell-wmi:
- Ignore new rfkill and fn-lock events
- Set correct keycode for Fn + left arrow
fujitsu-laptop:
- Simplify soft key handling
ideapad-laptop:
- Add E42-80 to no_hw_rfkill
- Add fn-lock setting
- Add MIIX 720-12IKB to no_hw_rfkill
lib/string_helpers:
- Add missed declaration of struct task_struct
intel_scu_ipc:
- Replace mdelay with usleep_range in intel_scu_ipc_i2c_cntrl
mlx-platform:
- Add LED platform driver activation
platform/mellanox:
- Add new ODM system types to mlx-platform
- mlxreg-hotplug: add extra cycle for hotplug work queue
- mlxreg-hotplug: Document fixes for hotplug private data
platform_data/mlxreg:
- Document fixes for hotplug device
silead_dmi:
- Add entry for Chuwi Hi8 tablet touchscreen
- Add touchscreen info for the Onda V891w tablet
- Add info for the PoV mobii TAB-P800W (v2.0)
- Add touchscreen info for the Jumper EZpad 6 Pro
thinkpad_acpi:
- silence false-positive-prone pr_warn
- do not report thermal sensor state for tablet mode switch
- silence HKEY 0x6032, 0x60f0, 0x6030"
* tag 'platform-drivers-x86-v4.18-1' of git://git.infradead.org/linux-platform-drivers-x86: (30 commits)
platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
platform/x86: dell-laptop: Fix keyboard backlight timeout on XPS 13 9370
platform/x86: dell-wmi: Ignore new rfkill and fn-lock events
platform/x86: mlx-platform: Add LED platform driver activation
platform/mellanox: Add new ODM system types to mlx-platform
platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue
platform/x86: ideapad-laptop: Add E42-80 to no_hw_rfkill
platform/x86: silead_dmi: Add touchscreen info for the Onda V891w tablet
platform/x86: silead_dmi: Add info for the PoV mobii TAB-P800W (v2.0)
platform/x86: silead_dmi: Add touchscreen info for the Jumper EZpad 6 Pro
platform/x86: asus-wireless: Fix format specifier
platform/x86: asus-wmi: Fix NULL pointer dereference
platform/x86: dell-wmi: Set correct keycode for Fn + left arrow
platform/x86: acer-wmi: add another KEY_POWER keycode
platform/x86: ideapad-laptop: Add fn-lock setting
platform/x86: ideapad-laptop: Add MIIX 720-12IKB to no_hw_rfkill
lib/string_helpers: Add missed declaration of struct task_struct
platform/x86: DELL_WMI use depends on instead of select for DELL_SMBIOS
platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data
platform_data/mlxreg: Document fixes for hotplug device
...
Here is the big USB pull request for 4.18-rc1.
Lots of stuff here, the highlights are:
- phy driver updates and new additions
- usual set of xhci driver updates
- normal set of musb updates
- gadget driver updates and new controllers
- typec work, it's getting closer to getting fully out of the
staging portion of the tree.
- lots of minor cleanups and bugfixes.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWxba6w8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykumQCg2abWE5LijR0SNJIwX8xk64HLUAMAnAxBZDG3
aB0GyOQd54L+09q4LAdn
=ZCEx
-----END PGP SIGNATURE-----
Merge tag 'usb-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB and PHY updates from Greg KH:
"Here is the big USB pull request for 4.18-rc1.
Lots of stuff here, the highlights are:
- phy driver updates and new additions
- usual set of xhci driver updates
- normal set of musb updates
- gadget driver updates and new controllers
- typec work, it's getting closer to getting fully out of the staging
portion of the tree.
- lots of minor cleanups and bugfixes.
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (263 commits)
Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"
xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers
xhci: Allow more than 32 quirks
usb: xhci: force all memory allocations to node
selftests: add test for USB over IP driver
USB: typec: fsusb302: no need to check return value of debugfs_create_dir()
USB: gadget: udc: s3c2410_udc: no need to check return value of debugfs_create functions
USB: gadget: udc: renesas_usb3: no need to check return value of debugfs_create functions
USB: gadget: udc: pxa27x_udc: no need to check return value of debugfs_create functions
USB: gadget: udc: gr_udc: no need to check return value of debugfs_create functions
USB: gadget: udc: bcm63xx_udc: no need to check return value of debugfs_create functions
USB: udc: atmel_usba_udc: no need to check return value of debugfs_create functions
USB: dwc3: no need to check return value of debugfs_create functions
USB: dwc2: no need to check return value of debugfs_create functions
USB: core: no need to check return value of debugfs_create functions
USB: chipidea: no need to check return value of debugfs_create functions
USB: ehci-hcd: no need to check return value of debugfs_create functions
USB: fhci-hcd: no need to check return value of debugfs_create functions
USB: fotg210-hcd: no need to check return value of debugfs_create functions
USB: imx21-hcd: no need to check return value of debugfs_create functions
...
Further changes from Dmitry related to the removal of platform data from
atmel_mxt_ts and chromeos_laptop. This time, we have some changes that
teach chromeos_laptop how to supply acpi properties for some input devices
so that the peripheral driver doesn't have to do dmi matching on some
Chromebook platforms.
Also adds the Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.
Other misc. cleanup.
Thanks,
Benson
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6gYDF28Li+nEiKLaHwn1ewov5lgFAlsUrmMACgkQHwn1ewov
5ljpzRAAqgscZzPqHZNOtLC/QXsohdCKnbfjVL1Nd+xor773kJwA0jJVU6fSfvzx
sxqQkRUno3aFD3TeKzRVY+jBXzb8hkYUpIfvT2Fl3fGK26NIFaB+F0wqqwZZcyOt
36lR7Ngtun3HvrxxiJ8utQeF4z5fofpWRwSGzE+ADalBr47NSIBM2JofcWmo35tk
pw0wkZvvJhzSlouF4JW8ca6LjPpk6Ngw2988HEDzyXlYGwdS/IXGjriMQ5AIiRuE
qAFtydRYYcBfZ9IH7O3Utmq74mDg+UXcFjnnt8lrvbca8QiPRWvblxwkQ5alpbPQ
x/HS9dJqkPfy5xskKiivDSKCtYXSNi5E15crcbhreiZwSlX2ictVIYu9zEo2KYCh
aD0Ba1iCQVCs8uXdoIqIh92LDLzgkr8L7kjqqFwDWpQeEH5LGYtOaHD17e5vIBc8
dllkAiJfRPVtcJtdZgUkW7NwKl8CdKFAMi2X5owYCyEsPgwUtpi2xfO6xSpA2gWl
+srbY22RTcwmMgds0kktS46GgbW73rdFxEIlbeR6moaO6GUEILicsxu6BzvXYxuj
pfsjAt1CP50Hy1kInyiFjtgEwIEv0vbr39DsZNTWWjMFXlZHzmOc8JbjFK1lb+Kw
Hh2x31BtXHA4pFyk2DUem9ctqybDZePt1vlN5QYz7WjHzMeJRqg=
=mA72
-----END PGP SIGNATURE-----
Merge tag 'chrome-platform-for-linus-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform
Pull chrome platform updates from Benson Leung:
- further changes from Dmitry related to the removal of platform data
from atmel_mxt_ts and chromeos_laptop.
This time, we have some changes that teach chromeos_laptop how to
supply acpi properties for some input devices so that the peripheral
driver doesn't have to do dmi matching on some Chromebook platforms.
- new Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.
- other misc cleanup
* tag 'chrome-platform-for-linus-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform:
platform/chrome: Use to_cros_ec_dev more broadly
platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes
platform: chrome: Add input dependency for tablet switch driver
platform/chrome: chromeos_laptop - supply properties for ACPI devices
platform/chrome: chromeos_tbmc - add SPDX identifier
platform: chrome: Add Tablet Switch ACPI driver
platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found
The XPS 13 9370 doesn't expose the necessary KBD_LED_AC_TOKEN in
the BIOS, so the driver thinks it cannot adjust the AC keyboard
backlight timeout. This patch adds a quirk to fix this until
Dell adds the missing token to the BIOS.
For further discussion, see:
https://github.com/dell/libsmbios/issues/48
Signed-off-by: Timur Kristóf <venemo@fedoraproject.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
There are two new events generated by dell-wmi, rfkill and fn-lock, from
Dell Systems.
When Fn-lock hotkey gets pressed to switch to function mode:
[85951.591542] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85951.591546] dell_wmi: Unknown key with type 0x0010 and code 0x0000
pressed
When Fn-lock hotkey gets pressed to switch to multimedia mode:
[85956.667686] dell_wmi: Unknown key with type 0x0010 and code 0xe035
pressed
[85956.667690] dell_wmi: Unknown key with type 0x0010 and code 0x0001
pressed
When radio hotkey gets pressed:
[85974.430220] dell_wmi: Unknown key with type 0x0010 and code 0xe008
pressed
These events are for notification purpose, so we can ignore them.
This patch is tested on XPS 9370.
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add LED platform driver activation from mlx-platform. This LED driver uses
the same regmap infrastructure as others Mellanox platform drivers, so LED
specific registers description is added.
System LED configuration depends on system type. To support all the
relevant types per system type LED descriptions are defined for passing
to LED platform driver.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Add new ODM system types, matched according to DMI_BOARD_NAME. The
supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003, VMOD0004, VMOD0005.
Patch does not introduce new systems, but allows to ODM companies to set
DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their own. It assumes that ODM
company can't change DMI_BOARD_NAME.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Add extra cycle for hotplug work queue to handle the case when a signal is
It adds missed logic for signal acknowledge, by adding an extra run for
received, but no specific signal assertion is detected. Such case
theoretically can happen for example in case several units are removed or
inserted at the same time. In this situation acknowledge for some signal
can be missed at signal top aggreagation status level. The extra run will
allow to handler to acknowledge the missed signal.
The interrupt handling flow performs the next steps:
(1)
Enter mlxreg_hotplug_work_handler due to signal assertion.
Aggregation status register is changed for example from 0xff to 0xfd
(event signal group related to bit 1).
(2)
Mask aggregation interrupts, read aggregation status register and save it
(0xfd) in aggr_cache, then traverse down to handle signal from groups
related to the changed bit.
(3)
Read and mask group related signal.
Acknowledge and unmask group related signal (acknowledge should clear
aggregation status register from 0xfd back to 0xff).
(4)
Re-schedule work queue for the immediate execution.
(5)
Enter mlxreg_hotplug_work_handler due to re-scheduling.
Aggregation status is changed from previous 0xfd to 0xff.
Go over steps (2) - (5) and in case no new signal assertion
is detected - unmask aggregation interrupts.
The possible race could happen in case new signal from the same group is
asserted after step (3) and prior step (5). In such case aggregation
status will change back from 0xff to 0xfd and the value read from the
aggregation status register will be the same as a value saved in
aggr_cache. As a result the handler will not traverse down and signal
will stay unhandled.
Example of faulty flow:
The signal routing flow is as following (f.e. for of FANi removing):
- FAN status and event registers related bit is changed;
-- intermediate aggregation status register is changed;
--- top aggregation status register is changed;
---- interrupt routed to CPU and interrupt handler is invoked.
When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
(a1) mask top aggregation interrupt mask register;
(a2) read top aggregation interrupt status register and test to which
underling group belongs a signal (FANs in this case and is changed
from 0xff to 0xfb and 0xfb is saved as a last status value);
(b1) mask FANs interrupt mask register;
(b2) read FANs status register and test which FAN has been changed
FAN3 in this example);
(c1) perform relevant action;
<--------------- (FAN2 is removed at this point)
(b3) clear FANs interrupt event register to acknowledge FAN3 signal;
(b4) unmask FANs interrupt mask register
(a3) unmask top aggregation interrupt mask register;
An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
It should set top aggregation interrupt status register bit 6 (0xfb).
In step (a2)
(a2) read top aggregation interrupt and comparing it with saved value
does not show change (same 0xfb) and after (a2) execution jumps to
(a3) and signal leaved unhandled
The fix will enforce handler to traverse down in case the signal is
received, but signal assertion is not detected.
Fixes: 304887041d ("platform/x86: Introduce support for Mellanox hotplug driver")
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Lenovo Zhaoyang E42-80 is another Lenovo model without a hw rfkill switch,
resulting in wifi always reported as hard blocked.
Add the model to the list of models without rfkill switch.
Signed-off-by: dylanchu <chdy.uuid@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add touchscreen info for the Onda V891w 8.9" windows tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This commit adds the necessary device-properties to make the touchscreen
on Point of View mobii TAB-P800W (v2.0) tablets work.
Note that we already have an entry for the Point of View mobii
TAB-P800W (v2.1), that version uses a different digitizer and different
firmware, so the v2.0 version needs its own entry.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add touchscreen info for the Jumper EZpad 6 Pro.
Cc: zy <574249312@qq.com>
Reported-and-tested-by: zy <574249312@qq.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Fix NULL pointer dereference in asus-wmi on rfkill cleanup.
The following is an automated git shortlog grouped by driver:
asus-wmi:
- Fix NULL pointer dereference
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEhiZOUlnC9oKN3n3AmT3/83c5Sy0FAlsP6SQACgkQmT3/83c5
Sy2rGA//b4nN3aa2LAKYiMzwQUlrYY8QGxBC4VVyJB+ewTK9R0wEQbIGiwX08Ism
cz23kP5Ewn3SjKikytRBaqwZA92hkke1YSOPCXwgbLFz7e4Q7dxH+oPOxZB2dQoF
lSYe4FEh6XolsEq6aOvzGIUkQl4Ne97rpNGMozIYXnIwzlTTG/NPnwo3ghZL6YTb
XyTekpfLKUycUqKaADIkEGEAXTxDgeeoQnQLLQzBM6cuEkHAk8zyPsE1mVr9G9ns
3CCQlh4U2PFY9k2X32v5YMUrTZh1EtcVDG1gF4kV7OVFqeMjN3cQJti+W6dOjc6u
WoElplxWZ1yy5XKvyN1V4/Fm157t5Hf3BxytgHnwhfi5RvWP526alR42dfHYb6ss
desWCFPmG9nzDbzkVWZapnfVJpb9gqkyev4O9KYLk4ZJrUqEdiaumQicRAnwjwlV
NE1BYGmnj5N9EIw+k5/zYiBuAtYbtDlv5cf1EPbSMg/opXD4JZu+460Ea1y//D7N
mcq6KW6ZjFdsz9Ppw8cWcaEhTnXxYXRyT9IduIwlJ+6wttafGhFKumWMTxgu3WTj
+fhM+D+PXgFIgEoJNOVDSSK1zw2ajYzOyTXzXGo9FWxuFPIw0WfvgubArnOMTspi
kNe6WFJSpE+7UX0xCK0J00ORG6cquHVthYj+rB0seNixyM0+z78=
=GJY6
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v4.17-4' of git://git.infradead.org/linux-platform-drivers-x86
Pull x86 platform driver fix from Andy Shevchenko:
"Fix NULL pointer dereference in asus-wmi on rfkill cleanup.
The effective change is just one new condition - two lines of code.
But it required moving one static helper function, which is why the
diff looks a bit bigger"
* tag 'platform-drivers-x86-v4.17-4' of git://git.infradead.org/linux-platform-drivers-x86:
platform/x86: asus-wmi: Fix NULL pointer dereference
u64 should be printed with %llx instead of %x and cast to uint.
Signed-off-by: João Paulo Rechi Vita <jprvita@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move to_cros_ec_dev macro to cros_ec.h and use it when the private ec
object is needed from device object.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Celes has newer touch controller (compared to the controllers used in
older BayTrail-based devices) and so uses the same button mapping as
Samus.
This fixes the issue with mouse button being stuck in pressed state
after the first click.
Reported-by: Sultan Alsawaf <sultanxda@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
We should stop our worker thread while we're suspended. If we don't
then we'll get messages like:
cros-ec-spi spi5.0: spi transfer failed: -108
cros-ec-spi spi5.0: cs-deassert spi transfer failed: -108
cros-ec-ctl cros-ec-ctl.0.auto: EC communication failed
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The driver will not probe unless bq24190 is loaded, so
making it a dependency.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BayTrail-based and newer Chromebooks describe their peripherals in ACPI;
unfortunately their description is not complete, and peripherals
drivers, such as driver for Atmel Touch controllers, has to resort to
DMI-matching to configure the peripherals properly. To avoid polluting
peripheral driver code, let's teach chromeos_laptop driver to supply
missing data via generic device properties.
Note we supply "compatible" string for Atmel peripherals not because it is
needed for matching devices and driver (matching is still done on ACPI HID
entries), but because peripherals driver will be using presence of
"compatible" property to determine if device properties have been attached
to the device, and fail to bind if they are absent.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Replace the original license statement with the SPDX identifier.
Add also one line of description as recommended by the COPYING file.
Signed-off-by: Benson Leung <bleung@chromium.org>
Add a kernel driver for GOOG0006, an ACPI driver reporting an event when
the tablet switch status changes.
On an ACPI based convertible chromebook check evtest display tablet mode
switch changes:
Available devices:
..
/dev/input/event3: Tablet Mode Switch
..
Testing ... (interrupt to exit)
Event: time 1484879712.604360, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 1
Event: time 1484879712.604360, -------------- SYN_REPORT ------------
Event: time 1484879715.132228, type 5 (EV_SW), code 1 (SW_TABLET_MODE),
value 0
Event: time 1484879715.132228, -------------- SYN_REPORT ------------
...
Check state is updated at resume time when different from suspend time.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Commit 001dde9400 ("mfd: cros ec: spi: Fix "in progress" error
signaling") pointed out some bad code, but its analysis and conclusion
was not 100% correct.
It *is* correct that we should not propagate result==EC_RES_IN_PROGRESS
for transport errors, because this has a special meaning -- that we
should follow up with EC_CMD_GET_COMMS_STATUS until the EC is no longer
busy. This is definitely the wrong thing for many commands, because
among other problems, EC_CMD_GET_COMMS_STATUS doesn't actually retrieve
any RX data from the EC, so commands that expected some data back will
instead start processing junk.
For such commands, the right answer is to either propagate the error
(and return that error to the caller) or resend the original command
(*not* EC_CMD_GET_COMMS_STATUS).
Unfortunately, commit 001dde9400 forgets a crucial point: that for
some long-running operations, the EC physically cannot respond to
commands any more. For example, with EC_CMD_FLASH_ERASE, the EC may be
re-flashing its own code regions, so it can't respond to SPI interrupts.
Instead, the EC prepares us ahead of time for being busy for a "long"
time, and fills its hardware buffer with EC_SPI_PAST_END. Thus, we
expect to see several "transport" errors (or, messages filled with
EC_SPI_PAST_END). So we should really translate that to a retryable
error (-EAGAIN) and continue sending EC_CMD_GET_COMMS_STATUS until we
get a ready status.
IOW, it is actually important to treat some of these "junk" values as
retryable errors.
Together with commit 001dde9400, this resolves bugs like the
following:
1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400, we
would abort the first time we saw EC_SPI_PAST_END)
2. Before commit 001dde9400, transport errors (e.g.,
EC_SPI_RX_BAD_DATA) seen in other commands (e.g.,
EC_CMD_RTC_GET_VALUE) used to yield junk data in the RX buffer; they
will now yield -EAGAIN return values, and tools like 'hwclock' will
simply fail instead of retrieving and re-programming undefined time
values
Fixes: 001dde9400 ("mfd: cros ec: spi: Fix "in progress" error signaling")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Older models of Chromebooks did not describe the LPC EC in their ACPI
tables; starting with Strago-based devices Google is using GOOG0004 device
to describe EC LPC.
DMI-based match is fragile and does not work reliably, especially when
using custom firmware. It is also not needed when we can locate the right
ACPI device, so let's stop bailing out when DMI does not match but the
right ACPI device is present.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Fn + left arrow hotkey combination is used for enabling/disabling automatic
display brightness based on integrated ALS sensor. For this purpose there
is standard Linux key KEY_BRIGHTNESS_AUTO so use it instead of KEY_UNKNOWN.
Tested on Dell Lattitude E6500.
Signed-off-by: Henk Vergonet <henk.vergonet@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>
Now that we have informed the firmware that the Power Button driver is active,
laptops such as the Acer Swift 3 will generate a WMI key event with code 0x87
when the power button key is pressed.
Add this keycode to the table so that it is converted to
an appropriate input event.
Signed-off-by: Antonio Rosario Intilisano <antonio.intilisano@gmail.com>
Acked-by: Gianfranco Costamagna <locutusofborg@debian.org>
Tested-by: Antonio Rosario Intilisano <antonio.intilisano@gmail.com>
Cc: Chris Chiu <chiu@endlessm.com>
Cc: Daniel Drake <drake@endlessm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Some of latest Lenovo ideapad laptops do not have UEFI/BIOS setting for
switching fn-lock mode. This commit adds related acpi calls to ideapad
platform driver. However setting is available via sysfs.
Signed-off-by: Oleg Keri <ezhi99@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Yet another Lenovo model to be added to the no_hw_rfkill blacklist:
ideapad MIIX 720-12IKB. Otherwise it's always hard-blocked.
Reported-by: Robin Roevens <robin.roevens1@pandora.be>
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1093035
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
If DELL_WMI "select"s DELL_SMBIOS, the DELL_SMBIOS dependencies are
ignored and it is still possible to end up with unmet direct
dependencies.
Change the select to a depends on.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Variants of proc_create{,_data} that directly take a seq_file show
callback and drastically reduces the boilerplate code in the callers.
All trivial callers converted over.
Signed-off-by: Christoph Hellwig <hch@lst.de>
If DELL_WMI "select"s DELL_SMBIOS, the DELL_SMBIOS dependencies are
ignored and it is still possible to end up with unmet direct
dependencies.
Change the select to a depends on.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Add missing description of dev, regmap, dwork_irq, after_probe in struct
mlxreg_hotplug_priv_data.
Remove dwork field from the structure mlxreg_hotplug_priv_data itself and
for the descriptions, since it is not used.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: Andy 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: Andy 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reported-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: Andy 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: 32d7b19bad (platform/x86: dell-smbios: Resolve dependency error on DCDBAS)
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
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: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Andy 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: 32d7b19bad (platform/x86: dell-smbios: Resolve dependency error on DCDBAS)
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Cc: stable@vger.kernel.org
Signed-off-by: Darren 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: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>