summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)Author
2018-06-04platform/x86: dell-laptop: Fix keyboard backlight timeout on XPS 13 9370Timur Kristóf
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>
2018-06-04platform/x86: dell-wmi: Ignore new rfkill and fn-lock eventsKai Heng Feng
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>
2018-06-01platform/x86: mlx-platform: Add LED platform driver activationVadim Pasternak
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>
2018-06-01platform/mellanox: Add new ODM system types to mlx-platformVadim Pasternak
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>
2018-06-01platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queueVadim Pasternak
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: 304887041d95 ("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>
2018-06-01platform/x86: ideapad-laptop: Add E42-80 to no_hw_rfkilldylanchu
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>
2018-06-01platform/x86: silead_dmi: Add touchscreen info for the Onda V891w tabletHans de Goede
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>
2018-06-01platform/x86: silead_dmi: Add info for the PoV mobii TAB-P800W (v2.0)Hans de Goede
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>
2018-06-01platform/x86: silead_dmi: Add touchscreen info for the Jumper EZpad 6 ProHans de Goede
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>
2018-05-31Merge tag 'platform-drivers-x86-v4.17-4' of ↵Linus Torvalds
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
2018-05-31platform/x86: asus-wireless: Fix format specifierJoão Paulo Rechi Vita
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>
2018-05-31platform/x86: asus-wmi: Fix NULL pointer dereferenceJoão Paulo Rechi Vita
Do not perform the rfkill cleanup routine when (asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since nothing is registered with the rfkill subsystem in that case. Doing so leads to the following kernel NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 PGD 1a3aa8067 PUD 1a3b3d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34 Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012 task: ffff8801a639ba00 task.stack: ffffc900014cc000 RIP: 0010:[<ffffffff816c7348>] [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP: 0018:ffffc900014cfce0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4 RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4 R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8 FS: 00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0 Stack: ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28 ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0 ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7 Call Trace: [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61 [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52 [<ffffffff816c73e7>] mutex_lock+0x17/0x30 [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi] [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi] [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi] [<ffffffff814a5128>] platform_drv_remove+0x28/0x40 [<ffffffff814a2901>] __device_release_driver+0xa1/0x160 [<ffffffff814a29e3>] device_release_driver+0x23/0x30 [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170 [<ffffffff8149e5a9>] device_del+0x139/0x270 [<ffffffff814a5028>] platform_device_del+0x28/0x90 [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30 [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi] [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi] [<ffffffff8110c692>] SyS_delete_module+0x192/0x270 [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0 [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94 Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00 RIP [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP <ffffc900014cfce0> CR2: 0000000000000000 ---[ end trace 8d484233fa7cb512 ]--- note: modprobe[3275] exited with preempt_count 2 https://bugzilla.kernel.org/show_bug.cgi?id=196467 Reported-by: red.f0xyz@gmail.com Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-05-31platform/x86: asus-wmi: Fix NULL pointer dereferenceJoão Paulo Rechi Vita
Do not perform the rfkill cleanup routine when (asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since nothing is registered with the rfkill subsystem in that case. Doing so leads to the following kernel NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 PGD 1a3aa8067 PUD 1a3b3d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34 Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012 task: ffff8801a639ba00 task.stack: ffffc900014cc000 RIP: 0010:[<ffffffff816c7348>] [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP: 0018:ffffc900014cfce0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4 RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4 R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8 FS: 00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0 Stack: ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28 ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0 ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7 Call Trace: [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61 [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52 [<ffffffff816c73e7>] mutex_lock+0x17/0x30 [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi] [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi] [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi] [<ffffffff814a5128>] platform_drv_remove+0x28/0x40 [<ffffffff814a2901>] __device_release_driver+0xa1/0x160 [<ffffffff814a29e3>] device_release_driver+0x23/0x30 [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170 [<ffffffff8149e5a9>] device_del+0x139/0x270 [<ffffffff814a5028>] platform_device_del+0x28/0x90 [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30 [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi] [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi] [<ffffffff8110c692>] SyS_delete_module+0x192/0x270 [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0 [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94 Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00 RIP [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120 RSP <ffffc900014cfce0> CR2: 0000000000000000 ---[ end trace 8d484233fa7cb512 ]--- note: modprobe[3275] exited with preempt_count 2 https://bugzilla.kernel.org/show_bug.cgi?id=196467 Reported-by: red.f0xyz@gmail.com Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-05-30platform/chrome: Use to_cros_ec_dev more broadlyGwendal Grignou
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>
2018-05-29platform/chrome: chromeos_laptop: fix touchpad button mapping on CelesDmitry Torokhov
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>
2018-05-29mfd: cros_ec: Don't try to grab log when suspendedDouglas Anderson
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>
2018-05-28Merge branch 'ib-chrome-platform-atmel-mxt-ts-device-properties' into ↵Benson Leung
working-branch-for-4.18 Signed-off-by: Benson Leung <bleung@chromium.org>
2018-05-28platform: chrome: Add input dependency for tablet switch driverArnd Bergmann
Without CONFIG_INPUT, or with a modular input layer and built-in tablet driver, we get a link error: ERROR: "input_event" [drivers/platform/chrome/chromeos_tbmc.ko] undefined! ERROR: "input_register_device" [drivers/platform/chrome/chromeos_tbmc.ko] undefined! ERROR: "input_set_capability" [drivers/platform/chrome/chromeos_tbmc.ko] undefined! ERROR: "devm_input_allocate_device" [drivers/platform/chrome/chromeos_tbmc.ko] undefined! This adds the corresponding Kconfig dependency Fixes: b418f74170d7 ("platform: chrome: Add Tablet Switch ACPI driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benson Leung <bleung@chromium.org>
2018-05-24platform: x86: intel_cht_int33fe: Fix dependenciesHeikki Krogerus
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>
2018-05-23platform/chrome: chromeos_laptop - supply properties for ACPI devicesDmitry Torokhov
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>
2018-05-23platform/chrome: chromeos_tbmc - add SPDX identifierBenson Leung
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>
2018-05-23platform: chrome: Add Tablet Switch ACPI driverGwendal Grignou
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>
2018-05-23mfd: cros_ec: Retry commands when EC is known to be busyBrian Norris
Commit 001dde9400d5 ("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 001dde9400d5 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 001dde9400d5, this resolves bugs like the following: 1. EC_CMD_FLASH_ERASE now works again (with commit 001dde9400d5, we would abort the first time we saw EC_SPI_PAST_END) 2. Before commit 001dde9400d5, 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: 001dde9400d5 ("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>
2018-05-22platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device foundDmitry Torokhov
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>
2018-05-22platform/x86: dell-wmi: Set correct keycode for Fn + left arrowHenk
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>
2018-05-22platform/x86: acer-wmi: add another KEY_POWER keycodeAntonio Rosario Intilisano
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>
2018-05-22platform/x86: ideapad-laptop: Add fn-lock settingOleg Keri
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>
2018-05-22platform/x86: ideapad-laptop: Add MIIX 720-12IKB to no_hw_rfkillTakashi Iwai
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>
2018-05-18platform/x86: DELL_WMI use depends on instead of select for DELL_SMBIOSDarren Hart
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>
2018-05-16proc: introduce proc_create_single{,_data}Christoph Hellwig
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>
2018-05-12platform/x86: DELL_WMI use depends on instead of select for DELL_SMBIOSDarren Hart
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>
2018-05-12platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private dataVadim Pasternak
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>
2018-05-07platform/x86: thinkpad_acpi: silence false-positive-prone pr_warnHenrique de Moraes Holschuh
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>
2018-05-07platform/x86: thinkpad_acpi: do not report thermal sensor state for tablet ↵Henrique de Moraes Holschuh
mode switch 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>
2018-05-07platform/x86: thinkpad_acpi: silence HKEY 0x6032, 0x60f0, 0x6030Henrique de Moraes Holschuh
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>
2018-05-04platform/x86: Kconfig: Fix dell-laptop dependency chain.Mario Limonciello
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: 32d7b19bad96 (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>
2018-05-04platform/x86: asus-wireless: Fix NULL pointer dereferenceJoão Paulo Rechi Vita
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=196097 Reported-by: Dun Hum <bitter.taste@gmx.com> Cc: stable@vger.kernel.org Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-24platform/x86: apple-gmux: fix gmux_get_client_id()'s return typeLuc Van Oostenryck
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>
2018-04-23platform/x86: Kconfig: Fix dell-laptop dependency chain.Mario Limonciello
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: 32d7b19bad96 (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>
2018-04-23platform/x86: Simplify getting .drvdataWolfram Sang
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>
2018-04-23platform/x86: asus-wireless: Fix NULL pointer dereferenceJoão Paulo Rechi Vita
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=196097 Reported-by: Dun Hum <bitter.taste@gmx.com> Cc: stable@vger.kernel.org Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-23platform/x86: dell-smbios: Match on www.dell.com in OEM strings tooMario Limonciello
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: Sergey Kubushyn <ksi@koi8.net> Tested-by: Sergey Kubushyn <ksi@koi8.net> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> [dvhart: Simplify DMI logic and eliminate unnecessary variables] Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-23platform: x86: intel_scu_ipc: Replace mdelay with usleep_range in ↵Jia-Ju Bai
intel_scu_ipc_i2c_cntrl 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: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2018-04-19platform/x86: fujitsu-laptop: Simplify soft key handlingDarren Hart (VMware)
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: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2018-04-13Merge tag 'chrome-platform-for-linus-4.17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform Pull chrome platform updates from Benson Leung: - a series from Dmitry to remove platform data from chromeos_laptop.c, which was the only user of platform data for the atmel_mxt_ts driver. - a series to clean up sysfs and debugfs for cros_ec - other misc cleanups * tag 'chrome-platform-for-linus-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform: (22 commits) platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid angle platform/chrome: cros_ec_debugfs: Add PD port info to debugfs platform/chrome: cros_ec_debugfs: Use octal permissions '0444' platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR variants platform/chrome: cros_ec_sysfs: introduce to_cros_ec_dev define. platform/chrome: cros_ec_sysfs: Modify error handling platform/chrome: cros_ec_lpc: Add support for Google devices using custom coreboot firmware platform/chrome: cros_ec_lpc: wake up from s2idle on Chrome EC Input: atmel_mxt_ts - remove platform data support platform/chrome: chromeos_laptop - discard data for unneeded boards platform/chrome: chromeos_laptop - use device properties for Pixel platform/chrome: chromeos_laptop - rely on I2C to set up interrupt trigger platform/chrome: chromeos_laptop - use I2C notifier to create devices platform/chrome: chromeos_laptop - parse DMI IRQ data once platform/chrome: chromeos_laptop - rework i2c peripherals initialization platform/chrome: chromeos_laptop - factor out getting IRQ from DMI platform/chrome: chromeos_laptop - introduce pr_fmt() platform/chrome: chromeos_laptop - stop setting suspend mode for Atmel devices platform/chrome: chromeos_laptop - add SPDX identifier Input: atmel_mxt_ts - switch ChromeOS ACPI devices to generic props ...
2018-04-10Merge remote-tracking branch ↵Benson Leung
'origin/ib-chrome-platform-cros-ec-sysfs-debugfs-for-v4.17' into working-branch-for-4.17 Merging Enric's cros-ec sysfs and debugfs fixes from immutable branch. Signed-off-by: Benson Leung <bleung@chromium.org>
2018-04-10platform/chrome: mfd/cros_ec_dev: Add sysfs entry to set keyboard wake lid angleGwendal Grignou
This adds a sysfs attribute (/sys/class/chromeos/cros_ec/kb_wake_angle) used to set and get the keyboard wake lid angle. This attribute is present only if 2 accelerometers are controlled by the EC. This patch also moves the cros_ec features check before the device is added so the features map obtained from the EC is ready on time. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
2018-04-10platform/chrome: cros_ec_debugfs: Add PD port info to debugfsShawn Nematbakhsh
Add info useful for debugging USB-PD port state. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
2018-04-10platform/chrome: cros_ec_debugfs: Use octal permissions '0444'Enric Balletbo i Serra
Fixed the following checkpatch warning: WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2018-04-10platform/chrome: cros_ec_sysfs: use permission-specific DEVICE_ATTR variantsEnric Balletbo i Serra
Use DEVICE_ATTR variants for read/write attributes. This simplifies the source code, improves readbility, and reduces the chance of inconsistencies. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Benson Leung <bleung@chromium.org>
generated by cgit (git 2.34.1) at 2025-09-20 07:20:16 +0000