- 20 8月, 2017 1 次提交
-
-
由 Lv Zheng 提交于
EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing. This patch cleans it up using more readable flag/function names. Signed-off-by: NLv Zheng <lv.zheng@intel.com> Tested-by: NTomislav Ivek <tomislav.ivek@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 8月, 2017 5 次提交
-
-
由 Lv Zheng 提交于
Use the observation that the EC command/data register addresses are sufficient to determine if two EC devices are equivelent to modify acpi_is_boot_ec(). Then, for the removed comparison factors, EC ID and EC GPE, they need to be synchronized for the boot_ec: 1. Before registering the BIOS-provided EC event handlers in acpi_ec_register_query_methods(), the namespace node holding _Qxx methods should be located. The real namespace PNP0C09 device location then is apparently more trustworthy than the ECDT EC ID. 2. Because of the ASUS quirks, the ECDT EC GPE is more trustworthy than the namespace PNP0C09 device's _GPE setting. Use the above observations to synchronize the boot_ec settings in acpi_ec_add(). Finally, change the order of acpi_ec_ecdt_start() and acpi_ec_add(), called from acpi_bus_register_driver(), so as to follow the fast path of determining the location of _Qxx. Signed-off-by: NLv Zheng <lv.zheng@intel.com> [ rjw : Changelog & comments ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
On some systems the platform firmware expects GPEs to be enabled before the enumeration of devices and if that expectation is not met, the systems in question may not boot in some situations. For this reason, change the initialization ordering of the ACPI subsystem to make it enable GPEs before scanning the namespace for the first time in order to enumerate devices. Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com> Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NLv Zheng <lv.zheng@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled automatically during the initialization of the ACPI subsystem through acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake() will be called in advance for all of the GPEs pointed to by _PRW objects in the namespace that may be affected by acpi_update_all_gpes(). That is, acpi_ev_initialize_gpe_block() can only be called for a GPE block after acpi_setup_gpe_for_wake() has been called for all of the _PRW (wakeup) GPEs in it. The platform firmware on some systems, however, expects GPEs to be enabled before the enumeration of devices which is when acpi_setup_gpe_for_wake() is called and that goes against the above assumption. For this reason, introduce a new flag to be set by acpi_ev_initialize_gpe_block() when automatically enabling a GPE to indicate to acpi_setup_gpe_for_wake() that it needs to drop the reference to the GPE coming from acpi_ev_initialize_gpe_block() and modify acpi_setup_gpe_for_wake() accordingly. These changes allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block() to be invoked in any order. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
In some cases GPEs are already active when they are enabled by acpi_ev_initialize_gpe_block() and whatever happens next may depend on the result of handling the events signaled by them, so the events should not be discarded (which is what happens currently) and they should be handled as soon as reasonably possible. For this reason, modify acpi_ev_initialize_gpe_block() to dispatch GPEs with the status flag set in-band right after enabling them. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Lv Zheng 提交于
Commit 2a570840 (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) introduced acpi_ec_ecdt_start(), but that function is invoked before acpi_ec_query_init(), which is too early. This causes the kernel to crash if an EC event occurs after boot, when ec_query_wq is not valid: BUG: unable to handle kernel NULL pointer dereference at 0000000000000102 ... Workqueue: events acpi_ec_event_handler task: ffff9f539790dac0 task.stack: ffffb437c0e10000 RIP: 0010:__queue_work+0x32/0x430 Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start() is actually a no-op in the majority of cases. However, commit c712bb58 (ACPI / EC: Add support to skip boot stage DSDT probe) caused the probing of the DSDT EC as the "boot EC" to be skipped when the ECDT EC is valid and uncovered the bug. Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init() in acpi_ec_init(). Link: https://jira01.devtools.intel.com/browse/LCK-4348 Fixes: 2a570840 (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) Fixes: c712bb58 (ACPI / EC: Add support to skip boot stage DSDT probe) Reported-by: NWang Wendy <wendy.wang@intel.com> Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 7月, 2017 2 次提交
-
-
由 Timur Tabi 提交于
The work-around for Qualcomm Technologies QDF2400 Erratum 44 hinges on a global variable defined in the pl011 driver. The ACPI SPCR parsing code determines whether the work-around is needed, and if so, it changes the console name from "pl011" to "qdf2400_e44". The expectation is that the pl011 driver will implement the work-around when it sees the console name. The global variable qdf2400_e44_present is set when that happens. The problem is that work-around needs to be enabled when the pl011 driver probes, not when the console name is queried. However, sbsa_probe() is called before pl011_console_match(). The work-around appeared to work previously because the default console on QDF2400 platforms was always ttyAMA1. The first time sbsa_probe() is called (for ttyAMA0), qdf2400_e44_present is still false. Then pl011_console_match() is called, and it sets qdf2400_e44_present to true. All subsequent calls to sbsa_probe() enable the work-around. The solution is to move the global variable into spcr.c and let the pl011 driver query it during probe time. This works because all QDF2400 platforms require SPCR, so parse_spcr() will always be called. pl011_console_match still checks for the "qdf2400_e44" console name, but it doesn't do anything else special. Fixes: 5a0722b8 ("tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44") Tested-by: NJeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: NTimur Tabi <timur@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hanjun Guo 提交于
ACPI HID for Hisilicon Hip07/08 should be HISI02A1/2, not HISI0A21/2, HISI02A1/2 was tested ok but was modified by the stupid typo when upstream the patches (by me), correct them to the right IDs (matching the IDs in drivers/i2c/busses/i2c-designware-platdrv.c). Fixes: 6e14cf36 (ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C controller) Reported-by: NTao Tian <tiantao6@huawei.com> Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 7月, 2017 1 次提交
-
-
由 Ryan Kennedy 提交于
Partially overlapping regions cause platform device creation to fail. The latter of two overlapping resources will fail to be reserved. Fix this by merging overlapping resource ranges while enumerating WDAT table entries. Signed-off-by: NRyan Kennedy <ryan5544@gmail.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 25 7月, 2017 1 次提交
-
-
由 Ross Zwisler 提交于
To save someone the time of searching the ACPI spec for "Static Resource Affinity Table". Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 7月, 2017 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit eed4d47e (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) introduced acpi_freeze_sync() whose purpose is to flush all of the processing of possible wakeup events signaled via the ACPI SCI. However, it doesn't flush the query workqueue used by the EC driver, so the events generated by the EC may not be processed timely which leads to issues (increased overhead at least, lost events possibly). To fix that introduce acpi_ec_flush_work() that will flush all of the outstanding EC work and call it from acpi_freeze_sync(). Fixes: eed4d47e (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 7月, 2017 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit 8110dd28 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) the configuration of GPEs, including the EC one, is not changed during suspend-to-idle on recent systems. That's in order to make system wakeup events generated by the EC work, in particular. However, on some of the systems in question (for example on Dell XPS13 9365), in addition to generating system wakeup events the EC generates a heartbeat sequence of interrupts that have nothing to do with wakeup while suspended, and the Low Power Idle S0 _DSM interface doesn't change that behavior. The users of those systems may prefer to disable the EC GPE during system suspend, for the cost of non-functional power button wakeup or similar, but currently there is no way to do that. For this reason, add a new module parameter, ec_no_wakeup, for the EC driver module that, if set, will cause the EC GPE to be disabled during system suspend and re-enabled during the subsequent system resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=192591#c106 Amends: 8110dd28 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) Reported-and-tested-by: NPatrik Kullman <patrik.kullman@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 7月, 2017 1 次提交
-
-
由 Prarit Bhargava 提交于
nfit_init() calls nfit_mce_register() on module load. When the module load fails the nfit mce decoder is not unregistered. The module's memory is freed leaving the decoder chain referencing junk. This will cause panics as future registrations will reference the free'd memory. Unregister the nfit mce decoder on module init failure. [v2]: register and then unregister mce handler to avoid losing mce events [v3]: also cleanup nfit workqueue Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error") Cc: <stable@vger.kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Len Brown <lenb@kernel.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com> Cc: Linda Knippers <linda.knippers@hpe.com> Cc: lszubowi@redhat.com Acked-by: NJeff Moyer <jmoyer@redhat.com> Signed-off-by: NPrarit Bhargava <prarit@redhat.com> Reviewed-by: NVishal Verma <vishal.l.verma@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 12 7月, 2017 6 次提交
-
-
由 Hans de Goede 提交于
The GPD win BIOS dated 20170320 has disabled the accelerometer, the drivers sometimes cause crashes under Windows and this is how the manufacturer has solved this :| I see no other way to keep the accelerometer working under Windows then adding it to the always_present_ids array. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
The _STA method of the Venue 11 Pro 7130 touchscreen has this ugliness: Method (_STA, 0, NotSerialized) // _STA: Status { If ((SDS1 & One) == One) { If (RST1 == Zero) { Return (0x0F) } ElseIf (RST2 == Zero) { RST2 = One TMRV = Timer } Else { Local0 = ((Timer - TMRV) / 0x2710) If (Local0 > TMRI) { RST2 = Zero RST1 = Zero } } } Else { Return (Zero) } } Whereby RST1 gets set by _SB.PCI0.GFX0.LCD.LCD1._ON, this means that after RST1 has been set first _STA must be called to set TIMER and then after enough time has elapsed _STA must be called twice more, once to clear RST1 and once to finally return 0xf before the touchscreen will show up. Which is just crazy. This commit adds an always_present_ids entry for the SYNA7500 touchscreen ACPI node, together with a DMI match for the Venue 11 Pro 7130, fixing the touchscreen not working on this device. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
On some x86 systems the DSDT hides APCI devices to work around Windows driver bugs. On one such system the device is even hidden until a certain time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and* _STA has been called at least 3 times since. TL;DR: it is a mess. Until now the always_present_id matching was used to force status for a whole class of devices, e.g. always enable PWM1 on CHerry Trail devices. This commit extends the always_present_id matching code to optionally also check for a DMI match so that we can also add system specific quirks to the always_present_id array. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier EC event freezing timing causes acpitz-virtual-0 to report a stuck 48C temparature. And with EC firmware revisioned as 1.14, without reverting back to old EC event freezing timing, the fan still blows up after a system resume. This reverts the culprit change so that the regression can be fixed without upgrading the EC firmware. Fixes: d3028305 (ACPI / EC: Enable event freeze mode to improve event handling) Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168Tested-by: NDamjan Georgievski <gdamjan@gmail.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
According to bug reports, although the busy polling mode can make noirq stages execute faster, it causes abnormal fan blowing up after system resume (see the first link below for a video demonstration) on Lenovo ThinkPad X1 Carbon - the 5th Generation. The problem can be fixed by upgrading the EC firmware on that machine. However, many reporters confirm that the problem can be fixed by stopping busy polling during suspend/resume and for some of them upgrading the EC firmware is not an option. For this reason, drop the noirq stage hooks from the EC driver to fix the regression. Fixes: c3a696b6 (ACPI / EC: Use busy polling mode when GPE is not enabled) Link: https://youtu.be/9NQ9x-Jm99Q Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129Reported-by: NAndreas Lindhe <andreas@lindhe.io> Tested-by: NGjorgji Jankovski <j.gjorgji@gmail.com> Tested-by: NDamjan Georgievski <gdamjan@gmail.com> Tested-by: NFernando Chaves <nanochaves@gmail.com> Tested-by: NTomislav Ivek <tomislav.ivek@gmail.com> Tested-by: NDenis P. <theoriginal.skullburner@gmail.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mark Salter 提交于
The function acpi_gsi_to_irq() must return 0 on success as the caller ghes_probe expects an 0 for success. This change also matches x86 implementation. This patch was submitted around 4.5 timeframe but wasn't pushed because it didn't fix a real problem. Now that RAS/GHES patches are in kernel, this fixes an error seen on a Mustang (arm64) platform: GHES: Failed to map GSI to IRQ for generic hardware error source: 2 GHES: probe of GHES.2 failed with error 81 Signed-off-by: NTuan Phan <tphan@apm.com> Signed-off-by: NLoc Ho <lho@apm.com> Signed-off-by: NMark Salter <msalter@redhat.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 7月, 2017 1 次提交
-
-
由 Hans de Goede 提交于
At least on the UP board SBC both PWMs are enabled leading to us trying to add the same pwm_lookup twice, which leads to the following: [ 0.902224] list_add double add: new=ffffffffb8efd400, prev=ffffffffb8efd400, next=ffffffffb8eeede0. [ 0.912466] ------------[ cut here ]------------ [ 0.917624] kernel BUG at lib/list_debug.c:31! [ 0.922588] invalid opcode: 0000 [#1] SMP ... [ 1.027450] Call Trace: [ 1.030185] pwm_add_table+0x4c/0x90 [ 1.034181] bsw_pwm_setup+0x1a/0x20 [ 1.038175] acpi_lpss_create_device+0xfe/0x420 ... This commit fixes this by only calling pwm_add_table() for the first PWM controller (which is the one used for the backlight). Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458599 Fixes: bf7696a1 (acpi: lpss: call pwm_add_table() for BSW...) Fixes: 04434ab5 (ACPI / LPSS: Call pwm_add_table() for Bay Trail...) Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 7月, 2017 9 次提交
-
-
由 Arvind Yadav 提交于
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 904 496 0 1400 578 drivers/acpi/dptf/dptf_power.o File size After adding 'const': text data bss dec hex filename 944 432 0 1376 560 drivers/acpi/dptf/dptf_power.o Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Arvind Yadav 提交于
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Arvind Yadav 提交于
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Arvind Yadav 提交于
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 4622 304 8 4934 1346 drivers/acpi/power.o File size After adding 'const': text data bss dec hex filename 4846 80 8 4934 1346 drivers/acpi/power.o Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lee, Chun-Yi 提交于
In hotplug logic, it always indicates non-specific failure to platform through _OST when handing ACPI hot-remove event failed. Then platform terminates the hot-remove process but it can not identify the reason. Base on current hot-remove code, there have two situations that it returns busy: - OSPM try to offline an individual device, but the device offline function returns "busy". - When the ejection event is applied to an "not offlined yet" container. OSPM sends a kobject change event to userspace and returns "busy". Both of them will returns -EBUSY to ACPI device hotplug function. Then, the hotplug function indicates non-specific failure to platform just like for any other error, e.g. -ENODEV or -EIO. The benefit to the platform for identifying the OS "busy" state is that it can use a different approach to handle the "busy" instead of simply terminating the hot-remove operation for an unknown reason. For example, the platform can wait for a while and then re-trigger hot-remove. Signed-off-by: N"Lee, Chun-Yi" <jlee@suse.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> [ rjw: Changelog massage ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lee, Chun-Yi 提交于
Kernel should decrements the reference count of ACPI device when the scheduling of ACPI hotplug work failed, and evaluates _OST to notify BIOS the failure. Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: N"Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Colin Ian King 提交于
The function acpi_osi_dmi_linux() is local and does not need to be in global scope, so make it static. Cleans up sparse warning: "symbol 'acpi_osi_dmi_linux' was not declared. Should it be static?" Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Loc Ho 提交于
APM X-Gene verion 1 and 2 have an 8250 UART with its register aligned to 32-bit. In addition, the latest released BIOS encodes the access field as 8-bit access instead 32-bit access. This causes no console with ACPI boot as the console will not match X-Gene UART port due to the lack of mmio32 option. Signed-off-by: NLoc Ho <lho@apm.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Loc Ho 提交于
The current SPCR code does not check the access width of the MMIO, and uses a default of 8bit register accesses. This prevents devices that only do 16 or 32bit register accesses from working. By simply checking this field and setting the MMIO string appropriately, this issue can be corrected. To prevent any legacy issues, the code will default to 8bit accesses if the value is anything but 16 or 32. Signed-off-by: NJon Mason <jon.mason@broadcom.com> Signed-off-by: NLoc Ho <lho@apm.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 7月, 2017 1 次提交
-
-
由 Toshi Kani 提交于
ACPI 6.2 defines in section 9.20.7.2 that the OSPM may call a Start ARS with Flags Bit [1] set upon receiving the 0x81 notification. Upon receiving the notification, the OSPM may decide to issue a Start ARS with Flags Bit [1] set to prepare for the retrieval of existing records and issue the Query ARS Status function to retrieve the records. Add support to call a Start ARS from acpi_nfit_uc_error_notify() with ND_ARS_RETURN_PREV_DATA set when HW_ERROR_SCRUB_ON is not set. Link: http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdfSigned-off-by: NToshi Kani <toshi.kani@hpe.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Linda Knippers <linda.knippers@hpe.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 01 7月, 2017 3 次提交
-
-
由 Jerry Hoemann 提交于
Display bus_dsm_mask in sysfs as /sys/bus/nd/devices/ndbusX/nfit/dsm_mask. Signed-off-by: NJerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Jerry Hoemann 提交于
Add a bus level dsm_mask to nvdimm_bus_descriptor to allow the passthru calling mechanism to specify a different mask from the cmd_mask. Populate bus_dsm_mask and use it to filter dsm calls that user can make through the pass thru interface. Signed-off-by: NJerry Hoemann <jerry.hoemann@hpe.com> [djbw: use command number constants instead of a magic mask value] Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Jerry Hoemann 提交于
Set ND_CMD_CALL in the cmd_mask to enable calling root functions via the pass thru mechanism. Signed-off-by: NJerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 30 6月, 2017 1 次提交
-
-
由 Arvind Yadav 提交于
File size before: text data bss dec hex filename 20792 1580 994 23366 5b46 drivers/acpi/nfit/core.o File size After adding 'const': text data bss dec hex filename 20968 1388 994 23350 5b36 drivers/acpi/nfit/core.o Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 29 6月, 2017 5 次提交
-
-
由 Carlo Caione 提交于
ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: NCarlo Caione <carlo@caione.org> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Chris Chiu 提交于
Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no interrupts when pressing media keys thus the corresponding functions are not invoked. It's due to the _GPE defines in DSDT for EC returns differnt value compared to the GPE Number in ECDT. Confirmed with Asus that the vale in ECDT is the correct one. This commit uses DMI quirks to prevent calling _GPE when doing ec_parse_device() and keep the ECDT GPE number setting for the EC device. With previous commit, it is ensured that if there is an ECDT, it can always be kept as boot_ec, this patch thus can implement a quirk on top of the determined ECDT boot_ec. Link: https://phabricator.endlessm.com/T16033 Link: https://phabricator.endlessm.com/T16722 Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NChris Chiu <chiu@endlessm.com> Signed-off-by: NCarlo Caione <carlo@caione.org> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is no extra DSDT EC device enumeration process occurring before the main ACPI device enumeration process. That means acpi_ec_dsdt_probe() is not Windows-compatible. Tracking back, it was added by the following commit: Commit: c5279dee Subject: ACPI: EC: Add some basic check for ECDT data but that commit was misguided. Why we shouldn't enumerate DSDT EC before the main ACPI device enumeration? The only way to know if the DSDT EC is valid would be to evaluate its _STA control method, but it's not safe to evaluate this control method that early and out of the ACPI enumeration process, because _STA may refer to entities (such as resources or ACPI device objects) that may not have been initialized before OSPM starts to enumerate them via the main ACPI device enumeration. But after we had reverted back to the expected behavior, a regression was reported. On that platform, there is no ECDT, but the platform control methods access EC operation region earlier than Linux expects causing some ACPI method execution errors. For this reason, we just go back to old behavior to still probe DSDT EC as the boot EC. However, that turns out to lead to yet another functional breakage and in order to work around all of the problems, we skip boot stage DSDT probe when the ECDT exists so that a later quirk can always use correct ECDT GPE setting. Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880 Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261 Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> [ rjw: Changelog & comments massage ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one. This patch simply enhances sanity checks in ec_parse_device() as a workaround to skip probing wrong namespace ECs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
The Dell Precision 7510 has a broken acpi-video implementation. The backlight control bits work, but when the brightness is changed via the acpi-video interface the backlight flickers annoyingly before settling at the new brightness, switching to using the native interface fixes the flickering so add a quirk for this (the vendor interface can not change the brightness at all). Signed-off-by: NShih-Yuan Lee (FourDollars) <sylee@canonical.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 6月, 2017 1 次提交
-
-
由 Lv Zheng 提交于
acpi_ec_cmd_string() currently is only enabled for "DEBUG" macro, but users trend to use CONFIG_DYNAMIC_DEBUG and enable ec.c pr_debug() print-outs by "dyndbg='file ec.c +p'". In this use case, all command names are turned into UNDEF and the log is confusing. This affects bugzilla triage work. This patch fixes this issue by enabling acpi_ec_cmd_string() for CONFIG_DYNAMIC_DEBUG. Tested-by: NWang Wendy <wendy.wang@intel.com> Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-