09 May, 2018
1 commit
-
commit 9f0a93de9139c2b0a59299cd36b61564522458f8 upstream.
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 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
Cc: stable@vger.kernel.org
Signed-off-by: João Paulo Rechi Vita
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2018
2 commits
-
[ Upstream commit 587d8628fb71c3bfae29fb2bbe84c1478c59bac8 ]
This patch prevents the thinkpad_acpi driver from warning about 2 event
codes returned for keyboard palm-detection. No behavioral changes,
other than suppressing the warning in the kernel log. The events are
still forwarded via acpi-netlink channels.We could, optionally, decide to forward the event through a
input-switch on the tpacpi input device. However, so far no suitable
input-code exists, and no similar drivers report such events. Hence,
leave it an acpi event for now.Note that the event-codes are named based on empirical studies. On the
ThinkPad X1 5th Gen the sensor can be found underneath the arrow key.Cc: Matthew Thode
Signed-off-by: David Herrmann
Acked-by: Henrique de Moraes Holschuh
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 4d6bde512a86c32df3a1f289d2b4cd04b17758d1 ]
On some Dell XPS models WMI events of type 0x0000 reporting a keycode of
0xe00c get reported when the brightness of the LCD panel changes.This leads to us reporting false-positive kbd_led change events to
userspace which in turn leads to the kbd backlight OSD showing when it
should not.We already read the current keyboard backlight brightness value when
reporting events because the led_classdev_notify_brightness_hw_changed
API requires this. Compare this value to the last known value and filter
out duplicate events, fixing this.Note the fixed issue is esp. a problem on XPS models with an ambient light
sensor and automatic brightness adjustments turned on, this causes the kbd
backlight OSD to show all the time there.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514969
Fixes: 9c656b0799 ("platform/x86: dell-*: Call new led hw_changed API ...")
Acked-by: Pali Rohár
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2018
2 commits
-
[ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]
pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh
Signed-off-by: Brian Norris
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Benson Leung
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]This changes the code back to what it did before changing to a
zero-length array structure.Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann
Signed-off-by: Benson Leung
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
25 Feb, 2018
1 commit
-
[ Upstream commit 68a213d325c23d39f109f4c7c824b906a7d209de ]
This machine reports number of keyboard backlight led levels, instead of
value of the last led level index. Therefore max_brightness properly needs
to be subtracted by 1 to match led max_brightness API.Signed-off-by: Pali Rohár
Reported-by: Gabriel M. Elder
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196913
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2018
1 commit
-
commit d6fa7588fd7a8def4c747c0c574ce85d453e3788 upstream.
Commit 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb
changes") amended this driver's ->probe hook to lock decoding of normal
(non-legacy) I/O space accesses to the integrated GPU on dual-GPU
MacBook Pros. The lock stays in place until the driver is unbound.The change was made to work around an issue with the out-of-tree nvidia
graphics driver (available at http://www.nvidia.com/object/unix.html).
It contains the following sequence in nvidia/nv.c:#if defined(CONFIG_VGA_ARB) && !defined(NVCPU_PPC64LE)
#if defined(VGA_DEFAULT_DEVICE)
vga_tryget(VGA_DEFAULT_DEVICE, VGA_RSRC_LEGACY_MASK);
#endif
vga_set_legacy_decoding(dev, VGA_RSRC_NONE);
#endifThis code was reported to cause deadlocks with VFIO already in 2013:
https://devtalk.nvidia.com/default/topic/545560I've reported the issue to Nvidia developers once more in 2017:
https://www.spinics.net/lists/dri-devel/msg138754.htmlOn the MacBookPro10,1, this code apparently breaks backlight control
(which is handled by apple-gmux via an I/O region starting at 0x700),
as reported by Petri Hodju:
https://bugzilla.kernel.org/show_bug.cgi?id=86121I tried to replicate Petri's observations on my MacBook9,1, which uses
the same Intel Ivy Bridge + Nvidia GeForce GT 650M architecture, to no
avail. On my machine apple-gmux' I/O region remains accessible even
with the nvidia driver loaded and commit 4eebd5a4e726 reverted.
Petri reported that apple-gmux becomes accessible again after a
suspend/resume cycle because the BIOS changed the VGA routing on the
root port to the Nvidia GPU. Perhaps this is a BIOS issue after all
that can be fixed with an update?In any case, the change made by commit 4eebd5a4e726 has turned out to
cause two new issues:* Wilfried Klaebe reports a deadlock when launching Xorg because it
opens /dev/vga_arbiter and calls vga_get(), but apple-gmux is holding
a lock on I/O space indefinitely. It looks like apple-gmux' current
behavior is an abuse of the vgaarb API as locks are not meant to be
held for longer periods:
https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11
https://bugzilla.kernel.org/attachment.cgi?id=217541* On dual GPU MacBook Pros introduced since 2013, the integrated GPU is
powergated on boot und thus becomes invisible to Linux unless a custom
EFI protocol is used to leave it powered on. (A patch exists but is
not in mainline yet due to several negative side effects.) On these
machines, locking I/O to the integrated GPU (as done by 4eebd5a4e726)
fails and backlight control is therefore broken:
https://bugzilla.kernel.org/show_bug.cgi?id=105051So let's revert commit 4eebd5a4e726 please. Users experiencing the
issue with the proprietary nvidia driver can comment out the above-
quoted problematic code as a workaround (or try updating the BIOS).Cc: Petri Hodju
Cc: Bjorn Helgaas
Cc: Bruno Prémont
Cc: Andy Ritger
Cc: Ronald Tschalär
Tested-by: Wilfried Klaebe
Signed-off-by: Lukas Wunner
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Greg Kroah-Hartman
17 Jan, 2018
1 commit
-
commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream.
Calling acpi_wmi_init() at the subsys_initcall() level causes ordering
issues to appear on some systems and they are difficult to reproduce,
because there is no guaranteed ordering between subsys_initcall()
calls, so they may occur in different orders on different systems.In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache
creation delayed issue) exposed one of these issues where genl_init()
and acpi_wmi_init() are both called at the same initcall level, but
the former must run before the latter so as to avoid a NULL pointer
dereference.For this reason, move the acpi_wmi_init() invocation to the
initcall_sync level which should still be early enough for things
to work correctly in the WMI land.Link: https://marc.info/?t=151274596700002&r=1&w=2
Reported-by: Jonathan McDowell
Reported-by: Joonsoo Kim
Tested-by: Jonathan McDowell
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Greg Kroah-Hartman
25 Dec, 2017
1 commit
-
commit bff5bf9db1c9453ffd0a78abed3e2d040c092fd9 upstream.
Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.https://bugs.freedesktop.org/show_bug.cgi?id=104041
Signed-off-by: Peter Hutterer
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Greg Kroah-Hartman
20 Dec, 2017
2 commits
-
[ Upstream commit 163ca80013aafb6dc9cb295de3db7aeab9ab43f8 ]
Added support for HP ProBook 440 G4 laptops by including the accelerometer
orientation quirk for that device. Testing was performed based on the
axis orientation guidelines here:
https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d
which states "If the left side is elevated, X increases (becomes positive)".When tested, on lifting the left edge, x values became increasingly negative
thus indicating an inverted x-axis on the installed lis3lv02d chip.
This was compensated by adding an entry for this device in hp_accel.c
specifying the quirk as x_inverted. The patch was tested on a
ProBook 440 G4 device and x-axis as well as y and z-axis values are now
generated as per spec.Signed-off-by: Osama Khan
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6cc8cbbc8868033f279b63e98b26b75eaa0006ab ]
For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not
mandatory. So when PMC IPC driver creates a PUNIT device, if these
resources are not available then it creates dummy resource entries for
these missing resources. But during PUNIT device probe, doing ioremap on
these dummy resources generates following warning messages.intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]This patch fixes this issue by adding extra check for resource size
before performing ioremap operation.Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Andy Shevchenko
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
05 Dec, 2017
1 commit
-
commit 9968e12a291e639dd51d1218b694d440b22a917f upstream.
Commit f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet
state fetchers") consolidated the methods for docking and laptop mode
detection, but omitted to apply the correct mask for the laptop mode
(it always uses the constant for docking).Fixes: f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers")
Signed-off-by: Stefan Brüns
Cc: Michel Dänzer
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
21 Nov, 2017
2 commits
-
commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream.
Add missing terminating entry to peaq_dmi_table.
Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...")
Reported-by: Fengguang Wu
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 upstream.
It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not
as unique as a GUID should be and is used on some other devices too.This is causing spurious key-press reports on these other devices.
This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to
ensure that it is actually running on a PEAQ 2-in-1, fixing the
spurious key-presses on these other devices.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1497861
BugLink: https://bugzilla.suse.com/attachment.cgi?id=743182
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
03 Nov, 2017
1 commit
-
…el/git/gregkh/driver-core
Pull initial SPDX identifiers from Greg KH:
"License cleanup: add SPDX license identifiers to some filesMany source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the
'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally
binding shorthand, which can be used instead of the full boiler plate
text.This patch is based on work done by Thomas Gleixner and Kate Stewart
and Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset
of the use cases:- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to
license had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied
to a file was done in a spreadsheet of side by side results from of
the output of two independent scanners (ScanCode & Windriver)
producing SPDX tag:value files created by Philippe Ombredanne.
Philippe prepared the base worksheet, and did an initial spot review
of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537
files assessed. Kate Stewart did a file by file comparison of the
scanner results in the spreadsheet to determine which SPDX license
identifier(s) to be applied to the file. She confirmed any
determination that was not immediately clear with lawyers working with
the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained
>5 lines of source- File already had some variant of a license header in it (even if <5
lines).All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that
was:SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that
became the concluded license(s).- when there was disagreement between the two scanners (one detected
a license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply
(and which scanner probably needed to revisit its heuristics).- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases,
confirmation by lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.
The Windriver scanner is based on an older version of FOSSology in
part, so they are related.Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot
checks in about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect
the correct identifier.Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial
patch version early this week with:- a full scancode scan run, collecting the matched texts, detected
license ids and scores- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct- reviewing anything where there was no detection but the patch
license was not GPL-2.0 WITH Linux-syscall-note to ensure that the
applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"* tag 'spdx_identifiers-4.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
License cleanup: add SPDX license identifier to uapi header files with a license
License cleanup: add SPDX license identifier to uapi header files with no license
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
24 Oct, 2017
2 commits
-
Currently, update_no_reboot_bit() function implemented in this driver
uses mutex_lock() to protect its register updates. But this function is
called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop()
functions in iTCO_wdt.c driver, which in turn causes "sleeping into
atomic context" issue. This patch fixes this issue by replacing the
mutex_lock() with spin_lock() to protect the GCR read/write/update APIs.Fixes: 9d855d4 ("platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure")
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Andy Shevchenko -
This patch cleans up unnecessary free/alloc calls in ipc_plat_probe(),
ipc_pci_probe() and ipc_plat_get_res() functions by using devm_*
calls.This patch also adds proper error handling for failure cases in
ipc_pci_probe() function.Signed-off-by: Kuppuswamy Sathyanarayanan
[andy: fixed style issues, missed devm_free_irq(), removed unnecessary log message]
Signed-off-by: Andy Shevchenko
27 Sep, 2017
1 commit
-
My Fujitsu-Siemens Lifebook S6120 doesn't have the FUJ02E3 device,
but it does have FUJ02B1. That means we do register the backlight
device (and it even seems to work), but the code will oops as soon
as we try to set the backlight brightness because it's trying to
call call_fext_func() with a NULL device. Let's just skip those
function calls when the FUJ02E3 device is not present.Cc: Jonathan Woithe
Cc: Andy Shevchenko
Signed-off-by: Ville Syrjälä
Cc: # 4.13.x
Signed-off-by: Darren Hart (VMware)
14 Sep, 2017
1 commit
-
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]Signed-off-by: Christoph Hellwig
Signed-off-by: Jean Delvare
09 Sep, 2017
1 commit
-
Pull x86 platform driver updates from Darren Hart:
"Several fixes from static analysis and message noise reduction.
Correct WMI core and related drivers to evaluate instance number 0x0
in accordance with the documentation. Add intel-telemetry support for
Gemini Lake. Various individual driver fixes noted below.dell-wmi:
- Update dell_wmi_check_descriptor_buffer() to new modelintel-vbtn:
- reduce unnecessary messages for normal users
- match power button on press rather than releaseintel-hid:
- reduce unnecessary messages for normal usersthinkpad_acpi:
- Fix warning about deprecated hwmon_device_registerwmi:
- Fix check for method instance numberideapad-laptop:
- Expose conservation mode switchintel_pmc_core:
- Make the driver PCH family agnosticpeaq-wmi:
- Evaluate wmi method with instance number 0x0
- silence a static checker warningmxm-wmi:
- Evaluate wmi method with instance number 0x0asus-wmi:
- Evaluate wmi method with instance number 0x0intel_scu_ipc:
- make intel_scu_ipc_pdata_t constintel_mid_powerbtn:
- make mid_pb_ddata const
- fix error return code in mid_pb_probe()hp-wmi:
- Remove unused macro helper
- Correctly determine method id in WMI callsdell-wmi:
- Fix driver interface version queryintel_telemetry:
- remove redundant macro definition
- Add GLK PSS Event Tablealienware-wmi:
- fix format string overflow warningibm_rtl:
- remove unnecessary static in ibm_rtl_write()msi-wmi:
- remove unnecessary static in msi_wmi_notify()"* tag 'platform-drivers-x86-v4.14-1' of git://git.infradead.org/linux-platform-drivers-x86: (23 commits)
platform/x86: dell-wmi: Update dell_wmi_check_descriptor_buffer() to new model
platform/x86: intel-vbtn: reduce unnecessary messages for normal users
platform/x86: intel-hid: reduce unnecessary messages for normal users
platform/x86: thinkpad_acpi: Fix warning about deprecated hwmon_device_register
platform/x86: wmi: Fix check for method instance number
platform/x86: ideapad-laptop: Expose conservation mode switch
platform/x86: intel_pmc_core: Make the driver PCH family agnostic
platform/x86: peaq-wmi: Evaluate wmi method with instance number 0x0
platform/x86: mxm-wmi: Evaluate wmi method with instance number 0x0
platform/x86: asus-wmi: Evaluate wmi method with instance number 0x0
platform/x86: intel_scu_ipc: make intel_scu_ipc_pdata_t const
platform/x86: intel_mid_powerbtn: make mid_pb_ddata const
platform/x86: intel_mid_powerbtn: fix error return code in mid_pb_probe()
platform/x86: hp-wmi: Remove unused macro helper
platform/x86: hp-wmi: Correctly determine method id in WMI calls
platform/x86: intel-vbtn: match power button on press rather than release
platform/x86: dell-wmi: Fix driver interface version query
platform/x86: intel_telemetry: remove redundant macro definition
platform/x86: intel_telemetry: Add GLK PSS Event Table
platform/x86: alienware-wmi: fix format string overflow warning
...
04 Sep, 2017
1 commit
-
* pm-sleep:
ACPI / PM: Check low power idle constraints for debug only
PM / s2idle: Rename platform operations structure
PM / s2idle: Rename ->enter_freeze to ->enter_s2idle
PM / s2idle: Rename freeze_state enum and related items
PM / s2idle: Rename PM_SUSPEND_FREEZE to PM_SUSPEND_TO_IDLE
ACPI / PM: Prefer suspend-to-idle over S3 on some systems
platform/x86: intel-hid: Wake up Dell Latitude 7275 from suspend-to-idle
PM / suspend: Define pr_fmt() in suspend.c
PM / suspend: Use mem_sleep_labels[] strings in messages
PM / sleep: Put pm_test under CONFIG_PM_SLEEP_DEBUG
PM / sleep: Check pm_wakeup_pending() in __device_suspend_noirq()
PM / core: Add error argument to dpm_show_time()
PM / core: Split dpm_suspend_noirq() and dpm_resume_noirq()
PM / s2idle: Rearrange the main suspend-to-idle loop
PM / timekeeping: Print debug messages when requested
PM / sleep: Mark suspend/hibernation start and finish
PM / sleep: Do not print debug messages by default
PM / suspend: Export pm_suspend_target_state
19 Aug, 2017
4 commits
-
This converts dell_wmi_check_descriptor_buffer() to the new driver
model interface and puts the interface version in dell_wmi_priv
where it belongs.Signed-off-by: Andy Lutomirski
Reviewed-by: Pali Rohár
Signed-off-by: Darren Hart (VMware) -
Unsupported events is only useful for developers and does not meaningful
for users. Using dev_dbg makes more sense and reduces noise in kernel
messages.Signed-off-by: Alex Hung
Signed-off-by: Darren Hart (VMware) -
Unsupported events is only useful for developers and does not meaningful
for users. Using dev_dbg makes more sense and reduces noise in kernel
messages.Signed-off-by: Alex Hung
Signed-off-by: Darren Hart (VMware) -
Use hwmon_device_register_with_groups instead of deprecated
hwmon_device_register and fix a dmesg warning.This patch however changes the userspace API.
hwmon_device_register_with_groups takes `hwmon' name as an argument and
creates a name file in the `hwmon' device, not in the `platform_device'.
This allows us to remove custom `name' device attribute, but in order to
make lm-sensors happy we also have to move fans and thermal attributes
to the `hwmon' device.Even though this patch changes userspace API, it's still compatible with
the lm-sensors. Starting with lm-sensors 3.0 (circa 2007), it looks at
both hwmon and the backing device for the name and other attributes.before:
$ cat /sys/devices/platform/thinkpad_hwmon/{name,fan1_input}
thinkpad
2007
$ cat /sys/devices/platform/thinkpad_hwmon/hwmon/hwmon1/{name,fan1_input}
cat: /sys/devices/platform/thinkpad_hwmon/hwmon/hwmon1/name: No such file or directory
cat: /sys/devices/platform/thinkpad_hwmon/hwmon/hwmon1/fan1_input: No such file or directory
$ cat /sys/class/hwmon/hwmon1/{name,fan1_input}
cat: /sys/class/hwmon/hwmon1/name: No such file or directory
cat: /sys/class/hwmon/hwmon1/fan1_input: No such file or directory
$ sensors
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 3533 RPMafter:
$ cat /sys/devices/platform/thinkpad_hwmon/{name,fan1_input}
cat: /sys/devices/platform/thinkpad_hwmon/name: No such file or directory
cat: /sys/devices/platform/thinkpad_hwmon/fan1_input: No such file or directory
$ cat /sys/devices/platform/thinkpad_hwmon/hwmon/hwmon1/{name,fan1_input}
thinkpad
3478
$ cat /sys/class/hwmon/hwmon1/{name,fan1_input}
thinkpad
3478
$ sensors
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 3489 RPM$ sensors -v
sensors version 3.4.0 with libsensors version 3.4.0Signed-off-by: Stanislav Fomichev
[dvhart: cleaned up commit log, bumped version to 4.14 in the doc change]
Signed-off-by: Darren Hart (VMware)
18 Aug, 2017
1 commit
-
instance_count defines number of instances of data block and instance
itself is indexed from zero, which means first instance has number 0.
Therefore check for invalid instance should be non-strict inequality.Signed-off-by: Pali Rohár
Reviewed-by: Darren Hart (VMware)
Signed-off-by: Andy Shevchenko
15 Aug, 2017
1 commit
-
This exposes the battery conservation mode present on some (?) IdeaPads.
The mode is set by calling ACPI method SBMC with argument 3 (on) or
5 (off). Status is reported in bit 5 of the return value of ACPI method
GBMD.Signed-off-by: Hao Wei Tee
Signed-off-by: Andy Shevchenko
13 Aug, 2017
9 commits
-
Although this driver did pretty good job in abstracting PCH specific
interfaces, but still there are some loose ends. For example
SLP_S0 counter (for reading SLP_S0 residency), PM config offset (for
checking permissions to read XRAM) and PPFEAR offset (for reading IP
status) is still hardcoded for a specific family of PCH.This change extended the struct pmc_reg_map to allow per family
configuration of offsets and bits.No functional change is expected with this change. This change allows
seamless additions to new PCH and create a baseline for other platform
specific extensions.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Andy Shevchenko -
According to Hans de Goede, WMI interface of thh peaq-wmi module has 10
instances but corresponding ACPI WMBC method does not check Arg0 (instance
number) at all. Therefore evaluate WMI method with first instance number
(0x0) instead of second (0x1).Signed-off-by: Pali Rohár
Cc: Hans de Goede
Acked-by: Hans de Goede
Signed-off-by: Andy Shevchenko -
According to MXM 2.1 specification, there is the only one instance of the
WMI GUID F6CB5C3C-9CAE-4EBD-B577-931EA32A2CC0 and so it is instance 0x0.MXM 2.1 specification:
https://lekensteyn.nl/files/docs/mxm-2.1-software-spec.pdf_WDG dump:
// Methods GUID {F6CB5C3C-9CAE-4EBD-B577-931EA32A2CC0}
0x3C, 0x5C, 0xCB, 0xF6, 0xAE, 0x9C, 0xBD, 0x4E, 0xB5, 0x77, 0x93,
0x1E, 0xA3, 0x2A, 0x2C, 0xC0,
0x4D, 0x58, // Object ID "MX" = method "WMMX"
1, // Instance Count
0x02, // Flags (WMIACPI_REGFLAG_METHOD)Signed-off-by: Pali Rohár
Signed-off-by: Andy Shevchenko -
According to available DSDT dump from Asus machine, there is the only one
instance of the WMI GUID 97845ED0-4E6D-11DE-8A39-0800200C9A66 and so it is
0x0. Moreover corresponding method WMBC does not check Arg0 (instance
number) at all.DSDT dump is available at:
https://lwn.net/Articles/391249/_WDG dump:
0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11, 0x8A, 0x39, 0x08,
0x00, 0x20, 0x0C, 0x9A, 0x66,
0x42, 0x43, // Object ID "BC" = method "WMBC"
0x01, // Instance count
0x02, // FlagsSigned-off-by: Pali Rohár
Signed-off-by: Andy Shevchenko -
Make these const as they are only used during a copy operation.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal
Signed-off-by: Andy Shevchenko -
Make these const as they are only used during a copy operation.
Done using Coccinelle.Signed-off-by: Bhumika Goyal
Signed-off-by: Andy Shevchenko -
platform_get_irq() returns an error code, but the intel_mid_powerbtn
driver ignores it and always returns -EINVAL. This is not correct and,
prevents -EPROBE_DEFER from being propagated properly.Print error message and propagate the return value of platform_get_irq
on failure.This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Andy Shevchenko -
The commit d8193cff3390
("platform/x86: hp-wmi: Standardize enum usage for constants")
introduced a macro that had been never used.Remove it.
Signed-off-by: Paulo Alcantara
[andy wrote commit message]
Signed-off-by: Andy Shevchenko -
The WMI queries are performed by evaluating the WMPV() method from ACPI
DSDT tables, and it takes three arguments: instance index, method id and
input data (buffer).Currently the method id is hard-coded to 0x3 in hp_wmi_perform_query()
which means that it will perform WMI calls that expect an output data of
size 0x80 (128). The output size is usually OK for the WMI queries we
perform, however it would be better to pick the correct one before
evaluating the WMI method.Which correct method id to choose can be figured out by looking at the
following ASL code from WVPI() method:...
Name (PVSZ, Package (0x05)
{
Zero,
0x04,
0x80,
0x0400,
0x1000
})
Store (Zero, Local0)
If (LAnd (LGreaterEqual (Arg1, One), LLessEqual (Arg1, 0x05)))
{
Store (DerefOf (Index (PVSZ, Subtract (Arg1, One))), Local0)
}
...Arg1 is the method id and PVSZ is the package used to index the
corresponding output size; 1 -> 0, 2 -> 4, 3 -> 128, 4 -> 1024, 5 ->
4096.This patch maps the output size passed in hp_wmi_perform_query() to the
correct method id before evaluating the WMI method.Signed-off-by: Paulo Alcantara
Signed-off-by: Andy Shevchenko
06 Aug, 2017
2 commits
-
This fixes a problem where the system gets stuck in a loop
unable to wakeup via power button in s2idle.The problem happens because:
- press power button:
- system emits 0xc0 (power press), event ignored
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- set wakeup_mode to true
- system goes to s2idle
- press power button
- system emits 0xc0 (power press), wakeup_mode is true,
system wakes
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- system goes to s2idle againTo avoid this situation, process the presses (which matches what
intel-hid does too).Verified on an Dell XPS 9365
Signed-off-by: Mario Limonciello
Acked-by: Rafael J. Wysocki
Signed-off-by: Darren Hart (VMware) -
This fixes a problem where the system gets stuck in a loop
unable to wakeup via power button in s2idle.The problem happens because:
- press power button:
- system emits 0xc0 (power press), event ignored
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- set wakeup_mode to true
- system goes to s2idle
- press power button
- system emits 0xc0 (power press), wakeup_mode is true,
system wakes
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- system goes to s2idle againTo avoid this situation, process the presses (which matches what
intel-hid does too).Verified on an Dell XPS 9365
Signed-off-by: Mario Limonciello
Acked-by: Rafael J. Wysocki
Signed-off-by: Darren Hart (VMware)
02 Aug, 2017
1 commit
-
When I converted dell-wmi to the new bus infrastructure, I left the
call to dell_wmi_check_descriptor_buffer() in dell_wmi_init(). This
could cause two problems:- An error message when loading the driver on a system without
dell-wmi. We'd try to read the event descriptor even if the WMI
GUID wasn't there.- A possible race if dell-wmi was loaded manually before wmi was
fully initialized.Fix it by moving the call to the probe function where it belongs.
Fixes: bff589be59c5 ("platform/x86: dell-wmi: Convert to the WMI bus infrastructure")
Signed-off-by: Andy Lutomirski
Reviewed-by: Pali Rohár
Signed-off-by: Darren Hart (VMware)