#
e0359f15 |
|
22-Feb-2024 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI: EC: Use a spin lock without disabing interrupts" Commit eb9299beadbd ("ACPI: EC: Use a spin lock without disabing interrupts") introduced an unexpected user-visible change in behavior, which is a significant CPU load increase when the EC is in use. This most likely happens due to increased spinlock contention and so reducing this effect would require a major rework of the EC driver locking. There is no time for this in the current cycle, so revert commit eb9299beadbd. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218511 Reported-by: Dieter Mummenschanz <dmummenschanz@web.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eb9299be |
|
14-Dec-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Use a spin lock without disabing interrupts Since all of the ACPI EC driver code runs in thread context after recent changes, it does not need to disable interrupts on the local CPU when acquiring a spin lock. Make it use the spin lock without disabling interrupts. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
655a6e7c |
|
14-Dec-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Use a threaded handler for dedicated IRQ After commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") all of the EC code runs in thread context on all systems where EC events are signaled through a GPE. It may as well run in thread context on systems using a dedicated IRQ for EC events signaling, so make it use a threaded handler for that IRQ. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
891ddc03 |
|
24-Oct-2023 |
Jonathan Denose <jdenose@chromium.org> |
ACPI: EC: Add quirk for HP 250 G7 Notebook PC Add GPE quirk entry for HP 250 G7 Notebook PC. This change allows the lid switch to be identified as the lid switch and not a keyboard button. With the lid switch properly identified, the device triggers suspend correctly on lid close. Signed-off-by: Jonathan Denose <jdenose@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cd4aece4 |
|
20-Sep-2023 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx. There is a quirk entry for 2 15-c..... laptops, this is for a new version which has 15-dk1xxx as identifier. This fixes the LID switch and rfkill and brightness hotkeys not working. Closes: https://github.com/systemd/systemd/issues/28942 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b5539eb5 |
|
27-Jun-2023 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Fix acpi_ec_dispatch_gpe() Commit 896e97bf99ec ("ACPI: EC: Clear GPE on interrupt handling only") broke suspend-to-idle at least on Dell XPS13 9360 and 9380. The problem is that acpi_ec_dispatch_gpe() must clear the EC GPE, because the EC GPE handler never runs when the system is in the suspend-to-idle state and if the EC GPE is not cleared by the suspend- to-idle loop, it is never cleared at all which leads to a GPE storm. This causes suspend-to-idle to burn energy instead of saving it which is potentially dangerous (the affected machines heat up rather badly when that happens). Addess this by making acpi_ec_dispatch_gpe() clear the EC GPE as it did before. Fixes: 896e97bf99ec ("ACPI: EC: Clear GPE on interrupt handling only") Tested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
896e97bf |
|
06-Jun-2023 |
Compostella, Jeremy <jeremy.compostella@intel.com> |
ACPI: EC: Clear GPE on interrupt handling only On multiple devices I work on, we noticed that /sys/firmware/acpi/interrupts/sci_not is non-zero and keeps increasing over time. It turns out that there is a race condition between servicing a GPE interrupt and handling task driven transactions. If a GPE interrupt is received at the same time ec_poll() is running, the advance_transaction() clears the GPE flag and the interrupt is not serviced as acpi_ev_detect_gpe() relies on the GPE flag to call the handler. As a result, `sci_not' is increased. To address this, move the GPE status check and clearing from advance_transaction() directly into acpi_ec_handle_interrupt(), so the EC GPE only gets cleared in the interrupt handling path. Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e5b492c6 |
|
24-Mar-2023 |
Armin Wolf <W_Armin@gmx.de> |
ACPI: EC: Fix oops when removing custom query handlers When removing custom query handlers, the handler might still be used inside the EC query workqueue, causing a kernel oops if the module holding the callback function was already unloaded. Fix this by flushing the EC query workqueue when removing custom query handlers. Tested on a Acer Travelmate 4002WLMi Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
28f7b858 |
|
24-Mar-2023 |
Armin Wolf <W_Armin@gmx.de> |
ACPI: EC: Limit explicit removal of query handlers to custom query handlers According to the ACPI spec part 5.6.4.1.2, EC query handlers discovered thru ACPI should not be removed when a driver removes his custom query handler. On the Acer Travelmate 4002WLMi for example, such a query handler is used as a fallback to handle the EC SMBus alert when no driver is present. Change acpi_ec_remove_query_handlers() so that only custom query handlers are removed then remove_all is false. Query handlers discovered thru ACPI will still get removed when remove_all is true, which happens on device removal. Also add a simple check to ensure that acpi_ec_add_query_handler() is always called with either handle or func being set, since custom query handlers are detected based whether handlers->func is set or not. Tested on a Acer Travelmate 4002WLMi. Signed-off-by: Armin Wolf <W_Armin@gmx.de> [ rjw: Comment adjustment ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ab4620f5 |
|
08-Dec-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Fix ECDT probe ordering issues ACPI-2.0 says that the EC OpRegion handler must be available immediately (like the standard default OpRegion handlers): Quoting from the ACPI spec version 6.3: "6.5.4 _REG (Region) ... 2. OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. These operation regions may become inaccessible after OSPM runs _REG(EmbeddedControl, 0)." So acpi_bus_init() calls acpi_ec_ecdt_probe(), which calls acpi_install_address_space_handler() to install the EC's OpRegion handler, early on. This not only installs the OpRegion handler, but also calls the EC's _REG method. The _REG method call is a problem because it may rely on initialization done by the _INI methods of one of the PCI / _SB root devs, see for example: https://bugzilla.kernel.org/show_bug.cgi?id=214899 . Generally speaking _REG methods are executed when the ACPI-device they are part of has a driver bound to it. Where as _INI methods must be executed at table load time (according to the spec). The problem here is that the early acpi_install_address_space_handler() call causes the _REG handler to run too early. To allow fixing this the ACPICA code now allows to split the OpRegion handler installation and the executing of _REG into 2 separate steps. This commit uses this ACPICA functionality to fix the EC probe ordering by delaying the executing of _REG for ECDT described ECs till the matching EC device in the DSDT gets parsed and acpi_ec_add() for it gets called. This moves the calling of _REG for the EC on devices with an ECDT to the same point in time where it is called on devices without an ECDT table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214899 Reported-and-tested-by: Johannes Penßel <johannespenssel@posteo.net> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a5072078 |
|
08-Dec-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Fix EC address space handler unregistration When an ECDT table is present the EC address space handler gets registered on the root node. So to unregister it properly the unregister call also must be done on the root node. Store the ACPI handle used for the acpi_install_address_space_handler() call and use te same handle for the acpi_remove_address_space_handler() call. Reported-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6c0eb5ba |
|
13-Nov-2022 |
Dawei Li <set_pte_at@outlook.com> |
ACPI: make remove callback of ACPI driver void For bus-based driver, device removal is implemented as: 1 device_remove()-> 2 bus->remove()-> 3 driver->remove() Driver core needs no inform from callee(bus driver) about the result of remove callback. In that case, commit fc7a6209d571 ("bus: Make remove callback return void") forces bus_type::remove be void-returned. Now we have the situation that both 1 & 2 of calling chain are void-returned, so it does not make much sense for 3(driver->remove) to return non-void to its caller. So the basic idea behind this change is making remove() callback of any bus-based driver to be void-returned. This change, for itself, is for device drivers based on acpi-bus. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dawei Li <set_pte_at@outlook.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/* Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b423f240 |
|
29-Oct-2022 |
Mia Kanashi <chad@redpilled.dev> |
ACPI: EC: Add quirk for the HP Pavilion Gaming 15-cx0041ur Added GPE quirk entry for the HP Pavilion Gaming 15-cx0041ur. There is a quirk entry for the 15-cx0xxx laptops, but this one has different DMI_PRODUCT_NAME. Notably backlight keys and other ACPI events now function correctly. Signed-off-by: Mia Kanashi <chad@redpilled.dev> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b3c0e38b |
|
25-Aug-2022 |
ye xingchen <ye.xingchen@zte.com.cn> |
ACPI: EC: Drop unneeded result variable from ec_write() Return the acpi_ec_write() return value directly instead of storing it in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3e6573c5 |
|
20-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Drop unused ident initializers from dmi_system_id tables Drop the unused const string ident initializers from the dmi_system_id tables to make the object size a bit smaller. While at it also use proper named struct-member initializers for the ec_dmi_table[]. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
81df5f91 |
|
20-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Re-use boot_ec when possible even when EC_FLAGS_TRUST_DSDT_GPE is set EC_FLAGS_TRUST_DSDT_GPE only does anything when the: if (boot_ec && ec->command_addr == boot_ec->command_addr && ec->data_addr == boot_ec->data_addr) conditions are all true. Normally acpi_ec_add() would re-use the boot_ec struct acpi_ec in this case. But when the EC_FLAGS_TRUST_DSDT_GPE flag was set the code would continue with a newly allocated (second) struct acpi_ec. There is no reason to use a second struct acpi_ec if all the above checks match. Instead just change boot_ec->gpe to ec->gpe, when the flag is set, similar to how this is already one done for boot_ec->handle. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f7090e0e |
|
20-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Drop the EC_FLAGS_IGNORE_DSDT_GPE quirk It seems that these quirks are no longer necessary since commit 69b957c26b32 ("ACPI: EC: Fix possible issues related to EC initialization order"), which has fixed this in a generic manner. There are 3 commits adding DMI entries with this quirk (adding multiple DMI entries per commit). 2/3 commits are from before the generic fix. Which leaves commit 6306f0431914 ("ACPI: EC: Make more Asus laptops use ECDT _GPE"), which was committed way after the generic fix. But this was just due to slow upstreaming of it. This commit stems from Endless from 15 Aug 2017 (committed upstream 20 May 2021): https://github.com/endlessm/linux/pull/288 The current code should work fine without this: 1. The EC_FLAGS_IGNORE_DSDT_GPE flag is only checked in ec_parse_device(), like this: if (boot_ec && boot_ec_is_ecdt && EC_FLAGS_IGNORE_DSDT_GPE) { ec->gpe = boot_ec->gpe; } else { /* parse GPE */ } 2. ec_parse_device() is only called from acpi_ec_add() and acpi_ec_dsdt_probe() 3. acpi_ec_dsdt_probe() starts with: if (boot_ec) return; so it only calls ec_parse_device() when boot_ec == NULL, meaning that the quirk never triggers for this call. So only the call in acpi_ec_add() matters. 4. acpi_ec_add() does the following after the ec_parse_device() call: if (boot_ec && ec->command_addr == boot_ec->command_addr && ec->data_addr == boot_ec->data_addr && !EC_FLAGS_TRUST_DSDT_GPE) { /* * Trust PNP0C09 namespace location rather than * ECDT ID. But trust ECDT GPE rather than _GPE * because of ASUS quirks, so do not change * boot_ec->gpe to ec->gpe. */ boot_ec->handle = ec->handle; acpi_handle_debug(ec->handle, "duplicated.\n"); acpi_ec_free(ec); ec = boot_ec; } The quirk only matters if boot_ec != NULL and EC_FLAGS_TRUST_DSDT_GPE is never set at the same time as EC_FLAGS_IGNORE_DSDT_GPE. That means that if the addresses match we always enter this if block and then only the ec->handle part of the data stored in ec by ec_parse_device() is used and the rest is thrown away, after which ec is made to point to boot_ec, at which point ec->gpe == boot_ec->gpe, so the same result as with the quirk set, independent of the value of the quirk. Also note the comment in this block which indicates that the gpe result from ec_parse_device() is deliberately not taken to deal with buggy Asus laptops and all DMI quirks setting EC_FLAGS_IGNORE_DSDT_GPE are for Asus laptops. Based on the above I believe that unless on some quirked laptops the ECDT and DSDT EC addresses do not match we can drop the quirk. I've checked dmesg output to ensure the ECDT and DSDT EC addresses match for quirked models using https://linux-hardware.org hw-probe reports. I've been able to confirm that the addresses match for the following models this way: GL702VMK, X505BA, X505BP, X550VXK, X580VD. Whereas for the following models I could find any dmesg output: FX502VD, FX502VE, X542BA, X542BP. Note the models without dmesg all were submitted in patches with a batch of models and other models from the same batch checkout ok. This, combined with that all the code adding the quirks was written before the generic fix makes me believe that it is safe to remove this quirk now. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Drake <drake@endlessos.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0dd6db35 |
|
20-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: EC: Remove duplicate ThinkPad X1 Carbon 6th entry from DMI quirks Somehow the "ThinkPad X1 Carbon 6th" entry ended up twice in the struct dmi_system_id acpi_ec_no_wakeup[] array. Remove one of the entries. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
13a62d0e |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rearrange code in acpi_ec_submit_event() Rearange acpi_ec_event_handler() so as to avoid releasing ec->lock and acquiring it again right away in the case when ec_event_clearing is not ACPI_EC_EVT_TIMING_EVENT. This also reduces the number of checks done by acpi_ec_event_handler() in that case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
54b86141 |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Reduce indentation level in acpi_ec_submit_event() The indentation level in acpi_ec_submit_event() can be reduced, so do that and while at it fix a typo in the comment affected by that change. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9aa60f3c |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Do not return result from advance_transaction() Notice that the if the event state is EC_EVENT_READY, the event handling work cannot be pending, so it is not necessary to check the return value of queue_work() in acpi_ec_submit_event(). Moreover, whether or not there is any EC work pending at the moment can always be checked by looking at the events_in_progress and queries_in_progress counters, so acpi_ec_submit_event() and consequently advance_transaction() need not return results. Accordingly, make acpi_ec_dispatch_gpe() always use the counters mentioned above (for first_ec) to check if there is any pending EC work to flush and turn both acpi_ec_submit_event() and advance_transaction() into void functions (again, because they were void functions in the past). While at it, add a clarifying comment about the acpi_ec_mask_events() call in advance_transaction(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
977dc308 |
|
01-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC / PM: Print additional debug message in acpi_ec_dispatch_gpe() Make acpi_ec_dispatch_gpe() print an additional debug message after seeing the EC GPE status bit set to help diagnose wakeup-related issues. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
dc0075ba |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") made acpi_ec_dispatch_gpe() check pm_wakeup_pending(), but that is before canceling the SCI wakeup, so pm_wakeup_pending() is always true. This causes the loop in acpi_ec_dispatch_gpe() to always terminate after one iteration which may not be correct. Address this issue by canceling the SCI wakeup earlier, from acpi_ec_dispatch_gpe() itself. Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
befd9b5b |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Relocate acpi_ec_create_query() and drop acpi_ec_delete_query() Move acpi_ec_create_query() after acpi_ec_event_processor(), drop the no longer needed forward declaration of the latter, and eliminate acpi_ec_delete_query() which isn't really necessary. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c33676aa |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Make the event work state machine visible The EC driver uses a relatively simple state machine for the event work handling, but it is not really straightforward to figure out. The states are as follows: "Ready": The event handling work can be submitted. In this state, the EC_FLAGS_QUERY_PENDING flag is clear. "In progress": The event handling work is pending or is being processed. It cannot be submitted again. In ths state, the EC_FLAGS_QUERY_PENDING flag is set and both the events_to_process count is nonzero and the EC_FLAGS_QUERY_GUARDING flag is clear. "Complete": The event handling work has been completed, but it still cannot be submitted again. In ths state, the EC_FLAGS_QUERY_PENDING flag is set and the events_to_process count is zero or the EC_FLAGS_QUERY_GUARDING flag is set. The state changes from "Ready" to "In progress" when new event is detected by advance_transaction() and acpi_ec_submit_event() is called by it. Next, the state can change from "In progress" directly to "Ready" in the following situations: * ec_event_clearing is ACPI_EC_EVT_TIMING_STATUS and the state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_POLL. * ec_event_clearing is ACPI_EC_EVT_TIMING_QUERY and the state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_COMPLETE. * ec_event_clearing is either ACPI_EC_EVT_TIMING_STATUS or ACPI_EC_EVT_TIMING_QUERY and there are no more events to process (ie. ec->events_to_process becomes 0). If ec_event_clearing is ACPI_EC_EVT_TIMING_EVENT, however, the state must change from "In progress" to "Complete" before it can change to "Ready". The changes from "In progress" to "Complete" in that case occur in the following situations: * The state of an ACPI_EC_COMMAND_QUERY transaction becomes ACPI_EC_COMMAND_COMPLETE. * There are no more events to process (ie. ec->events_to_process becomes 0). Finally, the state changes from "Complete" to "Ready" when advance_transaction() is invoked when the state is "Complete" and the state of the current transaction is not ACPI_EC_COMMAND_POLL. To make this state machine visible in the code, add a new event_state field to struct acpi_ec and modify the code to use it istead the EC_FLAGS_QUERY_PENDING and EC_FLAGS_QUERY_GUARDING flags. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c793570d |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Avoid queuing unnecessary work in acpi_ec_submit_event() Notice that it is not necessary to queue up the event work again if the while () loop in acpi_ec_event_handler() is still running which is the case if nr_pending_queries is greater than 0 at the beginning of acpi_ec_submit_event() and modify the code to avoid doing that. While at it, rename nr_pending_queries in struct acpi_ec to events_to_process which actually matches the role of that field and change its data type to unsigned int which is sufficient. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eafe7509 |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rename three functions Rename acpi_ec_submit_query() to acpi_ec_submit_event(), acpi_ec_query() to acpi_ec_submit_query(), and acpi_ec_complete_query() to acpi_ec_close_event() to make the names reflect what the functions do. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a105acd7 |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Simplify locking in acpi_ec_event_handler() Because acpi_ec_event_handler() is a work function, it always runs in process context with interrupts enabled, so it can use spin_lock_irq() and spin_unlock_irq() for the locking. Make it do so and adjust white space around those calls. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
388fb77d |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rearrange the loop in acpi_ec_event_handler() It is not necessary to check ec->nr_pending_queries against 0 in the while () loop in acpi_ec_event_handler(), because that loop terminates when ec->nr_pending_queries is 0 and the code depending on that can be run after the loop has ended. Modify the code accordingly and while at it rewrite the comment regarding that code to make it clearer. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
98d36450 |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Fold acpi_ec_check_event() into acpi_ec_event_handler() Because acpi_ec_event_handler() is the only caller of acpi_ec_check_event() and the separation of these two functions makes it harder to follow the code flow, fold the latter into the former (and simplify that code while at it). No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1f235044 |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Pass one argument to acpi_ec_query() Notice that the second argument to acpi_ec_query() is redundant, because in the only case when it is not NULL, the value passed through it is only checked against 0 and it can only be 0 when acpi_ec_query() returns an error code, but its return value is checked along with the value passed through its second argument. Accordingly, modify acpi_ec_query() to take only one argument and while at it, change its handling of the case when acpi_ec_transaction() returns an error so as to return that error value to the caller right away. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ca8283dc |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Call advance_transaction() from acpi_ec_dispatch_gpe() Calling acpi_dispatch_gpe() from acpi_ec_dispatch_gpe() is generally problematic, because it may cause the spurious interrupt handling in advance_transaction() to trigger in theory. However, instead of calling acpi_dispatch_gpe() to dispatch the EC GPE, acpi_ec_dispatch_gpe() can call advance_transaction() directly on first_ec and it can pass 'false' as its second argument to indicate calling it from process context. Moreover, if advance_transaction() is modified to return a bool value indicating whether or not the EC work needs to be flushed, it can be used to avoid unnecessary EC work flushing in acpi_ec_dispatch_gpe(), so change the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4a9af6ca |
|
23-Nov-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rework flushing of EC work while suspended to idle The flushing of pending work in the EC driver uses drain_workqueue() to flush the event handling work that can requeue itself via advance_transaction(), but this is problematic, because that work may also be requeued from the query workqueue. Namely, if an EC transaction is carried out during the execution of a query handler, it involves calling advance_transaction() which may queue up the event handling work again. This causes the kernel to complain about attempts to add a work item to the EC event workqueue while it is being drained and worst-case it may cause a valid event to be skipped. To avoid this problem, introduce two new counters, events_in_progress and queries_in_progress, incremented when a work item is queued on the event workqueue or the query workqueue, respectively, and decremented at the end of the corresponding work function, and make acpi_ec_dispatch_gpe() the workqueues in a loop until the both of these counters are zero (or system wakeup is pending) instead of calling acpi_ec_flush_work(). At the same time, change __acpi_ec_flush_work() to call flush_workqueue() instead of drain_workqueue() to flush the event workqueue. While at it, use the observation that the work item queued in acpi_ec_query() cannot be pending at that time, because it is used only once, to simplify the code in there. Additionally, clean up a comment in acpi_ec_query() and adjust white space in acpi_ec_event_processor(). Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
69cace6e |
|
02-Nov-2021 |
wangzhitong <wangzhitong@uniontech.com> |
ACPI: EC: Remove initialization of static variables to false Remove the initialization of two static variables to false which is pointless. Signed-off-by: wangzhitong <wangzhitong@uniontech.com> [ rjw: Subject and changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eb794e3c |
|
28-Oct-2021 |
Binbin Zhou <zhoubinbin@uniontech.com> |
ACPI: EC: Use ec_no_wakeup on HP ZHAN 66 Pro EC interrupts constantly wake up system from s2idle, so set ec_no_wakeup by default to keep the system in s2idle and reduce energy consumption. Signed-off-by: Binbin Zhou <zhoubinbin@uniontech.com> [ rjw: Changelog and subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4370cbf3 |
|
20-Jun-2021 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: EC: trust DSDT GPE for certain HP laptop On HP Pavilion Gaming Laptop 15-cx0xxx, the ECDT EC and DSDT EC share the same port addresses but different GPEs. And the DSDT GPE is the right one to use. The current code duplicates DSDT EC with ECDT EC if the port addresses are the same, and uses ECDT GPE as a result, which breaks this machine. Introduce a new quirk for the HP laptop to trust the DSDT GPE, and avoid duplicating even if the port addresses are the same. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209989 Reported-and-tested-by: Shao Fu, Chen <leo881003@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a9e10e58 |
|
03-Jun-2021 |
Daniel Scally <djrscally@gmail.com> |
ACPI: scan: Extend acpi_walk_dep_device_list() The acpi_walk_dep_device_list() function is not as generic as its name implies, serving only to decrement the dependency count for each dependent device of the input. Extend it to accept a callback which can be applied to all the dependencies in acpi_dep_list. Replace all existing calls to the function with calls to a wrapper, passing a callback that applies the same dependency reduction. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface parts Signed-off-by: Daniel Scally <djrscally@gmail.com> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6306f043 |
|
19-May-2021 |
Chris Chiu <chris.chiu@canonical.com> |
ACPI: EC: Make more Asus laptops use ECDT _GPE More ASUS laptops have the _GPE define in the DSDT table with a different value than the _GPE number in the ECDT. This is causing media keys not working on ASUS X505BA/BP, X542BA/BP Add model info to the quirks list. Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2a39a30f |
|
23-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Clean up status flags checks in advance_transaction() Eliminate comparisons from the status flags checks in advance_transaction() (especially from the one that is only correct, because the value of the flag checked in there is 1) and rearrange the code for more clarity while at it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
631734fc |
|
23-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Untangle error handling in advance_transaction() Introduce acpi_ec_spurious_interrupt() for recording spurious interrupts and use it for error handling in advance_transaction(), drop the (now redundant) original error handling block from there along with a frew goto statements that are not necessary any more. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
902675fa |
|
23-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Simplify error handling in advance_transaction() Notice that the value of t in advance_transaction() does not change after its initialization and: - Initialize t upfront (and rearrange the definitions of local variables while at it). - Check it against NULL in a block executed when it is NULL. - Skip error handling for t == NULL, because a valid pointer value of t is required for the error handling. - Drop the (now redundant) check of t against NULL from the error handling block and reduce the indentation level in there. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d2a2e6cc |
|
23-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rename acpi_ec_is_gpe_raised() Rename acpi_ec_is_gpe_raised() into acpi_ec_gpe_status_set(), update its callers accordingly and drop the ternary operator (which isn't really necessary in there) from it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d269fb03 |
|
23-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Fold acpi_ec_clear_gpe() into its caller Fold acpi_ec_clear_gpe() which is only used in one place into its caller and clean up comments related to that function while at it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2e84ea5a |
|
13-Nov-2020 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
ACPI: EC: Eliminate in_interrupt() usage advance_transaction() is using in_interrupt() to distinguish between an invocation from the interrupt handler and an invocation from another part of the stack. This looks misleading because chains like acpi_update_all_gpes() -> acpi_ev_gpe_detect() -> acpi_ev_detect_gpe() -> acpi_ec_gpe_handler() should probably also behave as if they were called from an interrupt handler. Replace in_interrupt() usage with a function parameter. Set this parameter to `true' if invoked from an interrupt handler (acpi_ec_gpe_handler() and acpi_ec_irq_handler()) and `false' otherwise. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e0e9ce39 |
|
05-Oct-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Drop ec_no_wakeup check from acpi_ec_dispatch_gpe() It turns out that in some cases there are EC events to flush in acpi_ec_dispatch_gpe() even though the ec_no_wakeup kernel parameter is set and the EC GPE is disabled while sleeping, so drop the ec_no_wakeup check that prevents those events from being processed from acpi_ec_dispatch_gpe(). Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5e92442b |
|
05-Oct-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Flush EC work unconditionally after wakeup Commit 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive") has been reported to cause some power button wakeup events to be missed on some systems, so modify acpi_ec_dispatch_gpe() to call acpi_ec_flush_work() unconditionally to effectively reverse the changes made by that commit. Also note that the problem which prompted commit 607b9df63057 is not reproducible any more on the affected machine. Fixes: 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive") Reported-by: Raymond Tan <raymond.tan@intel.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fc293b7a |
|
16-Jun-2020 |
Xiongfeng Wang <wangxiongfeng2@huawei.com> |
ACPI: EC: add newline when printing 'ec_event_clearing' module parameter When I cat acpi module parameter '/sys/module/acpi/parameters/ec_event_clearing', it displays as follows. It is better to add a newline for easy reading. [root@hulk-202 ~]# cat /sys/module/acpi/parameters/ec_event_clearing query[root@hulk-202 ~]# Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5fcd7359 |
|
19-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: s2idle: Extend GPE dispatching debug message Add the "ACPI" string to the "EC GPE dispatched" message as it is ACPI-related. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
607b9df6 |
|
14-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive Flushing the EC work while suspended to idle when the EC GPE status is not set causes some EC wakeup events (notably power button and lid ones) to be missed after a series of spurious wakeups on the Dell XPS13 9360 in my office. If that happens, the machine cannot be woken up from suspend-to-idle by the power button or lid status change and it needs to be woken up in some other way (eg. by a key press). Flushing the EC work only after successful dispatching the EC GPE, which means that its status has been set, avoids the issue, so change the code in question accordingly. Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Chris Chiu <chiu@endlessm.com>
|
#
a10660f7 |
|
10-May-2020 |
Pascal Terjan <pterjan@google.com> |
ACPI: Delete unused proc filename macros Those were used to create files in /proc/acpi long ago and were missed when that code was deleted. Signed-off-by: Pascal Terjan <pterjan@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7b301750 |
|
09-May-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake() If the EC GPE status is not set after checking all of the other GPEs, acpi_s2idle_wake() returns 'false', to indicate that the SCI event that has just triggered is not a system wakeup one, but it does that without canceling the pending wakeup and re-arming the SCI for system wakeup which is a mistake, because it may cause s2idle_loop() to busy spin until the next valid wakeup event. [If that happens, the first spurious wakeup is still pending after acpi_s2idle_wake() has returned, so s2idle_enter() does nothing, acpi_s2idle_wake() is called again and it sees that the SCI has triggered, but no GPEs are active, so 'false' is returned again, and so on.] Fix that by moving all of the GPE checking logic from acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the latter return 'true' only if a non-EC GPE has triggered and 'false' otherwise, which will cause acpi_s2idle_wake() to cancel the pending SCI wakeup and re-arm the SCI for system wakeup regardless of the EC GPE status. This also addresses a lockup observed on an Elitegroup EF20EA laptop after attempting to wake it up from suspend-to-idle by a key press. Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check") Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603 Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Link: https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=MvyG_PE+PGVfeA17AHF5i5JucgaKqqMX6mjArbQ@mail.gmail.com/ Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu <chiu@endlessm.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f900bf49 |
|
07-May-2020 |
Hanjun Guo <guohanjun@huawei.com> |
ACPI: EC: Put the ACPI table after using it The embedded controller boot resources table needs to be released after using it. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> [ rjw: avoid adding a label in acpi_ec_ecdt_start() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d7e0481c |
|
06-Apr-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Fix up fast path check in acpi_ec_add() The fast path check in acpi_ec_add() is not incorrect, because in fact acpi_device_hid(device) can be equal to ACPI_ECDT_HID only if boot_ec is not NULL, but it may confuse static checkers, so change it to explicitly check boot_ec upfront and use the slow path if that pointer is NULL. Link: https://lore.kernel.org/linux-acpi/20200406144217.GA68494@mwanda/ Fixes: 3d9b8dd8320d ("ACPI: EC: Use fast path in acpi_ec_add() for DSDT boot EC") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d5406284 |
|
25-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Refine active GPEs check The check for any active GPEs added by commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") turns out to be insufficiently precise to prevent some systems from resuming prematurely due to a spurious EC wakeup, so refine it by first checking if any GPEs other than the EC GPE are active and skipping all of the SCIs coming from the EC that do not produce any genuine wakeup events after processing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629 Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Reported-by: Ondřej Caletka <ondrej@caletka.cz> Tested-by: Ondřej Caletka <ondrej@caletka.cz> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b1e14999 |
|
05-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Eliminate EC_FLAGS_QUERY_HANDSHAKE The EC_FLAGS_QUERY_HANDSHAKE switch is never set in the current code (the only function setting it is defined under #if 0) and has no effect whatever, so eliminate it and drop the code depending on it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
65a691f5 |
|
05-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add() The reason for clearing boot_ec_is_ecdt in acpi_ec_add() (if a PNP0C09 device object matching the ECDT boot EC had been found in the namespace) was to cause acpi_ec_ecdt_start() to return early, but since the latter does not look at boot_ec_is_ecdt any more, acpi_ec_add() need not clear it. Moreover, doing that may be confusing as it may cause "DSDT" to be printed instead of "ECDT" in the EC initialization completion message, so stop doing it. While at it, split the EC initialization completion message into two messages, one regarding the boot EC and another one printed regardless of whether or not the EC at hand is the boot one. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
98ada3c5 |
|
05-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Simplify acpi_ec_ecdt_start() and acpi_ec_init() Notice that the return value of acpi_ec_init() is discarded anyway, so it can be void and it doesn't need to check the return values of acpi_bus_register_driver() and acpi_ec_ecdt_start() called by it. Thus the latter can be void too and it really has nothing to do if acpi_ec_add() has already found an EC matching the boot one in the namespace. Also, acpi_ec_ecdt_get_handle() can be folded into it. Modify the code accordingly and while at it create a propoer kerneldoc comment to document acpi_ec_ecdt_start() and move the remark regarding ASUS X550ZE along with the related bug URL from acpi_ec_init() into that comment. Additionally, fix up a stale comment in acpi_ec_init(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
03e9a0e0 |
|
03-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Consolidate event handler installation code Commit 406857f773b0 ("ACPI: EC: add support for hardware-reduced systems") made ec_install_handlers() return an error on failures to configure a GPIO IRQ for the EC, but that is inconsistent with the handling of the GPE event handler installation failures even though it is exactly the same issue and the driver can respond to it in the same way in both cases (the EC can be actively polled for events through its registers if the event handler installation fails). Moreover, it requires acpi_ec_add() to take that special case into account and disagrees with the ec_install_handlers() header comment. For this reason, rework the event handler installation code in ec_install_handlers() to explicitly take deferred probing (that may be needed in the GPIO IRQ case) into account and to avoid failing the EC initialization in any other case. Among other things, reduce code duplication between install_gpe_event_handler() and install_gpio_irq_event_handler() by moving some code from there into ec_install_handlers() itself and simplify the error code path in acpi_ec_add(). While at it, turn the ec_install_handlers() header comment into a proper kerneldoc one and add some general control flow information to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Jian-Hong Pan <jian-hong@endlessm.com>
|
#
3d9b8dd8 |
|
02-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Use fast path in acpi_ec_add() for DSDT boot EC If the boot EC comes from the DSDT, its ACPI handle is equal to the handle of a device object with the PNP0C09 device ID. If that device object is passed to acpi_ec_add(), it is not necessary to allocate a new EC structure for it and parse it, because that has been done already, so change the function to use the fast path in that case. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e3cfabcd |
|
02-Mar-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Simplify acpi_ec_add() First, notice that if the device ID in acpi_ec_add() is equal to ACPI_ECDT_HID, boot_ec_is_ecdt must be set, because this means that the device object passed to acpi_ec_add() comes from acpi_ec_ecdt_start() which fails if boot_ec_is_ecdt is unset. Accordingly, boot_ec_is_ecdt need not be set again in that case, so drop that redundant update of it from the code. Next, ec->handle must be a valid ACPI handle right before returning 0 from acpi_ec_add(), because it either is the handle of the device object passed to that function, or it is the boot EC handle coming from acpi_ec_ecdt_start() which fails if it cannot find a valid handle for the boot EC. Moreover, the object with that handle is regarded as a valid representation of the EC in all cases, so there is no reason to avoid the _DEP list update walk if that handle is the boot EC handle. Accordingly, drop the dep_update local variable from acpi_ec_add() and call acpi_walk_dep_device_list() for ec->handle unconditionally before returning 0 from it. Finally, the ec local variable in acpi_ec_add() need not be initialized to NULL and the status local variable declaration can be moved to the block in which it is used, so change the code in accordance with these observations. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7247f0c2 |
|
27-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Drop AE_NOT_FOUND special case from ec_install_handlers() If the status value returned by acpi_install_address_space_handler() in ec_install_handlers() is AE_NOT_FOUND, it is treated in a special way, apparently because it might mean a _REG method evaluation failure (at least that is the case according to the comment in there), but acpi_install_address_space_handler() does not take _REG evaluation errors into account at all, so the AE_NOT_FOUND special handling is confusing at best. For this reason, change ec_install_handlers() to stop the EC and return -ENODEV on all acpi_install_address_space_handler() errors. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a2b69177 |
|
27-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Avoid passing redundant argument to functions After commit 406857f773b0 ("ACPI: EC: add support for hardware-reduced systems") the handle_events argument passed to ec_install_handlers() and acpi_ec_setup() is redundant, because it is always 'false' when the device argument passed to them in NULL and it is always 'true' otherwise, so the device argument can be tested against NULL instead of testing the handle_events one. Accordingly, modify ec_install_handlers() and acpi_ec_setup() to take two arguments and reduce the number of checks in the former. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c823c17a |
|
27-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Avoid printing confusing messages in acpi_ec_setup() It doesn't really make sense to pass ec->handle of the ECDT EC to acpi_handle_info(), because it is set to ACPI_ROOT_OBJECT in acpi_ec_ecdt_probe(), so rework acpi_ec_setup() to avoid using acpi_handle_info() for printing messages. First, notice that the "Used as first EC" message is not really useful, because it is immediately followed by a more meaningful one from either acpi_ec_ecdt_probe() or acpi_ec_dsdt_probe() (the latter also includes the EC object path), so drop it altogether. Second, use pr_info() for printing the EC configuration information. While at it, make the code in question avoid printing invalid GPE or IRQ numbers and make it print the GPE/IRQ information only when the driver is ready to handle events. Fixes: 72c77b7ea9ce ("ACPI / EC: Cleanup first_ec/boot_ec code") Fixes: 406857f773b0 ("ACPI: EC: add support for hardware-reduced systems") Cc: 5.5+ <stable@vger.kernel.org> # 5.5+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f0ac20c3 |
|
11-Feb-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Fix flushing of pending work Commit 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work") introduced a subtle bug into the flushing of pending EC work while suspended to idle, which may cause the EC driver to fail to re-enable the EC GPE after handling a non-wakeup event (like a battery status change event, for example). The problem is that the work item flushed by flush_scheduled_work() in __acpi_ec_flush_work() may disable the EC GPE and schedule another work item expected to re-enable it, but that new work item is not flushed, so __acpi_ec_flush_work() returns with the EC GPE disabled and the CPU running it goes into an idle state subsequently. If all of the other CPUs are in idle states at that point, the EC GPE won't be re-enabled until at least one CPU is woken up by another interrupt source, so system wakeup events that would normally come from the EC then don't work. This is reproducible on a Dell XPS13 9360 in my office which sometimes stops reacting to power button and lid events (triggered by the EC on that machine) after switching from AC power to battery power or vice versa while suspended to idle (each of those switches causes the EC GPE to trigger for several times in a row, but they are not system wakeup events). To avoid this problem, it is necessary to drain the workqueue entirely in __acpi_ec_flush_work(), but that cannot be done with respect to system_wq, because work items may be added to it from other places while __acpi_ec_flush_work() is running. For this reason, make the EC driver use a dedicated workqueue for EC events processing (let that workqueue be ordered so that EC events are processed sequentially) and use drain_workqueue() on it in __acpi_ec_flush_work(). Fixes: 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3df663a1 |
|
27-Dec-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Reference count query handlers under lock There is a race condition in acpi_ec_get_query_handler() theoretically allowing query handlers to go away before refernce counting them. In order to avoid it, call kref_get() on query handlers under ec->mutex. Also simplify the code a bit while at it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
016b87ca |
|
28-Nov-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Rework flushing of pending work There is a race condition in the ACPI EC driver, between __acpi_ec_flush_event() and acpi_ec_event_handler(), that may cause systems to stay in suspended-to-idle forever after a wakeup event coming from the EC. Namely, acpi_s2idle_wake() calls acpi_ec_flush_work() to wait until the delayed work resulting from the handling of the EC GPE in acpi_ec_dispatch_gpe() is processed, and that function invokes __acpi_ec_flush_event() which uses wait_event() to wait for ec->nr_pending_queries to become zero on ec->wait, and that wait queue may be woken up too early. Suppose that acpi_ec_dispatch_gpe() has caused acpi_ec_gpe_handler() to run, so advance_transaction() has been called and it has invoked acpi_ec_submit_query() to queue up an event work item, so ec->nr_pending_queries has been incremented (under ec->lock). The work function of that work item, acpi_ec_event_handler() runs later and calls acpi_ec_query() to process the event. That function calls acpi_ec_transaction() which invokes acpi_ec_transaction_unlocked() and the latter wakes up ec->wait under ec->lock, but it drops that lock before returning. When acpi_ec_query() returns, acpi_ec_event_handler() acquires ec->lock and decrements ec->nr_pending_queries, but at that point __acpi_ec_flush_event() (woken up previously) may already have acquired ec->lock, checked the value of ec->nr_pending_queries (and it would not have been zero then) and decided to go back to sleep. Next, if ec->nr_pending_queries is equal to zero now, the loop in acpi_ec_event_handler() terminates, ec->lock is released and acpi_ec_check_event() is called, but it does nothing unless ec_event_clearing is equal to ACPI_EC_EVT_TIMING_EVENT (which is not the case by default). In the end, if no more event work items have been queued up while executing acpi_ec_transaction_unlocked(), there is nothing to wake up __acpi_ec_flush_event() again and it sleeps forever, so the suspend-to-idle loop cannot make progress and the system is permanently suspended. To avoid this issue, notice that it actually is not necessary to wait for ec->nr_pending_queries to become zero in every case in which __acpi_ec_flush_event() is used. First, during platform-based system suspend (not suspend-to-idle), __acpi_ec_flush_event() is called by acpi_ec_disable_event() after clearing the EC_FLAGS_QUERY_ENABLED flag, which prevents acpi_ec_submit_query() from submitting any new event work items, so calling flush_scheduled_work() and flushing ec_query_wq subsequently (in order to wait until all of the queries in that queue have been processed) would be sufficient to flush all of the pending EC work in that case. Second, the purpose of the flushing of pending EC work while suspended-to-idle described above really is to wait until the first event work item coming from acpi_ec_dispatch_gpe() is complete, because it should produce system wakeup events if that is a valid EC-based system wakeup, so calling flush_scheduled_work() followed by flushing ec_query_wq is also sufficient for that purpose. Rework the code to follow the above observations. Fixes: 56b9918490 ("PM: sleep: Simplify suspend-to-idle control flow") Reported-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
406857f7 |
|
14-Oct-2019 |
Daniel Drake <drake@endlessm.com> |
ACPI: EC: add support for hardware-reduced systems As defined in the ACPI spec section 12.11, ACPI hardware-reduced platforms define the EC SCI interrupt as a GpioInt in the _CRS object. This replaces the previous way of using a GPE for this interrupt; GPE blocks are not available on reduced hardware platforms. Add support for handling this interrupt as an EC event source, and avoid GPE usage on reduced hardware platforms. This enables the use of several media keys (e.g. screen brightness up/down) on Asus UX434DA. Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4446abc9 |
|
14-Oct-2019 |
Daniel Drake <drake@endlessm.com> |
ACPI: EC: tweak naming in preparation for GpioInt support In preparation for supporting reduced hardware platforms which use a GpioInt instead of a GPE, rename some functions and constants to have more appropriate names. No logical changes. Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b90ff355 |
|
21-Aug-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Always set up EC GPE for system wakeup Commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") assumed that the EC GPE would only need to be set up for system wakeup if either the intel-hid or the intel-vbtn driver was in use, but that turns out to be incorrect. In particular, on ASUS Zenbook UX430UNR/i7-8550U, if the EC GPE is not enabled while suspended, the system cannot be woken up by opening the lid or pressing a key, and that machine doesn't use any of the drivers mentioned above. For this reason, always set up the EC GPE for system wakeup from suspend-to-idle by setting and clearing its wake mask in the ACPI suspend-to-idle callbacks. Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it") Reported-by: Kristian Klausen <kristian@klausen.dk> Tested-by: Kristian Klausen <kristian@klausen.dk> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
29113f2f |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Make acpi_ec_dispatch_gpe() print debug message Add a pm_pr_dbg() debug statement to acpi_ec_dispatch_gpe() to print a message when the EC GPE has been dispatched (because its status was set). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
d7589404 |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: PM: Consolidate some code depending on PM_SLEEP Move some routines, including acpi_ec_dispatch_gpe(), that are only used if CONFIG_PM_SLEEP is set to the #ifdef block containing the EC suspend and resume callbacks, to make the "full EC PM picture" easier to follow. While at it, move the header of acpi_ec_dispatch_gpe() in the header file to a CONFIG_PM_SLEEP #ifdef block. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
6e86633a |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Eliminate acpi_sleep_no_ec_events() Change acpi_ec_suspend() to use pm_suspend_no_platform() instead of acpi_sleep_no_ec_events(), which allows the latter to be eliminated along with the s2idle_in_progress variable which is only used by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
fcd0a042 |
|
31-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: s2idle: Switch EC over to polling during "noirq" suspend Since the ACPI SCI is set up for system wakeup before the "noirq" suspend of devices, it is better to make suspend-to-idle follow suspend-to-RAM (S3) and switch over the EC to polling during "noirq" suspend (and back to interrupt-based flow during "noirq" resume). The frequency of spurious wakeup interrupts from the EC may be reduced this way. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
#
10a08fd6 |
|
30-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: PM: Set up EC GPE for system wakeup from drivers that need it The EC GPE needs to be set up for system wakeup only if there is a driver depending on it, either intel-hid or intel-vbtn, bound to a button device that is expected to wake up the system from sleep (such as the power button on some Dell systems, like the XPS13 9360). It doesn't need to be set up for waking up the system from sleep in any other cases and whether or not it is expected to wake up the system from sleep doesn't depend on whether or not the LPS0 device is present in the ACPI namespace. For this reason, rearrange the ACPI suspend-to-idle code to make the drivers depending on the EC GPE wakeup take care of setting it up and decouple that from the LPS0 device handling. While at it, make intel-hid and intel-vbtn prepare for system wakeup only if they are allowed to wake up the system from sleep by user space (via sysfs). [Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask() are there to prevent the EC GPE from being disabled by the acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on systems with either intel-hid or intel-vbtn this change doesn't affect any interactions with the hardware or platform firmware.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
9089f16e |
|
15-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Return bool from acpi_ec_dispatch_gpe() On some systems, if suspend-to-idle is used, the EC may signal system wakeup events (power button events, for example) as well as events that should not cause the system to resume and acpi_ec_dispatch_gpe() needs to be called to determine whether or not the system should resume then. In particular, if acpi_ec_dispatch_gpe() doesn't detect any EC events at all, the system should remain suspended, so it is useful to know when that is the case. For this reason, make acpi_ec_dispatch_gpe() return a bool value indicating whether or not any EC events have been detected by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
c942fddf |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b6a3e147 |
|
31-Jan-2019 |
Zhang Rui <rui.zhang@intel.com> |
Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk" On some Samsung hardware, it is necessary to clear events accumulated by the EC during sleep. These ECs stop reporting GPEs until they are manually polled, if too many events are accumulated. Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands unconditionally after resume to clear all the EC query events on those platforms. Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ polling logic should handle this case. Now it has been proved that the EC IRQ Polling logic does not fix the issue actually because we got regression report on these Samsung platforms after removing the quirk. Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk") to introduce back the Samsung quirk in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Tested-by: Ortwin Glück <odi@odi.ch> Tested-by: Francisco Cribari <cribari@gmail.com> Tested-by: Balazs Varga <balazs4web@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
116f2b34 |
|
31-Jan-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Simplify boot EC checks in acpi_ec_add() Consolidate boot EC checks in acpi_ec_add(), put the acpi_is_boot_ec() checks directly into it and drop the latter. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d2c62aef |
|
31-Jan-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Eliminate acpi_config_boot_ec() Notice that acpi_ec_add() calls acpi_config_boot_ec() when it finds that the device object passed to it represents a "boot" EC, but in that case the ec pointer passed to acpi_config_boot_ec() is guaranteed to be equal to boot_ec and ec->handle is passed as the handle argument to it, so acpi_config_boot_ec() really only calls acpi_ec_setup() and prints a message. Avoid the pointless checks in acpi_config_boot_ec() by calling acpi_ec_setup() directly and print the message separately. With the above changes in place, there are no users of acpi_config_boot_ec(), so drop it. No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c746b6b6 |
|
01-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Make acpi_ec_dsdt_probe() more straightforward Since acpi_ec_dsdt_probe() returns early if boot_ec is set, it is always unset when that function calls acpi_config_boot_ec() (passing ec->handle as the handle argument to it). Thus it is not really useful to call acpi_config_boot_ec() at that point. It is sufficient to call acpi_ec_setup() directly and (if that is successful) set boot_ec, so make acpi_ec_dsdt_probe() do that and avoid some pointless checks in acpi_config_boot_ec(). No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1568426c |
|
01-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Make acpi_ec_ecdt_probe() more straightforward Since acpi_ec_ecdt_probe() is called when boot_ec is not set, it doesn't neeed to take the other possibility into account. Accordingly, it only needs to set the handle field in the ec object to ACPI_ROOT_OBJECT, call acpi_ec_setup() and (if that is successful) set boot_ec to ec and boot_ec_is_ecdt to 'true'. Make it do so directly, without calling acpi_config_boot_ec(), and avoid some pointless checks in the latter. No intentional functional impact except for a changed message. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a9c30768 |
|
01-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Declare boot_ec as static The boot_ec variable is not used outside of the file it is defined in, so declare it as static. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fdb3c177 |
|
21-Jan-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Clean up probing for early EC Both acpi_ec_dsdt_probe() and acpi_ec_ecdt_probe() may be void as their return values are ignored anyway. This allows a couple of gotos and labels to go away from there. Moreover, acpi_ec_ecdt_probe() only needs to allocate the ec object after getting the ECDT pointer and checking it, so the pointless memory allocation and release on systems without the ECDT can be avoided by reordering it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f941d3e4 |
|
16-Dec-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle There are systems in which non-wakeup GPEs fire during the "noirq" suspend stage of suspending devices and that effectively prevents the system that tries to suspend to idle from entering any low-power state at all. If the offending GPE fires regularly and often enough, the system appears to be suspended, but in fact it is in a tight loop over "noirq" suspend and "noirq" resume of devices all the time. To prevent that from happening, disable all non-wakeup GPEs except for the EC GPE for suspend-to-idle (the EC GPE is special, because on some systems it has to be enabled for power button wakeup events to be generated as expected). Fixes: 147a7d9d25ca (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle) Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987 Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4c3be61e |
|
07-Aug-2018 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / EC: Add another entry for Thinkpad X1 Carbon 6th Commit 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) changed the DMI table to match all systems where DMI product family is "Thinkpad X1 Carbon 6th". However, the system I have here has this string written differently (ThinkPad vs. Thinkpad) which makes the match fail. In addition to that, after BIOS upgrade Robin now has the same string than my system has (perhaps newer BIOS has changed the string). In any case add another DMI entry to acpi_ec_no_wakeup[] table hopefully covering all the X1 Carbon 6th systems out there. Fixes: 2c4d6baf1bc4 (ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> [ rjw: Rebase and change the ident string to match the product familiy ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b047c62e |
|
31-Jul-2018 |
Aaron Ma <aaron.ma@canonical.com> |
ACPI / EC: Use ec_no_wakeup on ThinkPad X1 Yoga 3rd Like on X1C6, on X1Y3 EC interrupts constantly wake up system from s2idle, the power consumption is extremely high. So make ec_no_wakeup be true as default to keep system in s2idle mode and reduce power consumption. Power button works when ec_no_wakeup=true. Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2c4d6baf |
|
13-Jul-2018 |
Robin H. Johnson <robbat2@gentoo.org> |
ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems beyond matched only a single DMI model (20KGS3JF01), that didn't cover my laptop (20KH002JUS). Change to match based on DMI product family to cover all X1 6th gen systems. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8195a655 |
|
18-Jun-2018 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / EC: Use ec_no_wakeup on Thinkpad X1 Carbon 6th On this system EC interrupt triggers constantly kicking devices out of low power states and thus blocking power management. The system also has a PCIe root port hosting Alpine Ridge Thunderbolt controller and it never gets a chance to go to D3cold because of this. Since the power button works the same regardless if EC interrupt is enabled or not during s2idle, add a quirk for this machine that sets ec_no_wakeup=true preventing spurious wakeups. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
68e22011 |
|
16-May-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: EC: Dispatch the EC GPE directly on s2idle wake On platforms where the Low Power S0 Idle _DSM interface is used, on wakeup from suspend-to-idle, when it is known that the ACPI SCI has triggered while suspended, dispatch the EC GPE in order to catch all EC events that may have triggered the wakeup before carrying out the noirq phase of device resume. That is needed to handle power button wakeup on some platforms where the EC goes into a low-power mode during suspend-to-idle and while in that mode it will discard events after a timeout. If that timeout is shorter than the time it takes to complete the noirq resume of devices, looking for EC events after the latter is too late. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Wendy Wang <wendy.wang@intel.com>
|
#
3cd091a7 |
|
09-Feb-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / EC: Restore polling during noirq suspend/resume phases Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) modified the ACPI EC driver so that it doesn't switch over to busy polling mode during noirq stages of system suspend and resume in an attempt to fix an issue resulting from that behavior. However, that modification introduced a system resume regression on Thinkpad X240, so make the EC driver switch over to the polling mode during noirq stages of system suspend and resume again, which effectively reverts the problematic commit. Fixes: 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression) Link: https://bugzilla.kernel.org/show_bug.cgi?id=197863 Reported-by: Markus Demleitner <m@tfiu.de> Tested-by: Markus Demleitner <m@tfiu.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3522f867 |
|
02-Jan-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
ACPI: EC: Fix debugfs_create_*() usage acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose the wrong half on big-endian 64-bit systems. Fix this by changing its type to "u32" and removing the cast, as all other code already uses u32 or sometimes even only u8. Fixes: 1195a098168fcacf (ACPI: Provide /sys/kernel/debug/ec/...) Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a64a62ce |
|
26-Sep-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix regression related to PM ops support in ECDT device On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an ACPI device. Thus the following commit actually removed post-resume acpi_ec_enable_event() invocation for such platforms, and triggered a regression on them that after being resumed, EC (actually should be ECDT) driver stops handling EC events: Commit: c2b46d679b30c5c0d7eb47a21085943242bdd8dc Subject: ACPI / EC: Add PM operations to improve event handling for resume process Notice that the root cause actually is "ECDT is not an ACPI device" rather than "the timing of acpi_ec_enable_event() invocation", this patch fixes this issue by enumerating ECDT EC as an ACPI device. Due to the existence of the noirq stage, the ability of tuning the timing of acpi_ec_enable_event() invocation is still meaningful. This patch is a little bit different from the posted fix by moving acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make sure that EC event handling won't be stopped as long as the ACPI EC driver is bound. Thus the following sequence shouldn't disable EC event handling: unbind,suspend,resume,bind. Fixes: c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847 Reported-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
53c5eaab |
|
26-Sep-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix regression related to triggering source of EC event handling Originally the Samsung quirks removed by commit 4c237371 can be covered by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956 changed ec_freeze_events=Y back to N, making this problem re-surface. Actually, if commit e923e8e7 is robust enough, we can freely change ec_freeze_events mode, so this patch fixes the issue by improving commit e923e8e7. Related commits listed in the merged order: Commit: e923e8e79e18fd6be9162f1be6b99a002e9df2cb Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled Commit: 4c237371f290d1ed3b2071dd43554362137b1cce Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk Commit: 9c40f956ce9b331493347d1b3cb7e384f7dc0581 Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix a regression This patch not only fixes the reported post-resume EC event triggering source issue, but also fixes an unreported similar issue related to the driver bind by adding EC event triggering source in ec_install_handlers(). Fixes: e923e8e79e18 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled) Fixes: 4c237371f290 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk) Fixes: 9c40f956ce9b (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-by: Alistair Hamilton <ahpatent@gmail.com> Tested-by: Alistair Hamilton <ahpatent@gmail.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e4dca7b7 |
|
17-Oct-2017 |
Kees Cook <keescook@chromium.org> |
treewide: Fix function prototypes for module_param_call() Several function prototypes for the set/get functions defined by module_param_call() have a slightly wrong argument types. This fixes those in an effort to clean up the calls when running under type-enforced compiler instrumentation for CFI. This is the result of running the following semantic patch: @match_module_param_call_function@ declarer name module_param_call; identifier _name, _set_func, _get_func; expression _arg, _mode; @@ module_param_call(_name, _set_func, _get_func, _arg, _mode); @fix_set_prototype depends on match_module_param_call_function@ identifier match_module_param_call_function._set_func; identifier _val, _param; type _val_type, _param_type; @@ int _set_func( -_val_type _val +const char * _val , -_param_type _param +const struct kernel_param * _param ) { ... } @fix_get_prototype depends on match_module_param_call_function@ identifier match_module_param_call_function._get_func; identifier _val, _param; type _val_type, _param_type; @@ int _get_func( -_val_type _val +char * _val , -_param_type _param +const struct kernel_param * _param ) { ... } Two additional by-hand changes are included for places where the above Coccinelle script didn't notice them: drivers/platform/x86/thinkpad_acpi.c fs/lockd/svc.c Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jessica Yu <jeyu@kernel.org>
|
#
6faadbbb |
|
14-Sep-2017 |
Christoph Hellwig <hch@lst.de> |
dmi: Mark all struct dmi_system_id instances const ... 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 <hch@lst.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
|
#
56f77eeb |
|
11-Aug-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Clean up EC GPE mask flag 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: Lv Zheng <lv.zheng@intel.com> Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
69b957c2 |
|
16-Aug-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: EC: Fix possible issues related to EC initialization order 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: Lv Zheng <lv.zheng@intel.com> [ rjw : Changelog & comments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
98529b92 |
|
16-Aug-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: EC: Fix regression related to wrong ECDT initialization order Commit 2a5708409e4e (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 c712bb58d827 (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: 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) Fixes: c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe) Reported-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
880a6627 |
|
19-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM / EC: Flush all EC work in acpi_freeze_sync() Commit eed4d47efe95 (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: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
76380636 |
|
19-Jul-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / EC: Add parameter to force disable the GPE on suspend After commit 8110dd281e15 (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: 8110dd281e15 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) Reported-and-tested-by: Patrik Kullman <patrik.kullman@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9c40f956 |
|
11-Jul-2017 |
Lv Zheng <lv.zheng@intel.com> |
Revert "ACPI / EC: Enable event freeze mode..." to fix a regression 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: d30283057ecd (ACPI / EC: Enable event freeze mode to improve event handling) Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168 Tested-by: Damjan Georgievski <gdamjan@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
66259146 |
|
11-Jul-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Drop EC noirq hooks to fix a regression 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: c3a696b6e8f8 (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=196129 Reported-by: Andreas Lindhe <andreas@lindhe.io> Tested-by: Gjorgji Jankovski <j.gjorgji@gmail.com> Tested-by: Damjan Georgievski <gdamjan@gmail.com> Tested-by: Fernando Chaves <nanochaves@gmail.com> Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com> Tested-by: Denis P. <theoriginal.skullburner@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ef75040a |
|
14-Jun-2017 |
Carlo Caione <carlo@caione.org> |
ACPI / EC: Add quirk for GL720VMK ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
440f53da |
|
14-Jun-2017 |
Chris Chiu <chiu@endlessm.com> |
ACPI / EC: Fix media keys not working problem on some Asus laptops 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=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Carlo Caione <carlo@caione.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c712bb58 |
|
14-Jun-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add support to skip boot stage DSDT probe 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: c5279dee26c0e8d7c4200993bfc4b540d2469598 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=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog & comments massage ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ae56c9fd |
|
14-Jun-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Enhance boot EC sanity check 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=195651 Tested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4625d752 |
|
13-Jun-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: EC: Fix EC command visibility for dynamic debug 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: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1ab69f27 |
|
13-Jun-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: EC: Fix an EC event IRQ storming issue The EC event IRQ (SCI_EVT) can only be handled by submitting QR_EC. As the EC driver handles SCI_EVT in a workqueue, after SCI_EVT is flagged and before QR_EC is submitted, there is a period risking IRQ storming. EC IRQ must be masked for this period but linux EC driver never does so. No end user notices the IRQ storming and no developer fixes this known issue because: 1. The EC IRQ is always edge triggered GPE, and 2. The kernel can execute no-op EC IRQ handler very fast. For edge-triggered EC GPE platforms, it is only reported of post-resume EC event lost issues, there won't be an IRQ storming. For level triggered EC GPE platforms, fortunately the kernel is always fast enough to execute such a no-op EC IRQ handler so that the IRQ handler won't be accumulated to starve the task contexts, causing a real IRQ storming. But the IRQ storming actually can still happen when: 1. The EC IRQ performs like level triggered GPE, and 2. The kernel EC debugging log is turned on but the console is slow enough. There are more and more platforms using EC GPE as wake GPE where the EC GPE is likely designed as level triggered. Then when EC debugging log is enabled, the EC IRQ handler is no longer a no-op but dumps IRQ status to the consoles. If the consoles are slow enough, the EC IRQs can arrive much faster than executing the handler. Finally the accumulated EC event IRQ handlers starve the task contexts, causing the IRQ storming to occur, and the kernel hangs can be observed during boot/resume. This patch fixes this issue by masking EC IRQ for this period: 1. Begins when there is an SCI_EVT IRQ pending, and 2. Ends when there is a QR_EC completed (SCI_EVT acknowledged). Tested-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8110dd28 |
|
23-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems Some recent Dell laptops, including the XPS13 model numbers 9360 and 9365, cannot be woken up from suspend-to-idle by pressing the power button which is unexpected and makes that feature less usable on those systems. Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is not expected to be used at all (the OS these systems ship with never exercises the ACPI S3 path in the firmware) and suspend-to-idle is the only viable system suspend mechanism there. The reason why the power button wakeup from suspend-to-idle doesn't work on those systems is because their power button events are signaled by the EC (Embedded Controller), whose GPE (General Purpose Event) line is disabled during suspend-to-idle transitions in Linux. That is done on purpose, because in general the EC tends to be noisy for various reasons (battery and thermal updates and similar, for example) and all events signaled by it would kick the CPUs out of deep idle states while in suspend-to-idle, which effectively might defeat its purpose. Of course, on the Dell systems in question the EC GPE must be enabled during suspend-to-idle transitions for the button press events to be signaled while suspended at all, but fortunately there is a way out of this puzzle. First of all, those systems have the ACPI_FADT_LOW_POWER_S0 flag set in their ACPI tables, which means that the OS is expected to prefer the "low power S0 idle" system state over ACPI S3 on them. That causes the most recent versions of other OSes to simply ignore ACPI S3 on those systems, so it is reasonable to expect that it should not be necessary to block GPEs during suspend-to-idle on them. Second, in addition to that, the systems in question provide a special firmware interface that can be used to indicate to the platform that the OS is transitioning into a system-wide low-power state in which certain types of activity are not desirable or that it is leaving such a state and that (in principle) should allow the platform to adjust its operation mode accordingly. That interface is a special _DSM object under a System Power Management Controller device (PNP0D80). The expected way to use it is to invoke function 0 from it on system initialization, functions 3 and 5 during suspend transitions and functions 4 and 6 during resume transitions (to reverse the actions carried out by the former). In particular, function 5 from the "Low-Power S0" device _DSM is expected to cause the platform to put itself into a low-power operation mode which should include making the EC less verbose (so to speak). Next, on resume, function 6 switches the platform back to the "working-state" operation mode. In accordance with the above, modify the ACPI suspend-to-idle code to look for the "Low-Power S0" _DSM interface on platforms with the ACPI_FADT_LOW_POWER_S0 flag set in the ACPI tables. If it's there, use it during suspend-to-idle transitions as prescribed and avoid changing the GPE configuration in that case. [That should reflect what the most recent versions of other OSes do.] Also modify the ACPI EC driver to make it handle events during suspend-to-idle in the usual way if the "Low-Power S0" _DSM interface is going to be used to make the power button events work while suspended on the Dell machines mentioned above Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b6aeab44 |
|
20-May-2017 |
Vincent Legoll <vincent.legoll@gmail.com> |
ACPI: fix whitespace in pr_fmt() to align log entries See this dmesg extract before the patch: [ 0.679466] ACPI: Dynamic OEM Table Load: [ 0.679470] ACPI: SSDT 0xFFFF910F6B497E00 00018A (v02 PmRef ApCst 00003000 INTL 20160422) [ 0.679579] ACPI: Executed 1 blocks of module-level executable AML code [ 0.681477] ACPI : EC: EC started [ 0.681478] ACPI : EC: interrupt blocked [ 0.684798] ACPI: Interpreter enabled [ 0.684835] ACPI: (supports S0 S3 S4 S5) Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c3a696b6 |
|
20-Jan-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Use busy polling mode when GPE is not enabled When GPE is not enabled, it is not efficient to use the wait polling mode as it introduces an unexpected scheduler delay. So before the GPE handler is installed, this patch uses busy polling mode for all EC(s) and the logic can be applied to non boot EC(s) during the suspend/resume process. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561 Tested-by: Jakobus Schurz <jakobus.schurz@gmail.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4c237371 |
|
03-Jan-2017 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove old CLEAR_ON_RESUME quirk IRQ polling logic has been implemented to drain the post-boot/resume EC events: 1. Triggered by the following code, invoked from acpi_ec_enable_event(): if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) advance_transaction(ec); 2. Drained by the following code, invoked after acpi_ec_complete_query(): if (status & ACPI_EC_FLAG_SCI) acpi_ec_submit_query(ec); This facility is safer than the old CLEAR_ON_RESUME quirk as the CLEAR_ON_RESUME quirk sends EC query commands unconditionally. The behavior is apparently not suitable for firmware that requires QUERY_HANDSHAKE quirk. Though the QUERY_HANDSHAKE quirk isn't used now because of the improvement done in the EC transaction state machine (ec_event_clearing=QUERY), it is the proof that we cannot send EC query command unconditionally. So it's time to delete the out-dated CLEAR_ON_RESUME quirk to let the users to try the newer approach. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191211 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eab05ec3 |
|
05-Oct-2016 |
Eric Biggers <ebiggers@google.com> |
ACPI / EC: Fix unused function warning when CONFIG_PM_SLEEP=n Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
97cb159f |
|
07-Sep-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix issues related to boot_ec There are issues related to the boot_ec: 1. If acpi_ec_remove() is invoked, boot_ec will also be freed, this is not expected as the boot_ec could be enumerated via ECDT. 2. Address space handler installation/unstallation lead to unexpected _REG evaluations. This patch adds acpi_is_boot_ec() check to be used to fix the above issues. However, since acpi_ec_remove() actually won't be invoked, this patch doesn't handle the reference counting of "struct acpi_ec", it only ensures the correctness of the boot_ec destruction during the boot. Link: https://bugzilla.kernel.org/show_bug.cgi?id=153511 Reported-and-tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2a570840 |
|
07-Sep-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a gap that ECDT EC cannot handle EC events It is possible to register _Qxx from namespace and use the ECDT EC to perform event handling. The reported bug reveals that Windows is using ECDT in this way in case the namespace EC is not present. This patch facilitates Linux to support ECDT in this way. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
46922d2a |
|
07-Sep-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a memory leakage issue in acpi_ec_add() When the handler installation failed, there was no code to free the allocated EC device. This patch fixes this memory leakage issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
72c77b7e |
|
07-Sep-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup first_ec/boot_ec code In order to support full ECDT (driving the ECDT EC after probing the namespace EC), we need to change our EC device alloc/free algorithm, ensure not to free old boot EC before qualifying new boot EC. This patch achieves this by cleaning up first_ec/boot_ec logic: 1. first_ec: used to perform transactions, so it is assigned in new acpi_ec_setup() function. 2. boot_ec: used to track early EC device, so it is assigned in new acpi_config_boot_ec() function which explictly tells the driver to save the EC device as early EC device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d3028305 |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Enable event freeze mode to improve event handling for suspend process This patch enables the event freeze mode, flushing the EC event handling in .suspend() callback. This feature is experimental, if it is bisected out to be the cause of the real issues, please report the issues to the kernel bugzilla for further root causing and improvement. This mode eliminates useless _Qxx handling during the power saving operations, thus can help to tune the power saving operations faster. Tests show that this mode can efficiently block flooding _Qxx during the suspend process and tune the speed of the suspend faster. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
39a2a2aa |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add PM operations to improve event handling for suspend process In the original EC driver, though the event handling is not explicitly stopped, the EC driver is actually not able to handle events during the noirq stage as the EC driver is not prepared to handle the EC events in the polling mode. So if there is no advance_transaction() triggered, the EC driver couldn't notice the EC events. However, do we actually need to handle EC events during suspend/resume stage? EC events are mostly useless for the suspend/resume period (key strokes and battery/thermal updates, etc.,), and the useful ones (lid close, power/sleep button press) should have already been delivered to the OSPM to trigger the power saving operations. Thus this patch implements acpi_ec_disable_event() to be a reverse call of acpi_ec_enable_event(), with which, the EC driver is able to stop handling the EC events in a position before entering the noirq stage. Since there are actually 2 choices for us: 1. implement event handling in polling mode; 2. stop event handling before entering noirq stage. And this patch only implements the second choice using .suspend() callback. Thus this is experimental (first choice is better? or different hook position is better?). This patch finally keeps the old behavior by default and prepares a boot parameter to enable this feature. The differences of the event handling availability between the old behavior (this patch is not applied) and the new behavior (this patch is applied) are as follows: !FreezeEvents FreezeEvents before suspend Y Y suspend before EC Y Y suspend after EC Y N suspend_late Y N suspend_noirq Y (actually N) N resume_noirq Y (actually N) N resume_late Y (actually N) N resume before EC Y (actually N) N resume after EC Y Y after resume Y Y Where "actually N" means if there is no EC transactions, the EC driver is actually not able to notice the pending events. We can see that FreezeEvents is the only approach now can actually flush the EC event handling with both query commands and _Qxx evaluations flushed, other modes can only flush the EC event handling with only query commands flushed, _Qxx evaluations occurred after stopping the EC driver may end up failure due to the failure of the EC transaction carried out in the _Qxx control methods. We also can see that this feature should be able to trigger some platform notifications later than resuming other drivers. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c2b46d67 |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add PM operations to improve event handling for resume process This patch makes 2 changes: 1. Restore old behavior Originally, EC driver stops handling both events and transactions in acpi_ec_block_transactions(), and restarts to handle transactions in acpi_ec_unblock_transactions_early(), restarts to handle both events and transactions in acpi_ec_unblock_transactions(). While currently, EC driver still stops handling both events and transactions in acpi_ec_block_transactions(), but restarts to handle both events and transactions in acpi_ec_unblock_transactions_early(). This patch tries to restore the old behavior by dropping __acpi_ec_enable_event() from acpi_unblock_transactions_early(). 2. Improve old behavior However this still cannot fix the real issue as both of the acpi_ec_unblock_xxx() functions are invoked in the noirq stage. Since the EC driver actually doesn't implement the event handling in the polling mode, re-enabling the event handling too early in the noirq stage could result in the problem that if there is no triggering source causing advance_transaction() to be invoked, pending SCI_EVT cannot be detected by the EC driver and _Qxx cannot be triggered. It actually makes sense to restart the event handling in any point during resuming after the noirq stage. Just like the boot stage where the event handling is enabled in .add(), this patch further moves acpi_ec_enable_event() to .resume(). After doing that, the following 2 functions can be combined: acpi_ec_unblock_transactions_early()/acpi_ec_unblock_transactions(). The differences of the event handling availability between the old behavior (this patch isn't applied) and the new behavior (this patch is applied) are as follows: !Applied Applied before suspend Y Y suspend before EC Y Y suspend after EC Y Y suspend_late Y Y suspend_noirq Y (actually N) Y (actually N) resume_noirq Y (actually N) Y (actually N) resume_late Y (actually N) Y (actually N) resume before EC Y (actually N) Y (actually N) resume after EC Y (actually N) Y after resume Y (actually N) Y Where "actually N" means if there is no triggering source, the EC driver is actually not able to notice the pending SCI_EVT occurred in the noirq stage. So we can clearly see that this patch has improved the situation. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e923e8e7 |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled After enabling the EC event handling, Linux is still in the noirq stage, if there is no triggering source (EC transaction, GPE STS status), advance_transaction() will not be invoked and SCI_EVT cannot be detected. This patch adds one more triggering source after enabling the EC event handling to poll the pending SCI_EVT. Known issues: 1. Still no SCI_EVT triggering source There could still be no SCI_EVT triggering source after handling the first SCI_EVT (polled by this patch if any). Because after handling the first SCI_EVT, Linux could still be in noirq stage and there could still be no further triggering source in this stage. Then the second SCI_EVT indicated during this stage still cannot be detected by the EC driver. With this improvement applied, it is then possible to move acpi_ec_enable_event() out of the noirq stage to fix this issue (if the first SCI_EVT is handled out of the noirq stage, the follow-up SCI_EVTs should be able to trigger IRQs). Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
750f628b |
|
03-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add EC_FLAGS_QUERY_ENABLED to reveal a hidden logic There is a hidden logic in the EC driver: 1. During boot, EC_FLAGS_QUERY_PENDING is responsible for blocking event handling; 2. During suspend, EC_FLAGS_STARTED is responsible for blocking event handling. This patch uses a new EC_FLAGS_QUERY_ENABLED flag to make this hidden logic explicit and have code cleaned up. No functional change. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
df45db61 |
|
02-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add PM operations for suspend/resume noirq stage It is reported that on some platforms, resume speed is not fast. The cause is: in noirq stage, EC driver is working in polling mode, and each state machine advancement requires a context switch. The context switch is not necessary to the EC driver's polling mode. This patch implements PM hooks to automatically switch the driver to/from the busy polling mode to eliminate the overhead caused by the context switch. This finally contributes to the tuning result: acpi_pm_finish() execution time is improved from 192ms to 6ms. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-and-tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e1191bd4 |
|
02-Aug-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx A regression is caused by the following commit: Commit: 02b771b64b73226052d6e731a0987db3b47281e9 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations In this commit, using system workqueue causes that the maximum parallel executions of _Qxx can exceed 255. This violates the method reentrancy limit in ACPICA and generates the following error log: ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341) This patch creates a seperate workqueue and limits the number of parallel _Qxx evaluations down to a configurable value (can be tuned against number of online CPUs). Since EC events are handled after driver probe, we can create the workqueue in acpi_ec_init(). Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691 Cc: 4.3+ <stable@vger.kernel.org> # 4.3+ Reported-and-tested-by: Helen Buus <ubuntu@hbuus.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fa5b4a50 |
|
07-Jul-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix code ordering issue in ec_remove_handlers() There is an order issue in ec_remove_handlers() that acpi_ec_stop() is called before removing the operation region handler. That is incorrect, because the operation region handler removal triggers _REG(DISCONNECT) which may result in new EC transactions to carry out. That existing issue has been triggered by the following commit: Commit: dcf15cbded656a12335bc4151f3f75f10080a375 Subject: ACPI / EC: Fix a boot EC regresion by restoring boot EC which changed the driver to call ec_remove_handlers() after invoking _REG(CONNECT), so the issue has become visible. Fixes: dcf15cbded65 (ACPI / EC: Fix a boot EC regresion by restoring boot EC) Link: https://bugzilla.kernel.org/show_bug.cgi?id=102421 Reported-and-tested-by: Wolfram Sang <wsa@the-dreams.de> Reported-by: Nicholas <nkudriavtsev@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bc539567 |
|
21-Jun-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove wrong ECDT correction quirks Our Windows probe result shows that EC._REG is evaluated after evaluating all _INI/_STA control methods. With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as long as there is no EC opregion accesses in the MLC (module level code, AML code out of any control methods) and in _INI/_STA, there is no need to make sure that ECDT must be correct. Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA evaluations contain EC accesses while the ECDT setting is wrong. >From the acpidump output posted on bug 9399, we can see that it is actually a different issue. In this table, if EC._REG is not executed, EC accesses will be done in a platform specific manner. As we've already ensured not to execute EC._REG during the eary stage, we can remove the quirks for bug 9399. From the acpidump output posted on bug 12461, we can see that it still needs the quirk. In this table, EC._REG flags a named object whose default value is One, thus BAT1._STA surely should invoke EC accesses whatever we invoke EC._REG or not. We have to keep the quirk for it before we can root cause the issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
fd6231e7 |
|
21-Jun-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup boot EC code using acpi_ec_alloc() Failure handling of the boot EC code is not tidy. This patch cleans them up with acpi_ec_alloc(). This patch also changes acpi_ec_dsdt_probe(), always switches the boot EC from the ECDT one to the DSDT one in this function. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
dcf15cbd |
|
02-Jun-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC According to the Windows probing result, during the table loading, the EC device described in the ECDT should be used. And the ECDT EC is also effective during the period the namespace objects are initialized (we can see a separate process executing _STA/_INI on Windows before executing other device specific control methods, for example, EC._REG). During the device enumration, the EC device described in the DSDT should be used. But there are differences between Linux and Windows around the device probing order. Thus in Linux, we should enable the DSDT EC as early as possible before enumerating devices in order not to trigger issues related to the device enumeration order differences. This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to fix the gap. This also fixes a user reported regression triggered after we switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant. Fixes: 59f0aa9480cf (ACPI 2.0 / ECDT: Remove early namespace reference from EC) Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261 Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
59f0aa94 |
|
23-Mar-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI 2.0 / ECDT: Remove early namespace reference from EC All operation region accesses are allowed by AML interpreter when AML is executed, so actually BIOSen are responsible to avoid the operation region accesses in AML before OSPM has prepared an operation region driver. This is done via _REG control method. So AML code normally sets a global named object REGC to 1 when _REG(3, 1) is evaluated. Then what is ECDT? Quoting from ACPI spec 6.0, 5.2.15 Embedded Controller Boot Resources Table (ECDT): "The presence of this table allows OSPM to provide Embedded Controller operation region space access before the namespace has been evaluated." Spec also suggests a compatible mean to indicate the early EC access availability: Device (EC) { Name (REGC, Ones) Method (_REG, 2) { If (LEqual (Arg0, 3)) { Store (Arg1, REGC) } } Method (ECAV) { If (LEqual (REGC, Ones)) { If (LGreaterEqual (_REV, 2)) { Return (One) } Else { Return (Zero) } } Else { Return (REGC) } } } In this way, it allows EC accesses to happen before EC._REG(3, 1) is invoked. But ECAV is not the only way practical BIOSen using to indicate the early EC access availibility, the known variations include: 1. Setting REGC to One in \_SB._INI when _REV >= 2. Since \_SB._INI is the first control method evaluated by OSPM during the enumeration, this allows EC accesses to happen for the entire enumeration process before the namespace EC is enumerated. 2. Initialize REGC to One by default, this even allows EC accesses to happen during the table loading. Linux is now broken around ECDT support during the long term bug fixing work because it has merged many wrong ECDT bug fixes (see details below). Linux currently uses namespace EC's settings instead of ECDT settings when ECDT is detected. This apparently will result in namespace walk and _CRS/_GPE/_REG evaluations. Such stuffs could only happen after namespace is ready, while ECDT is purposely to be used before namespace is ready. The wrong bug fixing story is: 1. Link 1: At Linux ACPI early stages, "no _Lxx/_Exx/_Qxx evaluation can happen before the namespace is ready" are not ensured by ACPICA core and Linux. This is currently ensured by deferred enabling of GPE and defered registering of EC query methods (acpi_ec_register_query_methods). 2. Link 2: Reporters reported buggy ECDTs, expecting quirks for the platform. Originally, the quirk is simple, only doing things with ECDT. Bug 9399 and 12461 are platforms (Asus L4R, Asus M6R, MSI MS-171F) reported to have wrong ECDT IO port addresses, the port addresses are reversed. Bug 11880 is a platform (Asus X50GL) reported to have 0 valued port addresses, we can see that all EC accesses are protected by ECAV on this platform, so actually no early EC accesses is required by this platform. 3. Link 3: But when the bug fixing developer was requested to provide a handy and non-quirk bug fix, he tried to use correct EC settings from namespace and broke the spec purpose. We can even see that the developer was suffered from many regrssions. One interesting one is 14086, where the actual root cause obviously should be: _REG is evaluated too early. But unfortunately, the bug is fixed in a totally wrong way. So everything goes wrong from these commits: Commit: c6cb0e878446c79f42e7833d7bb69ed6bfbb381f Subject: ACPI: EC: Don't trust ECDT tables from ASUS Commit: a5032bfdd9c80e0231a6324661e123818eb46ecd Subject: ACPI: EC: Always parse EC device This patch reverts Linux behavior to simple ECDT quirk support in order to stop early _CRS/_GPE/_REG evaluations. For Bug 9399, 12461, since it is reported that the platforms require early EC accesses, this patch restores the simple ECDT quirks for them. For Bug 11880, since it is not reported that the platform requires early EC accesses and its ACPI tables contain correct ECAV, we choose an ECDT enumeration failure for this platform. Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=9916 http://bugzilla.kernel.org/show_bug.cgi?id=10100 https://lkml.org/lkml/2008/2/25/282 Link 2: https://bugzilla.kernel.org/show_bug.cgi?id=9399 https://bugzilla.kernel.org/show_bug.cgi?id=12461 https://bugzilla.kernel.org/show_bug.cgi?id=11880 Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=11884 https://bugzilla.kernel.org/show_bug.cgi?id=14081 https://bugzilla.kernel.org/show_bug.cgi?id=14086 https://bugzilla.kernel.org/show_bug.cgi?id=14446 Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0e1affe4 |
|
23-Mar-2016 |
Lv Zheng <lv.zheng@intel.com> |
ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED This patch splits EC_FLAGS_HANDLERS_INSTALLED so that address space handler can be installed when it is not possible to install GPE handler during early stage. This patch also tunes address space handler installation, making it happening earlier than GPE handler installation for the same purpose. Since acpi_ec_start()/acpi_ec_stop() will be entered multiple times after applying this change, it is also required to protect acpi_enable_gpe()/ acpi_disable_gpe() invocations. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4981c2b7 |
|
15-Nov-2015 |
Markus Elfring <elfring@users.sourceforge.net> |
ACPI-EC: Drop unnecessary check made before calling acpi_ec_delete_query() The acpi_ec_delete_query() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
61197547 |
|
24-Sep-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a race issue in acpi_ec_guard_event() In acpi_ec_guard_event(), EC transaction state machine variables should be checked with the EC spinlock locked. The bug doesn't trigger any real issue now because this bug can only occur when the ec_event_clearing=event mode is applied while there is no user currently using this mode. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0700c047 |
|
24-Sep-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix query handler related issues 1. acpi_ec_remove_query_handlers() This patch refines the query handler removal logic implemented in acpi_ec_remove_query_handler(), making it to invoke new acpi_ec_remove_query_handlers() API, and ensuring all other removal code paths to invoke the new API to honor the reference count of the query handlers. 2. acpi_ec_get_query_handler_by_value() This patch also refines the query handler search logic originally implemented in acpi_ec_query(), collecting it into acpi_ec_get_query_handler_by_value(). And since schedule_work() can ensure the serilization of acpi_ec_event_handler(), we needn't put the mutex_lock() around schedule_work(). Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
15b94fa3 |
|
24-Sep-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a memory leak issue in acpi_ec_query() When query handler is not found, "result" is actually stil 0, and "struct acpi_ec_query" is not NULL, so the deletion code of "struct acpi_ec_query" at the end of the function cannot be invoked. As a consequence, memory leak can be observed. The issue is introduced by this commit: Commit: 02b771b64b73226052d6e731a0987db3b47281e9 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx This patch fixes such memory leakage. Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
02b771b6 |
|
11-Aug-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations It is proven that Windows evaluates _Qxx handlers in a parallel way. This patch follows this fact, splits _Qxx evaluations from the NOTIFY queue to form a separate queue, so that _Qxx evaluations can be queued up on different CPUs rather than being queued up on a CPU0 bound queue. Event handling related callbacks are also renamed and sorted in this patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4c62dbbc |
|
26-Jun-2015 |
Jarkko Nikula <jarkko.nikula@linux.intel.com> |
ACPI: Remove FSF mailing addresses There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
66db3834 |
|
10-Jun-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed. When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents the event handling work queue from being scheduled again. Though there shouldn't be failed QR_EC transactions, and this gap was efficiently used for catching and learning the SCI_EVT clearing timing compliance issues, we need to fix this as we are not fully compatible with all platforms/Windows to handle SCI_EVT clearing timing correctly. Fixing this gives the EC driver the chances to recover from a state machine failure. So this patch fixes this issue. When nr_pending_queries drops to 0, it clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in order to ensure that the SCI_EVT handling can proceed. In order to be clearer for future ec_event_clearing modes, all checks in this patch are written in the inclusive style, not the exclusive style. Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3cb02aeb |
|
10-Jun-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing. It is reported that on several platforms, EC firmware will not respond non-expected QR_EC (see EC_FLAGS_QUERY_HANDSHAKE, only write QR_EC when SCI_EVT is set). Unfortunately, ACPI specification doesn't define when the SCI_EVT should be cleared by the firmware, thus the original implementation queued up second QR_EC right after writing QR_EC command and before reading the returned event value as at that time the SCI_EVT is ensured not cleared. This behavior is also based on the assumption that the firmware should be able to return 0x00 to indicate "no outstanding event". This behavior did fix issues on Samsung platforms where the spurious query value of 0x00 is supported and didn't break platforms in my test queue. But recently, specific Acer, Asus, Lenovo platforms keep on blaming this change. This patch changes the behavior to re-check the SCI_EVT a bit later and removes EC_FLAGS_QUERY_HANDSHAKE quirks, hoping this is the Windows compliant EC driver behavior. In order to be robust to the possible regressions, instead of removing the quirk directly, this patch keeps the quirk code, removes the quirk users and keeps old behavior for Samsung platforms. Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381 Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111 Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Reported-and-tested-by: Tigran Gabrielyan <tigrangab@gmail.com> Reported-and-tested-by: Adrien D <ghbdtn@openmailbox.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1d68d261 |
|
10-Jun-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add event clearing variation support. We've been suffering from the uncertainty of the SCI_EVT clearing timing. This patch implements 3 of 4 possible modes to handle SCI_EVT clearing variations. The old behavior is kept in this patch. Status: QR_EC is re-checked as early as possible after checking previous SCI_EVT. This always leads to 2 QR_EC transactions per SCI_EVT indication and the target may implement event queue which returns 0x00 indicating "no outstanding event". This is proven to be a conflict against Windows behavior, but is still kept in this patch to make the EC driver robust to the possible regressions that may occur on Samsung platforms. Query: QR_EC is re-checked after the target has handled the QR_EC query request command pushed by the host. Event: QR_EC is re-checked after the target has noticed the query event response data pulled by the host. This timing is not determined by any IRQs, so we may need to use a guard period in this mode, which may explain the existence of the ec_guard() code used by the old EC driver where the re-check timing is implemented in the similar way as this mode. Method: QR_EC is re-checked as late as possible after completing the _Qxx evaluation. The target may implement SCI_EVT like a level triggered interrupt. It is proven on kernel bugzilla 94411 that, Windows will have all _Qxx evaluations parallelized. Thus unless required by further evidences, we needn't implement this mode as it is a conflict of the _Qxx parallelism requirement. Note that, according to the reports, there are platforms that cannot be handled using the "Status" mode without enabling the EC_FLAGS_QUERY_HANDSHAKE quirk. But they can be handled with the other modes according to the tests (kernel bugzilla 97381). The following log entry can be used to confirm the differences of the 3 modes as it should appear at the different positions for the 3 modes: Command(QR_EC) unblocked Status: appearing after EC_SC(W) = 0x84 Query: appearing after EC_DATA(R) = 0xXX where XX is the event number used to determine _QXX Event: appearing after first EC_SC(R) = 0xX0 SCI_EVT=x BURST=0 CMD=0 IBF=0 OBF=0 that is next to the following log entry: Command(QR_EC) completed by hardware Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411 Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381 Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111 Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Reported-and-tested-by: Tigran Gabrielyan <tigrangab@gmail.com> Reported-and-tested-by: Adrien D <ghbdtn@openmailbox.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9d8993be |
|
10-Jun-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Convert event handling work queue into loop style. During the period that a work queue is scheduled (queued up for run) but hasn't been run, second schedule_work() could fail. This may not lead to the loss of queries because QR_EC is always ensured to be submitted after the work queue has been in the running state. The event handling work queue can be changed into the loop style to allow us to control the code in a more flexible way: 1. Makes it possible to add event=0x00 termination condition in the loop. 2. Increases the thoughput of the QR_EC transactions as the 2nd+ QR_EC transactions may be handled in the same work item used for the 1st QR_EC transaction, thus the delay caused by the 2nd+ work item scheduling can be eliminated. Except the logging message changes and the throughput improvement, this patch is just a funcitonal no-op. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Tested-by: Tigran Gabrielyan <tigrangab@gmail.com> Tested-by: Adrien D <ghbdtn@openmailbox.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f8b8eb71 |
|
10-Jun-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup transaction state transition. This patch collects transaction state transition code into one function. We then could have a single function to maintain transaction transition related behaviors. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Tested-by: Tigran Gabrielyan <tigrangab@gmail.com> Tested-by: Adrien D <ghbdtn@openmailbox.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3174abcf |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove non-root-caused busy polling quirks. { Update to correct 1 patch subject in the description } We have fixed a lot of race issues in the EC driver recently. The following commit introduces MSI udelay()/msleep() quirk to MSI laptops to make EC firmware working for bug 12011 without root causing any EC driver race issues: Commit: 5423a0cb3f74c16e90683f8ee1cec6c240a9556e Subject: ACPI: EC: Add delay for slow MSI controller Commit: 34ff4dbccccce54c83b1234d39b7ad9e548a75dd Subject: ACPI: EC: Separate delays for MSI hardware The following commit extends ECDT validation quirk to MSI laptops to make EC driver locating EC registers properly for bug 12461: Commit: a5032bfdd9c80e0231a6324661e123818eb46ecd Subject: ACPI: EC: Always parse EC device This is a different quirk than the MSI udelay()/msleep() quirk. This patch keeps validating ECDT for only "Micro-Star MS-171F" as reported. The following commit extends MSI udelay()/msleep() quirk to Quanta laptops to make EC firmware working for bug 20242, there is no requirement to validate ECDT for Quanta laptops: Commit: 534bc4e3d27096e2f3fc00c14a20efd597837a4f Mon Sep 17 00:00:00 2001 Subject: ACPI EC: enable MSI workaround for Quanta laptops The following commit extends MSI udelay()/msleep() quirk to Clevo laptops to make EC firmware working for bug 77431, there is no requirement to validate ECDT for Clevo laptops: Commit: 777cb382958851c88763253fe00a26529be4c0e9 Subject: ACPI / EC: Add msi quirk for Clevo W350etq All udelay()/msleep() quirks for MSI/Quanta/Clevo seem to be the wrong fixes generated without fixing the EC driver race issues. And even if it is not wrong, the guarding can be covered by the following commits in wait polling mode: Commit: 9e295ac14d6a59180beed0735e6a504c2ee87761 Subject: ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp. Commit: commit in the same series Subject: ACPI / EC: Fix and clean up register access guarding logics. The only case that is not covered is the inter-transaction guarding. And there is no evidence that we need the inter-transaction guarding upon reading the noted bug entries. So it is time to remove the quirks and let the users to try again. If there is a regression, the only thing we need to do is to restore the inter-transaction guarding for the reported platforms. Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011 Link: https://bugzilla.kernel.org/show_bug.cgi?id=12461 Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
15de603b |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add module params for polling modes. We have 2 polling modes in the EC driver: 1. busy polling: originally used for the MSI quirks. udelay() is used to perform register access guarding. 2. wait polling: normal code path uses wait_event_timeout() and it can be woken up as soon as the transaction is completed in the interrupt mode. It also contains the register acces guarding logic in case the interrupt doesn't arrive and the EC driver is about to advance the transaction in task context (the polling mode). The wait polling is useful for interrupt mode to allow other tasks to use the CPU during the wait. But for the polling mode, the busy polling takes less time than the wait polling, because if no interrupt arrives, the wait polling has to wait the minimal HZ interval. We have a new use case for using the busy polling mode. Some GPIO drivers initialize PIN configuration which cause a GPIO multiplexed EC GPE to be disabled out of the GPE register's control. Busy polling mode is useful here as it takes less time than the wait polling. But the guarding logic prevents it from responding even faster. We should spinning around the EC status rather than spinning around the nop execution lasted a determined period. This patch introduces 2 module params for the polling mode switch and the guard time, so that users can use the busy polling mode without the guarding in case the guarding is not necessary. This is an example to use the 2 module params for this purpose: acpi.ec_busy_polling acpi.ec_polling_guard=0 We've tested the patch on a test platform. The platform suffers from such kind of the GPIO PIN issue. The GPIO driver resets all PIN configuration and after that, EC interrupt cannot arrive because of the multiplexing. Then the platform suffers from a long delay carried out by the wait_event_timeout() as all further EC transactions will run in the polling mode. We switched the EC driver to use the busy polling mechanism instead of the wait timeout polling mechanism and the delay is still high: [ 44.283005] calling PNP0C0B:00+ @ 1305, parent: platform [ 44.417548] call PNP0C0B:00+ returned 0 after 131323 usecs And this patch can significantly reduce the delay: [ 44.502625] calling PNP0C0B:00+ @ 1308, parent: platform [ 44.503760] call PNP0C0B:00+ returned 0 after 1103 usecs Tested-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d8d031a6 |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix and clean up register access guarding logics. In the polling mode, EC driver shouldn't access the EC registers too frequently. Though this statement is concluded from the non-root caused bugs (see links below), we've maintained the register access guarding logics in the current EC driver. The guarding logics can be found here and there, makes it hard to root cause real timing issues. This patch collects the guarding logics into one single function so that all hidden logics related to this can be seen clearly. The current guarding related code also has several issues: 1. Per-transaction timestamp prevents inter-transaction guarding from being implemented in the same place. We have an inter-transaction udelay() in acpi_ec_transaction_unblocked(), this logic can be merged into ec_poll() if we can use per-device timestamp. This patch completes such merge to form a new ec_guard() function and collects all guarding related hidden logics in it. One hidden logic is: there is no inter-transaction guarding performed for non MSI quirk (wait polling mode), this patch skips inter-transaction guarding before wait_event_timeout() for the wait polling mode to reveal the hidden logic. The other hidden logic is: there is msleep() inter-transaction guarding performed when the GPE storming is observed. As after merging this commit: Commit: e1d4d90fc0313d3d58cbd7912c90f8ef24df45ff Subject: ACPI / EC: Refine command storm prevention support EC_FLAGS_COMMAND_STORM is ensured to be cleared after invoking acpi_ec_transaction_unlocked(), the msleep() guard logic will never happen now. Since no one complains such change, this logic is likely added during the old times where the EC race issues are not fixed and the bugs are false root-caused to the timing issue. This patch simply removes the out-dated logic. We can restore it by stop skipping inter-transaction guarding for wait polling mode. Two different delay values are defined for msleep() and udelay() while they are merged in this patch to 550us. 2. time_after() causes additional delay in the polling mode (can only be observed in noirq suspend/resume processes where polling mode is always used) before advance_transaction() is invoked ("wait polling" log is added before wait_event_timeout()). We can see 2 wait_event_timeout() invocations. This is because time_after() ensures a ">" validation while we only need a ">=" validation here: [ 86.739909] ACPI: Waking up from system sleep state S3 [ 86.742857] ACPI : EC: 2: Increase command [ 86.742859] ACPI : EC: ***** Command(RD_EC) started ***** [ 86.742861] ACPI : EC: ===== TASK (0) ===== [ 86.742871] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0 [ 86.742873] ACPI : EC: EC_SC(W) = 0x80 [ 86.742876] ACPI : EC: ***** Event started ***** [ 86.742880] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 86.743972] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 86.747966] ACPI : EC: ===== TASK (0) ===== [ 86.747977] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0 [ 86.747978] ACPI : EC: EC_DATA(W) = 0x06 [ 86.747981] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 86.751971] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 86.755969] ACPI : EC: ===== TASK (0) ===== [ 86.755991] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1 [ 86.755993] ACPI : EC: EC_DATA(R) = 0x03 [ 86.755994] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 86.755995] ACPI : EC: ***** Command(RD_EC) stopped ***** [ 86.755996] ACPI : EC: 1: Decrease command This patch corrects this by using time_before() instead in ec_guard(): [ 54.283146] ACPI: Waking up from system sleep state S3 [ 54.285414] ACPI : EC: 2: Increase command [ 54.285415] ACPI : EC: ***** Command(RD_EC) started ***** [ 54.285416] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 54.285417] ACPI : EC: ===== TASK (0) ===== [ 54.285424] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0 [ 54.285425] ACPI : EC: EC_SC(W) = 0x80 [ 54.285427] ACPI : EC: ***** Event started ***** [ 54.285429] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 54.287209] ACPI : EC: ===== TASK (0) ===== [ 54.287218] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0 [ 54.287219] ACPI : EC: EC_DATA(W) = 0x06 [ 54.287222] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 54.291190] ACPI : EC: ===== TASK (0) ===== [ 54.291210] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1 [ 54.291213] ACPI : EC: EC_DATA(R) = 0x03 [ 54.291214] ACPI : EC: ~~~~~ wait polling ~~~~~ [ 54.291215] ACPI : EC: ***** Command(RD_EC) stopped ***** [ 54.291216] ACPI : EC: 1: Decrease command After cleaning up all guarding logics, we have one single function ec_guard() collecting all old, non-root-caused, hidden logics. Then we can easily tune the logics in one place to respond to the bug reports. Except the time_before() change, all other changes do not change the behavior of the EC driver. Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011 Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
373783e6 |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove irqs_disabled() check. The following commit merges polling and interrupt modes for EC driver: Commit: 2a84cb9852f52c0cd1c48bca41a8792d44ad06cc Mon Sep 17 00:00:00 2001 Subject: ACPI: EC: Merge IRQ and POLL modes The irqs_disabled() check introduced in it tries to fall into busy polling mode when the context of ec_poll() cannot sleep. Actually ec_poll() is ensured to be invoked in the contexts that can sleep (from a sysfs /sys/kernel/debug/ec/ec0/io access, or from acpi_evaluate_object(), or from acpi_ec_gpe_poller()). Without the MSI quirk, we never saw the udelay() logic invoked. Thus this check is useless and can be removed. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5ab82a11 |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove storming threashold enlarging quirk. This patch removes the storming threashold enlarging quirk. After applying the following commit, we can notice that there is no no-op GPE handling invocation can be observed, thus it is unlikely that the no-op counts can exceed the storming threashold: Commit: ca37bfdfbc8d0a3ec73e4b97bb26dcfa51d515aa Subject: ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode. Even when the storming happens, we have already limited its affection to the only transaction and no further transactions will be affected. This is done by this commit: Commit: e1d4d90fc0313d3d58cbd7912c90f8ef24df45ff Subject: ACPI / EC: Refine command storm prevention support So it's time to remove this quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=45151 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7c0b2595 |
|
15-May-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Update acpi_ec_is_gpe_raised() with new GPE status flag. This patch updates acpi_ec_is_gpe_raised() according to the following commit: Commit: 09af8e8290deaff821ced01ea83594ee4c21e8df Subject: ACPICA: Events: Add support to return both enable/status register values for GPE and fixed event. This is actually a no-op change as both the flags are defined to a same value. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6b5eab54 |
|
21-Apr-2015 |
Chris Bainbridge <chris.bainbridge@gmail.com> |
ACPI / EC: fix NULL pointer dereference in acpi_ec_remove_query_handler() Use list_for_each_entry_safe for iterating because handler may be freed in the loop. BUG: unable to handle kernel NULL pointer dereference at 000000000000002c IP: [<ffffffff814d69c8>] acpi_ec_put_query_handler+0x7/0x1a Call Trace: acpi_ec_remove_query_handler+0x87/0x97 acpi_smbus_hc_remove+0x2a/0x44 [sbshc] acpi_device_remove+0x7b/0x9a __device_release_driver+0x7e/0x110 driver_detach+0xb0/0xc0 bus_remove_driver+0x54/0xe0 driver_unregister+0x2b/0x60 acpi_bus_unregister_driver+0x10/0x12 acpi_smb_hc_driver_exit+0x10/0x12 [sbshc] SyS_delete_module+0x1b8/0x210 system_call_fastpath+0x12/0x6a Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1c832b3e |
|
31-Mar-2015 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler On some machines(E,G Mircosoft surface 3), ACPI battery depends on the EC operation region and it has _DEP method which contains EC. Current code doesn't support such devices whose dep_unmet will be not be decreased after EC opregion handler being installed. This blocks battery device to be attached with its driver. This patch is to fix the issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=90161 Reported-and-tested-by: Lompik <lompik@voila.fr> Tested-by: Valentin Lab <valentin.lab_bugzilla.kernel.org@kalysto.org> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
770970f0 |
|
26-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add GPE reference counting debugging messages. This patch enhances debugging with the GPE reference count messages added. This kind of log entries can be used by the platform validators to validate if there is an EC transaction broken because of firmware/driver bugs. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3535a3c1 |
|
26-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup logging/debugging splitter support. This patch refines logging/debugging splitter support so that when DEBUG is disabled, splitters won't be visible in the kernel logs while they are still available for developers when DEBUG is enabled. This patch also refines the splitters to mark the following handling process boundaries: +++++: boundary of driver starting/stopping boundary of IRQ storming =====: boundary of transaction advancement *****: boundary of EC command boundary of EC query #####: boundary of EC _Qxx evaluation The following 2 log entries are originally logged using pr_info() in order to be used as the boot/suspend/resume log entries for the EC device, this patch also restores them to pr_info() logging level: ACPI : EC: EC started ACPI : EC: EC stopped In this patch, one log entry around "Polling quirk" is converted into ec_dbg_raw() which doesn't contain the boundary marker. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
92e4b1bc |
|
15-Feb-2015 |
Scot Doyle <lkml14@scotdoyle.com> |
ACPI / EC: Remove non-standard log emphasis Remove unusual pr_info() visual emphasis introduced in ad479e7f47ca "ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag". Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> [ rjw: Change pr_info() to pr_debug() too in those places. ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
37d11391 |
|
11-Feb-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI / EC: Add query flushing support" Revert commit f252cb09e1cb (ACPI / EC: Add query flushing support), because it breaks system suspend on Acer Aspire S5. The machine just hangs solid at the last stage of suspend (after taking non-boot CPUs offline). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e06bf91b |
|
11-Feb-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI / EC: Add GPE reference counting debugging messages" Revert commit b5bca896ef3c (ACPI / EC: Add GPE reference counting debugging messages), because it depends on commit f252cb09e1cb (ACPI / EC: Add query flushing support) which breaks system suspend on Acer Aspire S5 and needs to be reverted. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b5bca896 |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add GPE reference counting debugging messages This patch enhances debugging with the GPE reference count messages added. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f252cb09 |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add query flushing support This patch implementes the QR_EC flushing support. Grace periods are implemented from the detection of an SCI_EVT to the submission/completion of the QR_EC transaction. During this period, all EC command transactions are allowed to be submitted. Note that query periods and event periods are intentionally distiguished to allow further improvements. 1. Query period: from the detection of an SCI_EVT to the sumission of the QR_EC command. This period is used for storming prevention, as currently QR_EC is deferred to a work queue rather than directly issued from the IRQ context even there is no other transactions pending, so malicous SCI_EVT GPE can act like "level triggered" to trigger a GPE storm. We need to be prepared for this. And in the future, we may change it to be a part of the advance_transaction() where we will try QR_EC submission in appropriate positions to avoid such GPE storming. 2. Event period: from the detection of an SCI_EVT to the completion of the QR_EC command. We may extend it to the completion of _Qxx evaluation. This is actually a grace period for event flushing, but we only flush queries due to the reason stated in known issue 1. That's also why we use EC_FLAGS_EVENT_xxx. During this period, QR_EC transactions need to pass the flushable submission check. In this patch, the following flags are implemented: 1. EC_FLAGS_EVENT_ENABLED: this is derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT handlings. With this flag, the logics implemented by the original flag are extended: 1. Old logic: unless both of the flags are set, the event poller will not be scheduled, and 2. New logic: as soon as both of the flags are set, the evet poller will be scheduled. 2. EC_FLAGS_EVENT_DETECTED: this is also derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT detection. It thus can be used to indicate the storming prevention period for query submission. acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that acpi_set_gpe() can be invoked under the "reference count > 0" condition. 3. EC_FLAGS_EVENT_PENDING: this is newly added to indicate the grace period for event flushing (query flushing for now). acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that the flushing process can wait until the event handling (query transaction for now) to be completed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e1d4d90f |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Refine command storm prevention support This patch refines EC command storm prevention support. Current command storming code is wrong, when the storming condition is detected, it only flags the condition without doing anything for the current command but performing storming prevention for the follow-up commands. So: 1. The first command which suffers from the storming still suffers from storming. 2. The follow-up commands which may not suffer from the storming are unconditionally forced into the storming prevention mode. Ideally, we should only enable storm prevention immediately after detection for the current command so that the next command can try the power/performance efficient interrupt mode again. This patch improves the command storm prevention by disabling GPE right after the detection and re-enabling it right before completing the command transaction using the GPE storming prevention APIs. This thus deploys the following GPE handling model: 1. acpi_enable_gpe()/acpi_disable_gpe() for reference count changes: This set of APIs are used for EC usage reference counting. 2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE): This set of APIs are used for preventing GPE storm. They must be invoked when the reference count > 0. Note that as the storming prevention should always happen when there is an outstanding request, or GPE enabling value will be messed up by the races. This patch also adds BUG_ON() to enforces this rule to prevent future bugs. The msleep(1) used after completing a transaction is useless now as this sounds like a guard time only useful for platforms that need the EC_FLAGS_MSI quirks while we have fixed GPE race issues using the previous raw handler mode enabling. It is kept to avoid regressions. A seperate patch which deletes EC_FLAGS_MSI quirks should take care of deleting it. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9887d22a |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add command flushing support. This patch implements the EC command flushing support. During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED, all submitted EC command transactions can be completed and new submissions are prevented before suspending so that the EC hardware can be ensured to be in the idle state when the system is resumed. There is a good indicator for flush support: All acpi_ec_submit_request() is invoked after checking driver state with acpi_ec_started() except the first one. This means all code paths can be flushed as fast as possible by discarding the requests occurred after the flush operation. The reference increased for such kind of code path is wrapped by acpi_ec_submit_flushable_request(). Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ad479e7f |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag By using the 2 flags, we can indicate an inter-mediate state where the current transactions should be completed while the new transactions should be dropped. The comparison of the old flag and the new flags: Old New about to set BLOCKED STOPPED set / STARTED set BLOCKED set STOPPED clear / STARTED clear BLOCKED clear STOPPED clear / STARTED set A new period can be indicated by the 2 flags. The new period is between the point where we are about to set BLOCKED and the point when the BLOCKED is set. The new flags facilitate us with acpi_ec_started() check to allow the EC transaction to be submitted during the new period. This period thus can be used as a grace period for the EC transaction flushing. The only functional change after applying this patch is: 1. The GPE enabling/disabling is protected by the EC specific lock. We can do this because of recent ACPICA GPE API enhancement. This is reasonable as the GPE disabling/enabling state should only be determined by the EC driver's state machine which is protected by the EC spinlock. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a8d4fc22 |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Update revision due to raw handler mode. The bug fixes around GPE races have been done to the EC driver by the previous commits. This patch increases the revision to 3 to indicate the behavior differences between the old and the new drivers. The copyright/authorship notices are also updated. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9e295ac1 |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp. Timeout in the ec_poll() doesn't refer to the last register access time. It thus can win the competition against the acpi_ec_gpe_handler() if a transaction takes longer than 1ms but individual register accesses are less than 1ms. In some cases, it can make the following silicon bug easier to be triggered: GPE EN is not wired to the GPE trigger line, so when GPE STS is already set when 1 is written to GPE EN, no GPE can be triggered. This patch adds register access timestamp reference support for ec_poll() to reduce the number of ec_poll() invocations. Reported-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ca37bfdf |
|
05-Feb-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode. This patch switches EC driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode where the GPE lock is not held for acpi_ec_gpe_handler() and the ACPICA internal GPE enabling/disabling/clearing operations are bypassed so that further improvements are possible with the GPE APIs. There are 2 strong reasons for deploying raw GPE handler mode in the EC driver: 1. Some hardware logics can control their interrupts via their own registers, so their interrupts can be disabled/enabled/acknowledged without using the super IRQ controller provided functions. While there is no mean (EC commands) for the EC driver to achieve this. 2. During suspending, the EC driver is still working for a while to complete the platform firmware provided functionailities using ec_poll() after all GPEs are disabled (see acpi_ec_block_transactions()), which means the EC driver will drive the EC GPE out of the GPE core's control. Without deploying the raw GPE handler mode, we can see many races between the EC driver and the GPE core due to the above restrictions: 1. There is a race condition due to ACPICA internal GPE disabling/clearing/enabling logics in acpi_ev_gpe_dispatch(): Orignally EC GPE is disabled (EN=0), cleared (STS=0) before invoking a GPE handler and re-enabled (EN=1) after invoking a GPE handler in acpi_ev_gpe_dispatch(). When re-enabling appears, GPE may be flagged (STS=1). ================================================================= (event pending A) ================================================================= acpi_ev_gpe_dispatch() ec_poll() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) advance_transaction() EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** EN=1 This race condition is the root cause of different issues on different silicon variations. A. Silicon variation A: On some platforms, GPE will be triggered due to "writing 1 to EN when STS=1". This is because both EN and STS lines are wired to the GPE trigger line. 1. Issue 1: We can see no-op acpi_ec_gpe_handler() invoked on such platforms. This is because: a. event pending B: An event can arrive after ACPICA's GPE clearing performed in acpi_ev_gpe_dispatch(), this event may fail to be detected by EC_SC read that is performed before its arrival; b. event handling B: The event can be handled in ec_poll() because EC lock is released after acpi_ec_gpe_handler() invocation; c. There is no code in ec_poll() to clear STS but the GPE can still be triggered by the EN=1 write performed in acpi_ev_finish_gpe(), this leads to a no-op EC GPE handler invocation; d. As no-op GPE handler invocations are counted by the EC driver to trigger the command storming conditions, the wrong no-op GPE handler invocations thus can easily trigger wrong command storming conditions. Note 1: If we removed GPE disabling/enabling code from acpi_ev_gpe_dispatch(), we could still see no-op GPE handlers triggered by the event arriving after the GPE clearing and before the GPE handling on both silicon variation A and B. This can only occur if the CPU is very slow (timing slice between STS=0 write and EC_SC read should be short enough before hardware sets another GPE indication). Thus this is very rare and is not what we need to fix. B. Silicon variation B: On other platforms, GPE may not be triggered due to "writing 1 to EN when STS=1". This is because only STS line is wired to the GPE trigger line. 2. Issue 2: We can see GPE loss on such platforms. This is because: a. event pending B vs. event handling A: An event can arrive after ACPICA's GPE handling performed in acpi_ev_gpe_dispatch(), or event pending C vs. event handling B: An event can arrive after Linux's GPE handling performed in ec_poll(), these events may fail to be detected by EC_SC read that is performed before their arrival; b. The GPE cannot be triggered by EN=1 write performed in acpi_ev_finish_gpe(); c. If no polling mechanism is implemented in the driver for the pending event (for example, SCI_EVT), this event is lost due to no GPE being triggered. Note 2: On most platforms, there might be another rule that GPE may not be triggered due to "writing 1 to STS when STS=1 and EN=1". Then on silicon variation B, an even worse case is if the issue 2 event loss happens, further events may never trigger GPE again on such platforms due to being blocked by the current STS=1. Unless someone clears STS, all events have to be polled. 2. There is a race condition due to lacking in GPE status checking in EC driver: Originally, GPE status is checked in ACPICA core but not checked in the GPE handler. Thus since the status checking and handling is not locked, it can be interrupted by another handling path. ================================================================= (event pending A) ================================================================= acpi_ev_gpe_detect() ec_poll() if (EN==1 && STS==1) ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read EC_SC handled Unlock(EC) ***************************************************************** acpi_ev_gpe_dispatch() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling B) Lock(EC) advance_transaction() EC_SC read Unlock(EC) ***************************************************************** 3. Issue 3: We can see no-op acpi_ec_gpe_handler() invoked on both silicon variation A and B. This is because: a. event pending A: An event can arrive to trigger an EC GPE and ACPICA checks it and is about to invoke the EC GPE handler; b. event handling A: The event can be handled in ec_poll() because EC lock is not held after the GPE status checking; c. event handling B: Then when the EC GPE handler is invoked, it becomes a no-op GPE handler invocation. d. As no-op GPE handler invocations are counted by the EC driver to trigger the command storming conditions, the wrong no-op GPE handler invocations thus can easily trigger wrong command storming conditions. Note 3: This no-op GPE handler invocation is rare because the time between the IRQ arrival and the acpi_ec_gpe_handler() invocation is less than the timeout value waited in ec_poll(). So most of the no-op GPE handler invocations are caused by the reason described in issue 1. 3. There is a race condition due to ACPICA internal GPE clearing logic in acpi_enable_gpe(): During runtime, acpi_enable_gpe() can be invoked by the EC storming prevention code. When it is invoked, GPE may be flagged (STS=1). ================================================================= (event pending A) ================================================================= acpi_ev_gpe_dispatch() acpi_ec_transaction() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read EC_SC handled Unlock(EC) ***************************************************************** EN=1 ? Lock(EC) Unlock(EC) ================================================================= (event pending B) ================================================================= acpi_enable_gpe() STS=0 EN=1 4. Issue 4: We can see GPE loss on both silicon variation A and B platforms. This is because: a. event pending B: An event can arrive right before ACPICA's GPE clearing performed in acpi_enable_gpe(); b. If the GPE is cleared when GPE is disabled, then EN=1 write in acpi_enable_gpe() cannot trigger this GPE; c. If no polling mechanism is implemented in the driver for this event (for example, SCI_EVT), this event is lost due to no GPE being triggered. Note 4: Currently we don't have this issue, but after we switch the EC driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode, we need to take care of handling this because the EN=1 write in acpi_ev_gpe_dispatch() will be abandoned. There might be more race issues for the current GPE handler usages. This is because the EC IRQ's enabling/disabling/checking/clearing/handling operations should be locked by a single lock that is under the EC driver's control to achieve the serialization. Which means we need to invoke GPE APIs with EC driver's lock held and all ACPICA internal GPE operations related to the GPE handler should be abandoned. Invoking GPE APIs inside of the EC driver lock and bypassing ACPICA internal GPE operations requires the ACPI_GPE_DISPATCH_RAW_HANDLER mode where the same lock used by the APIs are released prior than invoking the handlers. Otherwise, we can see dead locks due to circular locking dependencies (see Reference below). This patch then switches the EC driver into the ACPI_GPE_DISPATCH_RAW_HANDLER mode so that it can perform correct GPE operations using the GPE APIs: 1. Bypasses EN modifications performed in acpi_ev_gpe_dispatch() by using acpi_install_gpe_raw_handler() and invoking all GPE APIs with EC spin lock held. This can fix issue 1 as it makes a non frequent GPE enabling/disabling environment. 2. Bypasses STS clearing performed in acpi_enable_gpe() by replacing acpi_enable_gpe()/acpi_disable_gpe() with acpi_set_gpe(). This can fix issue 4. And this can also help to fix issue 1 as it makes a no sudden GPE clearing environment when GPE is frequently enabled/disabled. 3. Ensures STS acknowledged before handling by invoking acpi_clear_gpe() in advance_transaction(). This can finally fix issue 1 even in a frequent GPE enabling/disabling environment. And this can also finally fix issue 3 when issue 2 is fixed. Note 3: GPE clearing is edge triggered W1C, which means we can clear it right before handling it. Since all EC GPE indications are handled in advance_transaction() by previous commits, we can now move GPE clearing into it to implement the correct GPE clearing. Note 4: We can use acpi_set_gpe() which is not shared GPE safer instead of acpi_enable_gpe()/acpi_disable_gpe() because EC GPE is not shared by other hardware, which is mentioned in the ACPI specification 5.0, 12.6 Interrupt Model: "OSPM driver treats this as an edge event (the EC SCI cannot be shared)". So we can stop using shared GPE safer APIs acpi_enable_gpe()/acpi_disable_gpe() in the EC driver. Otherwise cleanups need to be made in acpi_ev_enable_gpe() to bypass the GPE clearing logic before keeping acpi_enable_gpe(). This patch also invokes advance_transaction() when GPE is re-enabled in the task context which: 1. Ensures EN=1 can trigger GPE by checking and handling EC status register right after EN=1 writes. This can fix issue 2. After applying this patch, without frequent GPE enablings considered: ================================================================= (event pending A) ================================================================= acpi_ec_gpe_handler() ec_poll() ***************************************************************** (event handling A) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** The event pending for issue 1 (event pending B) can arrive as a next GPE due to the previous IRQ context STS=0 write. And if it is handled by ec_poll() (event handling B), as it is also acknowledged by ec_poll(), the event pending for issue 2 (event pending C) can properly arrive as a next GPE after the task context STS=0 write. So no GPE will be lost and never triggered due to GPE clearing performed in the wrong position. And since all GPE handling is performed after a locked GPE status checking, we can hardly see no-op GPE handler invocations due to issue 1 and 3. We may still see no-op GPE handler invocations due to "Note 1", but as it is inevitable, it needn't be fixed. After applying this patch, with frequent GPE enablings considered: ================================================================= (event pending A) ================================================================= acpi_ec_gpe_handler() acpi_ec_transaction() ***************************************************************** (event handling A) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) EN=1 if STS==1 advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** The event pending for issue 2 can be manually handled by advance_transaction(). And after the STS=0 write performed in the manual triggered advance_transaction(), GPE can always arrive. So no GPE will be lost due to frequent GPE disabling/enabling performed in the driver like issue 4. Note 5: It's ideally when EN=1 write occurred, an IRQ thread should be woken up to handle the GPE when the GPE was raised. But this requires the IRQ thread to contain the poller code for all EC GPE indications, while currently some of the indications are handled in the user tasks. It then is very hard for the code to determine whether a user task should be invoked or the poller work item should be scheduled. So we have to invoke advance_transaction() directly now and it leaves us such a restriction for the GPE re-enabling: it must be performed in the task context to avoid starving the GPEs. As a conclusion: we can see the EC GPE is always handled in serial after deploying the raw GPE handler mode: Lock(EC) if (STS==1) STS=0 EC_SC read EC_SC handled Unlock(EC) The EC driver specific lock is responsible to make the EC GPE handling processes serialized so that EC can handle its GPE from both IRQ and task contexts and the next IRQ can be ensured to arrive after this process. Note 6: We have many EC_FLAGS_MSI qurik users in the current driver. They all seem to be suffering from unexpected GPE triggering source lost. And they are false root caused to a timing issue. Since EC communication protocol has already flow control defined, timing shouldn't be the root cause, while this fix might be fixing the root cause of the old bugs. Link: https://lkml.org/lkml/2014/11/4/974 Link: https://lkml.org/lkml/2014/11/18/316 Link: https://www.spinics.net/lists/linux-acpi/msg54340.html Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
550b3aac |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup QR_EC related code The QR_EC related code pieces have redundants, this patch merges them into acpi_ec_query() which invokes acpi_ec_transaction() where EC mutex and the global lock are already held. After doing so, query handler traversal still need to be locked by EC mutex after invoking acpi_ec_transaction(). Note that EC event handling is sequential. We fetch one event from firmware event queue and process it until 0x00 or error returned. So we don't need to hold mutex for whole acpi_ec_clear() process to determine whether we should continue to drain. And for the same reason, we don't need to hold mutex for the whole procedure from the QR_EC transaction to the query handler traversal. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
74443bbe |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix issues related to the SCI_EVT handling This patch fixes 2 issues related to the draining behavior. But it doesn't implement the draining support, it only cleans up code so that further draining support is possible. The draining behavior is expected by some platforms (for example, Samsung) where SCI_EVT is set only once for a set of events and might be cleared for the very first QR_EC command issued after SCI_EVT is set. EC firmware on such platforms will return 0x00 to indicate "no outstanding event". Thus after seeing an SCI_EVT indication, EC driver need to fetch events until 0x00 returned (see acpi_ec_clear()). Issue 1 - acpi_ec_submit_query(): It's reported on Samsung laptops that SCI_EVT isn't checked when the transactions are advanced in ec_poll(), which leads to SCI_EVT triggering source lost: If no EC GPE IRQs are arrived after that, EC driver cannot detect this event and handle it. See comment 244/247 for kernel bugzilla 44161. This patch fixes this issue by moving SCI_EVT checks into advance_transaction(). So that SCI_EVT is checked each time we are going to handle the EC firmware indications. And this check will happen for both IRQ context and task context. Since after doing that, SCI_EVT is also checked after completing a transaction, ec_check_sci() and ec_check_sci_sync() can be removed. Issue 2 - acpi_ec_complete_query(): We expect to clear EC_FLAGS_QUERY_PENDING to allow queuing another draining QR_EC after writing a QR_EC command and before reading the event. After reading the event, SCI_EVT might be cleared by the firmware, thus it may not be possible to queue such a draining QR_EC at that time. But putting the EC_FLAGS_QUERY_PENDING clearing code after start_transaction() is wrong as there are chances that after start_transaction(), QR_EC can fail to be sent. If this happens, EC_FLAG_QUERY_PENDING will be cleared earlier. As a consequence, the draining QR_EC will also be queued earlier than expected. This patch also moves this code into advance_transaction() where QR_EC is just sent (ACPI_EC_COMMAND_POLL flagged) to fix this issue. Notes: 1. After introducing the 2 SCI_EVT related handlings into advance_transaction(), a next QR_EC can be queued right after writing the current QR_EC command and before reading the event. But this still hasn't implemented the draining behavior as the draining support requires: If a previous returned event value isn't 0x00, a draining QR_EC need to be issued even when SCI_EVT isn't set. 2. In this patch, acpi_os_execute() is also converted into a seperate work item to avoid invoking kmalloc() in the atomic context. We can do this because of the previous global lock fix. 3. Originally, EC_FLAGS_EVENT_PENDING is also used to avoid queuing up multiple work items (created by acpi_os_execute()), this can be covered by only using a single work item. But this patch still keeps this flag as there are different usages in the driver initialization steps relying on this flag. Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-by: Kieran Clancy <clancy.kieran@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f3e14329 |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix a code path that global lock is not held Currently QR_EC is queued up on CPU 0 to be safe with SMM because there is no global lock held for acpi_ec_gpe_query(). As we are about to move QR_EC to a non CPU 0 bound work queue to avoid invoking kmalloc() in advance_transaction(), we have to acquire global lock for the new QR_EC work item to avoid regressions. Known issue: 1. Global lock for acpi_ec_clear(). This is an existing issue that acpi_ec_clear() which invokes acpi_ec_sync_query() also suffers from the same issue. But this patch's target is only the code to invoke acpi_ec_sync_query() in a CPU 0 bound work queue item, and the acpi_ec_clear() can be automatically fixed by further patch that merges the redundant code, so it is left unchanged. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c2cf5769 |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix returning values in acpi_ec_sync_query() The returning value of acpi_os_execute() is erroneously handled as errno. This patch corrects it by returning EBUSY to indicate the work queue item creation failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
01305d41 |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add reference counting for query handlers This patch adds reference counting for query handlers in order to eliminate kmalloc()/kfree() usage. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0c78808f |
|
14-Jan-2015 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup transaction wakeup code This patch moves transaction wakeup code into advance_transaction(). No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1741acea |
|
14-Dec-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix unexpected ec_remove_handlers() invocations The ec_remove_handlers() is invoked without checking EC_FLAGS_HANDLERS_INSTALLED, this patch enhances this check to avoid issues that acpi_disable_gpe() is invoked unexpectedly to reduce the GPE runtime count. This may happen when the EC handler installation failed on some platforms. Reported-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
79149001 |
|
28-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer. It is reported that Samsung laptops that need to poll events are broken by the following commit: Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set The behaviors of the 2 vendor firmwares are conflict: 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware automatically sets SCI_EVT as long as there is event queued up. 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware returns 0 when there is no event queued up. This patch is a quick fix to distinguish the behaviors to make Acer behavior only effective for Acer EC firmware so that the breakages on Samsung EC firmware can be avoided. Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ [ rjw : Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
df9ff918 |
|
28-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC" It is reported that the following commit breaks Samsung hardware: Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4. Subject: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC Which means the Samsung behavior conflicts with the Acer behavior. 1. Samsung may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear Without the above commit, Samsung can work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC CAN prepare next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear write QR_EC read event [ -event 2 ] SCI_EVT clear With the above commit, Samsung cannot work: [ +event 1 ] SCI_EVT set [ +event 2 ] SCI_EVT set write QR_EC read event [ -event 1 ] SCI_EVT clear CANNOT prepare next QR_EC as SCI_EVT=0 2. Acer may behave like: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT clear [ +event 2 ] SCI_EVT set Without the above commit, Acer cannot work when there is only 1 event: [ +event 1 ] SCI_EVT set write QR_EC can prepared next QR_EC as SCI_EVT=1 read event [ -event 1 ] SCI_EVT clear CANNOT write QR_EC as SCI_EVT=0 With the above commit, Acer can work: [ +event 1 ] SCI_EVT set [ +event 2 ] write QR_EC read event [ -event 1 ] SCI_EVT set can prepare next QR_EC because SCI_EVT=0 CAN write QR_EC as SCI_EVT=1 Since Acer can also work with only the following commit applied: Commit: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 can be reverted. Fixes: 558e4736f2e1 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7a73e60e |
|
14-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Cleanup coding style. This patch cleans up the following coding style issues that are detected by scripts/checkpatch.pl: ERROR: code indent should use tabs where possible ERROR: "foo * bar" should be "foo *bar" WARNING: Missing a blank line after declarations WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable WARNING: void function return statements are not generally useful WARNING: else is not generally useful after a break or return WARNING: break is not useful after a goto or return WARNING: braces {} are not necessary for single statement blocks WARNING: line over 80 characters WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d3090b6a |
|
14-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Refine event/query debugging messages. This patch refines event/query debugging messages to use a unified format as commands. Developers can clearly find different processes by checking different log seperators. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e34c0e2b |
|
14-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add detailed command/query debugging information. Developers really don't need to translate EC commands in mind. This patch adds detailed debugging information for the EC commands. The address can be found in the follow-up sequential EC_DATA(W) accesses, thus this patch also removes some of the redundant address information. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
459572a7 |
|
14-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Enhance the logs to apply to QR_EC transactions. Currently some logs are applied to new transactions, but QR_EC transactions are not included. This patch merges the code path to make the logs also applying to the QR_EC transactions. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c95f25b0 |
|
14-Oct-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add CPU ID to debugging messages. This patch adds CPU ID to the context entries' debugging output. no functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
777cb382 |
|
28-Aug-2014 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Add msi quirk for Clevo W350etq Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: qbanin@gmail.com Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
558e4736 |
|
21-Aug-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3afcf2ec |
|
21-Aug-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set There is a platform refusing to respond QR_EC when SCI_EVT isn't set (Acer Aspire V5-573G). Currently, we rely on the behaviour that the EC firmware can respond something (for example, 0x00 to indicate "no outstanding events") to QR_EC even when SCI_EVT is not set, but the reporter has complained about AC/battery pluging/unpluging and video brightness change delay on that platform. This is because the work item that has issued QR_EC has to wait until timeout in this case, and the _Qxx method evaluation work item queued after QR_EC one is delayed. It sounds reasonable to fix this issue by: 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC driver's main state machine. 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation to a seperate IRQ handling thread. This patch fixes this issue using solution 1. By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to handle such platform in the EC driver's main state machine. This patch enhances the state machine in this way to survive with such malfunctioning EC firmware. Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ed4b197d |
|
02-Jul-2014 |
Colin Ian King <colin.king@canonical.com> |
ACPI / EC: Free saved_ec on error exit path Smatch detected two memory leaks on saved_ec: drivers/acpi/ec.c:1070 acpi_ec_ecdt_probe() warn: possible memory leak of 'saved_ec' drivers/acpi/ec.c:1109 acpi_ec_ecdt_probe() warn: possible memory leak of 'saved_ec' Free saved_ec on these two error exit paths to stop the memory leak. Note that saved_ec maybe null, but kfree on null is allowed. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
dd43de20 |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add detailed fields debugging support of EC_SC(R). Developers really don't need to translate EC_SC(R) in mind as long as the field details are decoded in the debugging message. Tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4a3f6b5b |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Update revision due to recent changes The bug fixes and asynchronous improvements have been done to the EC driver by the previous commits. This patch increases the revision to 2.2 to indicate the behavior differences between the old and the new drivers. The copyright/authorship notices are also updated. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c0d65341 |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Fix race condition in ec_transaction_completed() There is a race condition in ec_transaction_completed(). When ec_transaction_completed() is called in the GPE handler, it could return true because of (ec->curr == NULL). Then the wake_up() invocation could complete the next command unexpectedly since there is no lock between the 2 invocations. With the previous cleanup, the IBF=0 waiter race need not be handled any more. It's now safe to return a flag from advance_condition() to indicate the requirement of wakeup, the flag is returned from a locked context. The ec_transaction_completed() is now only invoked by the ec_poll() where the ec->curr is ensured to be different from NULL. After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a QR_SC command. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9b80f0f7 |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter After we've added the first command byte write into advance_transaction(), the IBF=0 waiter is duplicated with the command completion waiter implemented in the ec_poll() because: If IBF=1 blocked the first command byte write invoked in the task context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed out and retried again in the task context. Remove this seperate and duplicate IBF=0 waiter. By doing so we can reduce the overall number of times to access the EC_SC(R) status register. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f92fca00 |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Add asynchronous command byte write support Move the first command byte write into advance_transaction() so that all EC register accesses that can affect the command processing state machine can happen in this asynchronous state machine advancement function. The advance_transaction() function then can be a complete implementation of an asyncrhonous transaction for a single command so that: 1. The first command byte can be written in the interrupt context; 2. The command completion waiter can also be used to wait the first command byte's timeout; 3. In BURST mode, the follow-up command bytes can be written in the interrupt context directly, so that it doesn't need to return to the task context. Returning to the task context reduces the throughput of the BURST mode and in the worst cases where the system workload is very high, this leads to the hardware driven automatic BURST mode exit. In order not to increase memory consumption, convert 'done' into 'flags' to contain multiple indications: 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition, indicating the completion of the command transaction. 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first command byte. A new command can utilize this flag to compete for the right of accessing the underlying hardware. There is a follow-up bug fix that has utilized this new flag. The 2 flags are important because it also reflects a key concept of IO programs' design used in the system softwares. Normally an IO program running in the kernel should first be implemented in the asynchronous way. And the 2 flags are the most common way to implement its synchronous operations on top of the asynchronous operations: 1. POLL: This flag can be used to block until the asynchronous operations can happen. 2. COMPLETE: This flag can be used to block until the asynchronous operations have completed. By constructing code cleanly in this way, many difficult problems can be solved smoothly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
66b42b78 |
|
14-Jun-2014 |
Lv Zheng <lv.zheng@intel.com> |
ACPI / EC: Avoid race condition related to advance_transaction() The advance_transaction() will be invoked from the IRQ context GPE handler and the task context ec_poll(). The handling of this function is locked so that the EC state machine are ensured to be advanced sequentially. But there is a problem. Before invoking advance_transaction(), EC_SC(R) is read. Then for advance_transaction(), there could be race condition around the lock from both contexts. The first one reading the register could fail this race and when it passes the stale register value to the state machine advancement code, the hardware condition is totally different from when the register is read. And the hardware accesses determined from the wrong hardware status can break the EC state machine. And there could be cases that the functionalities of the platform firmware are seriously affected. For example: 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the hardware will either refuse to respond a next EC_SC(W) write of the next command or discard the current WR_EC command when it receives a EC_SC(W) write of the next command. 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write. The next EC_DATA(R) could never be responded by the hardware. This is the root cause of the reported issue. Fix this issue by moving the EC_SC(R) access into the lock so that we can ensure that the state machine is advanced consistently. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911 Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by: Barton Xu <tank.xuhan@gmail.com> Tested-by: Steffen Weber <steffen.weber@gmail.com> Tested-by: Arthur Chen <axchen@nvidia.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3eba563e |
|
29-Apr-2014 |
Kieran Clancy <clancy.kieran@gmail.com> |
ACPI / EC: Process rather than discard events in acpi_ec_clear Address a regression caused by commit ad332c8a4533: (ACPI / EC: Clear stale EC events on Samsung systems) After the earlier patch, there was found to be a race condition on some earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was sometimes discarding a new EC event before its GPE was triggered by the system. In the case of these systems, this meant that the "lid open" event was not registered on resume if that was the cause of the wake, leading to problems when attempting to close the lid to suspend again. After testing on a number of Samsung systems, both those affected by the previous EC bug and those affected by the race condition, it seemed that the best course of action was to process rather than discard the events. On Samsung systems which accumulate stale EC events, there does not seem to be any adverse side-effects of running the associated _Q methods. This patch adds an argument to the static function acpi_ec_sync_query so that it may be used within the acpi_ec_clear loop in place of acpi_ec_query_unlocked which was used previously. With thanks to Stefan Biereigel for reporting the issue, and for all the people who helped test the new patch on affected systems. Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems) References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173 Reported-by: Stefan Biereigel <stefan@biereigel.de> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Stefan Biereigel <stefan@biereigel.de> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ad332c8a |
|
28-Feb-2014 |
Kieran Clancy <clancy.kieran@gmail.com> |
ACPI / EC: Clear stale EC events on Samsung systems A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: San Zamoyski <san@plusnet.pl> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b8a0b0d1 |
|
17-Dec-2013 |
Rashika <rashika.kheria@gmail.com> |
ACPI / EC: Remove unused functions and add prototype declaration in internal.h Adds the prototype declarations of functions acpi_ec_add_query_handler() and acpi_ec_remove_query_handler() in header file internal.h and removes unused functions ec_burst_enable() and ec_burst_disable() in ec.c. This eliminates the following warnings in ec.c: drivers/acpi/ec.c:393:5: warning: no previous prototype for ‘ec_burst_enable’ [-Wmissing-prototypes] drivers/acpi/ec.c:402:5: warning: no previous prototype for ‘ec_burst_disable’ [-Wmissing-prototypes] drivers/acpi/ec.c:531:5: warning: no previous prototype for ‘acpi_ec_add_query_handler’ [-Wmissing-prototypes] drivers/acpi/ec.c:552:6: warning: no previous prototype for ‘acpi_ec_remove_query_handler’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
42b946bb |
|
12-Dec-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: disable GPE before removing GPE handler Adjust the order of disabling the EC GPE and removing its handler to avoid unhandled events. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8b48463f |
|
02-Dec-2013 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
36b15875 |
|
15-Nov-2013 |
Puneet Kumar <puneetster@chromium.org> |
ACPI / EC: Ensure lock is acquired before accessing ec struct members A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') that erroneously caused the struct member to be accessed before acquiring the required lock. This change fixes it by ensuring the lock acquisition is done first. Found by Aaron Durbin <adurbin@chromium.org> Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019 Signed-off-by: Puneet Kumar <puneetster@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> [olof: Commit message reworded a bit] Signed-off-by: Olof Johansson <olof@lixom.net> Cc: 3.8+ <stable@vger.kernel.org> # 3.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
16a26e85 |
|
12-Sep-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Convert all printk() calls to dynamic debug function This patch is to convert all printks in the ec driver to pr_debug/info/err and define pr_fmt macro to replace PREFIX. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
524f42fa |
|
25-Aug-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT The ECDT of ASUSTEK L4R doesn't provide correct command and data I/O ports. The DSDT provides the correct information instead. For this reason, add this machine to quirk list for ECDT validation and use the EC information from the DSDT. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=60765 Reported-and-tested-by: Daniele Esposti <expo@expobrain.net> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6cef7497 |
|
07-Aug-2013 |
Sachin Kamat <sachin.kamat@linaro.org> |
ACPI / EC: Fix incorrect placement of __initdata __initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
952c63e9 |
|
28-Jun-2013 |
Jiang Liu <jiang.liu@huawei.com> |
ACPI: introduce helper function acpi_has_method() Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eff9a4b6 |
|
04-Jun-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's _REG method will access that region. To allow the CMOS RTC region handler to be installed before the EC _REG method is first invoked, add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
28fe5c82 |
|
05-May-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
ACPI / EC: Restart transaction even when the IBF flag set The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
51fac838 |
|
23-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Remove useless type argument of driver .remove() operation The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
|
#
a3cd8d27 |
|
22-Oct-2012 |
Feng Tang <feng.tang@intel.com> |
ACPI / EC: Don't count a SCI interrupt as a false one Currently when advance_transaction() is called in EC interrupt handler, if there is nothing driver can do with the interrupt, it will be taken as a false one. But this is not always true, as there may be a SCI EC interrupt fired during normal read/write operation, which should not be counted as a false one. This patch fixes the problem. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b76b51ba |
|
22-Oct-2012 |
Feng Tang <feng.tang@intel.com> |
ACPI / EC: Add more debug info and trivial code cleanup Add more debug info for EC transaction debugging, like the interrupt status register value, the detail info of a EC transaction. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f351d027 |
|
22-Oct-2012 |
Feng Tang <feng.tang@intel.com> |
ACPI / EC: Cleanup the member name for spinlock/mutex in struct Current member names for mutex/spinlock are a little confusing. Change the { struct mutex lock; spinlock_t curr_lock; } to { struct mutex mutex; spinlock_t lock; } So that the code is cleaner and easier to read. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
67bfa9b6 |
|
28-Sep-2012 |
Feng Tang <feng.tang@intel.com> |
ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop By enlarging the GPE storm threshold back to 20, that laptop's EC works fine with interrupt mode instead of polling mode. https://bugzilla.kernel.org/show_bug.cgi?id=45151 Reported-and-Tested-by: Francesco <trentini@dei.unipd.it> Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> cc: stable@vger.kernel.org
|
#
a520d52e |
|
28-Sep-2012 |
Feng Tang <feng.tang@intel.com> |
ACPI: EC: Make the GPE storm threshold a module parameter The Linux EC driver includes a mechanism to detect GPE storms, and switch from interrupt-mode to polling mode. However, polling mode sometimes doesn't work, so the workaround is problematic. Also, different systems seem to need the threshold for detecting the GPE storm at different levels. ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm threshold" to fix kernel bug 11892 by forcing the laptop in that bug to work in polling mode. However in bug 45151, it works fine in interrupt mode if we lift the threshold back to 20. This patch makes the threshold a module parameter so that user has a flexible option to debug/workaround this issue. The default is unchanged. This is also a preparation patch to fix specific systems: https://bugzilla.kernel.org/show_bug.cgi?id=45151 Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> cc: stable@vger.kernel.org
|
#
d6795fe3 |
|
06-Feb-2012 |
Andi Kleen <andi@firstfloor.org> |
ACPI: ec: Do request_region outside WARN() WARN() is not supposed to have side effects, so move the request_regions outside. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3e2abc5a |
|
18-Jan-2012 |
Seth Forshee <seth.forshee@canonical.com> |
ACPI: EC: Add ec_get_handle() toshiba_acpi needs to execute an AML method within the EC namespace to make hotkeys work on some platforms. Provide an interface to allow it to easily get a handle to the EC namespace for this purpose. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
08b53f0e |
|
26-Apr-2011 |
Zhang Rui <rui.zhang@intel.com> |
ACPI EC: remove redundant code ec->handle is set in ec_parse_device(), so don't bother to set it again. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
534bc4e3 |
|
26-Apr-2011 |
Zhang Rui <rui.zhang@intel.com> |
ACPI EC: enable MSI workaround for Quanta laptops Enable MSI workaround for Quanta laptops. https://bugzilla.kernel.org/show_bug.cgi?id=20242 Tested-by: Jan-Matthias Braun <jan_braun@gmx.net> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
af986d10 |
|
24-Apr-2011 |
Peter Collingbourne <peter@pcc.me.uk> |
ACPI: EC: add another DMI check for ASUS hardware Commit 0adf3c746a73684b3f8c2821a584e1db998f61e9 introduced a regression by making the ECDT validation test for ASUS hardware more restrictive. The previous test used the dmi_name_in_vendors function which searches a number of DMI fields, while the new test checked only the BIOS vendor, which is known to not match on an ASUS F5GL laptop which requires ECDT validation. Add a rule to ec_dmi_table based on an alternative DMI pattern for ASUS hardware as found elsewhere in the kernel. Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1cb7b1e0 |
|
31-Mar-2011 |
Thomas Renninger <trenn@suse.de> |
ACPI EC: remove dead code static void acpi_ec_gpe_query(void *ec_cxt); -> The function is right above this declaration -> not needed. poll_force is also not used, cleaned up in ec.c and its users: compal-laptop and msi-laptop. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
bba63a29 |
|
12-Dec-2010 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Implicit notify support This feature provides an automatic device notification for wake devices when a wakeup GPE occurs and there is no corresponding GPE method or handler. Rather than ignoring such a GPE, an implicit AML Notify operation is performed on the parent device object. This feature is not part of the ACPI specification and is provided for Windows compatibility only. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8b6cd8ad |
|
12-Dec-2010 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: New GPE handler callback definition The new GPE handler callback has 2 additional parameters, gpe_device and gpe_number. typedef u32 (*acpi_gpe_handler) (acpi_handle gpe_device, u32 gpe_number, void *context); Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a5dc4f89 |
|
09-Dec-2010 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add another dmi match entry for MSI hardware http://bugzilla.kernel.org/show_bug.cgi?id=15418 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7a18e96d |
|
21-Oct-2010 |
Thomas Renninger <trenn@suse.de> |
ACPI: Make Embedded Controller command timeout delay configurable Here and then there show up machines which need higher timeout values. Finding this on affected machines can be cumbersome, because ACPI_EC_DELAY is a compile option -> make it configurable via boot param. This can even be provided writable at runtime via: /sys/modules/acpi/parameters/ec_delay Known machines where this helps: Some HP machines where for whatever reasons specific EC accesses take very long at resume from S3 (in _WAK function). The AE_TIME error is passed upwards and the ACPI interpreter will not execute the rest of the _WAK function which results in not properly initialized devices/variables with different side-effects. Afaik, on some MSI machines this helped as well. If this param is needed there probably are underlying problems like: - EC firmware bug - A kernel EC driver bug - An ACPI interpreter behavior (e.g. timings when specific EC accesses happen and how) which the EC does not like - ... which should get evaluated further, but often are nasty or impossible to fix from OS side. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
de4f1046 |
|
29-Jul-2010 |
Thomas Renninger <trenn@suse.de> |
acpi ec: Fix possible double io port registration which will result in a harmless but ugly WARN message on some machines. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: mjg59@srcf.ucam.org CC: platform-driver-x86@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: astarikovskiy@suse.de CC: akpm@linux-foundation.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
b52e0421 |
|
16-Jul-2010 |
Thomas Renninger <trenn@suse.de> |
ACPI: Register EC io ports in /proc/ioports Formerly these have been exposed through /proc/.. Better register them where all IO ports should get registered and scream loud if someone else claims to use them. EC data and command port typically should show up like this then: ... 0060-0060 : keyboard 0062-0062 : EC data 0064-0064 : keyboard 0066-0066 : EC command 0070-0071 : rtc0 ... Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
1195a098 |
|
16-Jul-2010 |
Thomas Renninger <trenn@suse.de> |
ACPI: Provide /sys/kernel/debug/ec/... This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
49c6c5ff |
|
16-Jul-2010 |
Thomas Renninger <trenn@suse.de> |
ACPI: Remove /proc/acpi/embedded_controller/.. Other patches in this series add the same info to /sys/... and /proc/ioports. The info removed should never have been used in an application, eventually someone read it manually. /proc/acpi is deprecated for more than a year anyway... Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
3784730b |
|
24-Jun-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC: Do not use acpi_set_gpe The EC driver is the last user of acpi_set_gpe() and since it is guaranteed that the EC GPE will not be shared, acpi_disable_gpe() and acpi_enable_gpe() may be used for disabling the GPE temporarilty if a GPE storm is detected and re-enabling it during EC transactions. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b63559f5 |
|
24-Jun-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC: Drop suspend and resume routines The suspend and resume routines provided by the EC driver are not really necessary, because the handler of the GPE disabled by them is not going to be executed after suspend_device_irqs() and before resume_device_irqs() anyway. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a44061aa |
|
30-Jun-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPICA: Remove wakeup GPE reference counting which is not used After the previous patch that introduced acpi_gpe_wakeup() and modified the ACPI suspend and wakeup code to use it, the third argument of acpi_{enable|disable}_gpe() and the GPE wakeup reference counter are not necessary any more. Remove them and modify all of the users of acpi_{enable|disable}_gpe() accordingly. Also drop GPE type constants that aren't used any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fe955682 |
|
08-Apr-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Fix names of functions that block/unblock EC transactions The names of the functions used for blocking/unblocking EC transactions during suspend/hibernation suggest that the transactions are suspended and resumed by them, while in fact they are disabled and enabled. Rename the functions (and the flag used by them) to better reflect what they really do. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d5a64513 |
|
08-Apr-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Fix race between EC transactions and system suspend There still is a race that may result in suspending the system in the middle of an EC transaction in progress, which leads to problems (like the kernel thinking that the ACPI global lock is held during resume while in fact it's not). To remove the race condition, modify the ACPI platform suspend and hibernate callbacks so that EC transactions are blocked right after executing the _PTS global control method and are allowed to happen again right after the low-level wakeup. Introduce acpi_pm_freeze() that will disable GPEs, wait until the event queues are empty and block EC transactions. Use it wherever GPEs are disabled in preparation for switching local interrupts off. Introduce acpi_pm_thaw() that will allow EC transactions to happen again and enable runtime GPEs. Use it to balance acpi_pm_freeze() wherever necessary. In addition to that use acpi_ec_resume_transactions_early() to unblock EC transactions as early as reasonably possible during resume. Also unblock EC transactions in acpi_hibernation_finish() and in the analogous suspend routine to make sure that the EC transactions are enabled in all error paths. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=14668 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d6bd535d |
|
15-May-2010 |
Julia Lawall <julia@diku.dk> |
ACPI: EC: Use kmemdup Use kmemdup when some other buffer is immediately copied into the allocated region. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S - memcpy(to, from, size); // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
dadf28a1 |
|
17-Mar-2010 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Allow multibyte access to EC http://bugzilla.kernel.org/show_bug.cgi?id=14667 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f6bb13aa |
|
03-Mar-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI / EC / PM: Close race between EC and resume from hibernation There is a race between resume from hibernation and the EC driver that may result in restoring the hibernation image in the middle of an EC transaction in progress, which in turn may lead to unpredictable behavior of the platform. To remove that race condition, add a helpers for suspending and resuming EC transactions in a safe way to be executed by the ACPI platform hibernate pre-restore and restore cleanup callbacks. http://bugzilla.kernel.org/show_bug.cgi?id=14668 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
cbbc0de7 |
|
23-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI: Use GPE reference counting to support shared GPEs To fix a bug and address the reviewers' comments regarding the ACPI GPE refcounting patch, do the following additional changes: o Remove the second argument of acpi_ev_enable_gpe(), 'write_to_hardware', because it is not necessary any more. o Add the "bad parameter" test against 'type' in acpi_enable_gpe() and acpi_disable_gpe(). o Make acpi_enable_gpe() only check 'status' for runtime GPEs if acpi_ev_enable_gpe() was actually called. o Make acpi_disable_gpe() return 'status' returned by acpi_ev_disable_gpe() and fix a bug where ACPI_GPE_TYPE_WAKE and ACPI_GPE_TYPE_RUNTIME were exchanged by mistake. o Add comments explaining why acpi_set_gpe() is used by the ACPI EC driver. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
9630bdd9 |
|
17-Feb-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
ACPI: Use GPE reference counting to support shared GPEs ACPI GPEs may map to multiple devices. The current GPE interface only provides a mechanism for enabling and disabling GPEs, making it difficult to change the state of GPEs at runtime without extensive cooperation between devices. Add an API to allow devices to indicate whether or not they want their device's GPE to be enabled for both runtime and wakeup events. Remove the old GPE type handling entirely, which gets rid of various quirks, like the implicit disabling with GPE type setting. This requires a small amount of rework in order to ensure that non-wake GPEs are enabled by default to preserve existing behaviour. Based on patches from Matthew Garrett <mjg@redhat.com>. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
439913ff |
|
27-Jan-2010 |
Lin Ming <ming.m.lin@intel.com> |
ACPI: replace acpi_integer by u64 acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
54070101 |
|
30-Dec-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add wait for irq storm Merge of poll and irq modes accelerated EC transaction, so that keyboard starts to suffer again. Add msleep(1) into transaction path for the storm to allow keyboard controller to do its job. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14747 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f5347867 |
|
30-Dec-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: SBS: Move SBS HC callback to faster Notify queue SBS transactions should happen in Notify work queue, to not create a dead lock with GPE execution accessing SBS devices. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a62e8f19 |
|
24-Dec-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Accelerate query execution Split EC query handling into acknowledge and execution phase. This allows much smaller pending query lattency and lowers chances of EC going "wild" and losing events. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14858 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
55b313f2 |
|
22-Dec-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Fix MSI DMI detection MSI strings should be ORed, not ANDed. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14446 cc: stable@kernel.org Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2263576c |
|
12-Nov-2009 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Add post-order callback to acpi_walk_namespace The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779. Also update the external calls to acpi_walk_namespace. http://www.acpica.org/bugzilla/show_bug.cgi?id=779 Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
478fa03b |
|
02-Oct-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't parse DSDT for EC early init on Compal Compal DSDT breaks if scanned early, while we need early scan for almost all ASUS machines. Safest workaround seems to be to continue do an early scan for all machines, but this Compal model. http://bugzilla.kernel.org/show_bug.cgi?id=14086 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0adf3c74 |
|
02-Oct-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Rewrite DMI checks Use dmi_check_system() for DMI matching. Don't use string "Notebook" for matching MSI hardware. http://bugzilla.kernel.org/show_bug.cgi?id=14081 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e12ac3d0 |
|
01-Oct-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Restart command even if no interrupts from EC EC may forget a command without sending any "reset" interrupt, thus we need to lessen the requirement for transaction restart. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14247 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
eb27cae8 |
|
06-Jul-2009 |
Len Brown <len.brown@intel.com> |
ACPI: linux/acpi.h should not include linux/dmi.h users of acpi.h that need dmi.h should include it directly. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f25752e6 |
|
28-Aug-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Drop orphan comment Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6a63b06f |
|
28-Aug-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: use BURST mode only for MSI notebooks Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2a84cb98 |
|
29-Aug-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Merge IRQ and POLL modes In general, EC transaction should complete in less than 1ms, thus it is possible to merge wait for 1ms in poll mode and 1ms of interrupt transaction timeout. Still, driver will wait 500ms for EC to complete transaction. This significantly simplifies driver and makes it immune to problematic EC interrupt implementations. It also may lessen kernel start-up time by 500ms. References: http://bugzilla.kernel.org/show_bug.cgi?id=12949 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a192a958 |
|
28-Jul-2009 |
Len Brown <len.brown@intel.com> |
ACPI: Move definition of PREFIX from acpi_bus.h to internal..h Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
cf745ec7 |
|
22-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: EC: remove .stop() method This patch folds the .stop() method into .remove(). acpi_ec_stop() is only called via acpi_device_probe() and acpi_device_remove(), and in both cases it is called immediately before acpi_ec_remove(), so there's no need to have it be a separate method. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> CC: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d02be047 |
|
22-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: EC: remove .start() method This patch folds the .start() method into .add(). acpi_ec_start() is always called immediately after acpi_ec_add(), so there's no need to have it be a separate method. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> CC: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5efc5476 |
|
22-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: EC: move acpi_ec_start() after acpi_ec_add() This patch rearranges ec_install_handlers() and acpi_ec_start() so acpi_ec_start() ends up just after acpi_ec_add(). A subsequent patch will merge them. Code movement only; no functional change. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5aa63f03 |
|
12-Apr-2009 |
Almer S. Tigelaar <almer@gnome.org> |
ACPI: EC: Fix ACPI EC resume non-query interrupt message When resuming from standby (on a laptop) I see the following message in my kernel.log: "ACPI: EC: non-query interrupt received, switching to interrupt mode" This apparently prevented sony-laptop to properly restore the brightness level on resume. The cause: In drivers/acpi/ec.c the acpi_ec_suspend function clears the GPE mode bit, but this is not restored in acpi_ec_resume (the function below it). The patch below fixes this by properly restoring the GPE_MODE bit. Tested and confirmed to work. Signed-off-by: Almer S. Tigelaar <almer@gnome.org> Signed-off-by: Mattia Dongili <malattia@linux.it> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
070d8eb1 |
|
11-Jan-2009 |
Jan Engelhardt <jengelh@medozas.de> |
ACPI: constify VFTs (1/2) Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a5032bfd |
|
31-Mar-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Always parse EC device If ECDT info is not valid, we have last chance to configure EC driver properly at this point, don't miss it. http://bugzilla.kernel.org/show_bug.cgi?id=12461 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
34ff4dbc |
|
31-Mar-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Separate delays for MSI hardware MSI notebooks require very strict delays, while all others are happy with msleep(). References: http://bugzilla.kernel.org/show_bug.cgi?id=9998 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a5f820fe |
|
24-Mar-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: call acpi_ec_init() explicitly rather than as initcall This patch makes acpi_init() call acpi_ec_init() directly. Previously, both were subsys_initcalls. acpi_ec_init() must happen after acpi_init(), and it's better to call it explicitly rather than rely on link ordering. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5423a0cb |
|
20-Feb-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add delay for slow MSI controller http://bugzilla.kernel.org/show_bug.cgi?id=12011 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4312495f |
|
17-Jan-2009 |
Tero Roponen <tero.roponen@gmail.com> |
ACPI: Fix crash on ASUS laptops This patch fixes the crash I experienced in 2.6.29-rc2. Tested on ASUS M50vm. Signed-off-by: Tero Roponen <tero.roponen@gmail.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c6cb0e87 |
|
13-Jan-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't trust ECDT tables from ASUS http://bugzilla.kernel.org/show_bug.cgi?id=9399 http://bugzilla.kernel.org/show_bug.cgi?id=11880 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
235c4a59 |
|
13-Jan-2009 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Limit workaround for ASUS notebooks even more References: http://bugzilla.kernel.org/show_bug.cgi?id=11884 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ea7e96e0 |
|
16-Dec-2008 |
Lin Ming <ming.m.lin@intel.com> |
ACPI: remove private acpica headers from driver files External driver files should not include any private acpica headers. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0175d562 |
|
16-Dec-2008 |
Lin Ming <ming.m.lin@intel.com> |
ACPI: ec.c: call acpi_get_name to get node name acpi_namespace_node is internal struct, it should not be used outside of ACPICA call acpi_get_name to get node ascii name Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8a383ef0 |
|
09-Dec-2008 |
Roel Kluin <roel.kluin@gmail.com> |
ACPI: ec.c, pci_link.c, video_detec.c: static Sparse asked whether these could be static. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3e540486 |
|
28-Nov-2008 |
Hannes Eder <hannes@hanneseder.net> |
ACPI: EC: fix compilation warning Fix the warning introduced in commit c5279dee26c0e8d7c4200993bfc4b540d2469598, and give the dummy variable a more verbose name. drivers/acpi/ec.c: In function 'acpi_ec_ecdt_probe': drivers/acpi/ec.c:1015: warning: ISO C90 forbids mixed declarations and code Signed-off-by: Hannes Eder <hannes@hanneseder.net> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7b4d4692 |
|
12-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: count interrupts only if called from interrupt handler. fix 2.6.28 EC interrupt storm regression Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c5279dee |
|
26-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add some basic check for ECDT data One more ASUS comes with empty ECDT, add a guard for it... http://bugzilla.kernel.org/show_bug.cgi?id=11880 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8517934e |
|
10-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't do transaction from GPE handler in poll mode. Referencies: http://bugzilla.kernel.org/show_bug.cgi?id=12004 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
06cf7d3c |
|
09-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: lower interrupt storm treshold http://bugzilla.kernel.org/show_bug.cgi?id=11892 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0b7084ac |
|
25-Oct-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPICA: Use spinlock for acpi_{en|dis}able_gpe Disabling gpe might interfere with gpe detection/handling, thus producing "interrupt not handled" errors. Ironically, disabling of GPE from interrupt context is already under spinlock, so only userspace needs to start using it. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a2f93aea |
|
11-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: restart failed command Restart current transaction if we recieved unexpected GPEs instead of needed ones. http://bugzilla.kernel.org/show_bug.cgi?id=11896 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dd15f8c4 |
|
08-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: wait for last write gpe There is a possibility that EC might break if next command is issued within 1 us after write or burst-disable command. Suggestd-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f8248434 |
|
01-Nov-2008 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
ACPI: EC: make kernel messages more useful when GPE storm is detected Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards. http://bugzilla.kernel.org/show_bug.cgi?id=11841 "plenty of line "ACPI: EC: non-query interrupt received, switching to interrupt mode" in dmesg" Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1cfe62c8 |
|
27-Oct-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: revert msleep patch With the better solution for EC interrupt storm issue, there is no need to use msleep over udelay. References: http://bugzilla.kernel.org/show_bug.cgi?id=11810 http://bugzilla.kernel.org/show_bug.cgi?id=10724 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d21cf3c1 |
|
03-Nov-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI EC: Fix regression due to use of uninitialized variable breakage introduced by following patch commit 27663c5855b10af9ec67bc7dfba001426ba21222 Author: Matthew Wilcox <willy@linux.intel.com> Date: Fri Oct 10 02:22:59 2008 -0400 acpi_evaluate_integer() does not clear passed variable if there is an error at evaluation. So if we ignore error, we must supply initialized variable. http://bugzilla.kernel.org/show_bug.cgi?id=11917 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
20edd74f |
|
17-Oct-2008 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Ignore AE_NOT_FOUND error of EC _REG method and continue to initialize EC On some broken BIOS the ACPI object in EC _REG method can't be found in ACPI namespace, which causes that the status code of AE_NOT_FOUND is returned by the EC _REG object. In such case the EC device can't be initialized correctly, which causes that battery/AC adapter can't work normally. As the EC address space handler is not removed and the memory pointed by its input argument is already free, sometimes the kernel will also be panic when EC internal register is still accessed. But the windows can work well on such broken BIOS. Maybe it will be reasonable that OS ignores the AE_NOT_FOUND error returned by the EC _REG object and continues to initialize EC device on some broken BIOS. For example: the ACPI object in EC _REG method can't be found and status error code is AE_NOT_FOUND. http://bugzilla.kernel.org/show_bug.cgi?id=8953 http://bugzilla.kernel.org/show_bug.cgi?id=10237 lenb: we may find a more general solution to this in the future. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c0ff1772 |
|
15-Oct-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Check for IBF=0 periodically if not in GPE mode Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
27663c58 |
|
10-Oct-2008 |
Matthew Wilcox <willy@infradead.org> |
ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels As of version 2.0, ACPI can return 64-bit integers. The current acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms. Change the argument to take a pointer to an acpi_integer so we support 64-bit integers on all platforms. lenb: replaced use of "acpi_integer" with "unsigned long long" lenb: fixed bug in acpi_thermal_trips_update() Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
db89b4f0 |
|
22-Sep-2008 |
Pavel Machek <pavel@suse.cz> |
ACPI: catch calls of acpi_driver_data on pointer of wrong type Catch attempts to use of acpi_driver_data on pointers of wrong type. akpm: rewritten to use proper C typechecking and remove the "function"-used-as-lvalue thing. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8463200a |
|
25-Sep-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Rename some variables No functional changes. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Rafael J. Wysocki <rjw@suse.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7c6db4e0 |
|
25-Sep-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: do transaction from interrupt context It is easier and faster to do transaction directly from interrupt context rather than waking control thread. Also, cleaner GPE storm avoidance is implemented. References: http://bugzilla.kernel.org/show_bug.cgi?id=9998 http://bugzilla.kernel.org/show_bug.cgi?id=10724 http://bugzilla.kernel.org/show_bug.cgi?id=10919 http://bugzilla.kernel.org/show_bug.cgi?id=11309 http://bugzilla.kernel.org/show_bug.cgi?id=11549 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9d699ed9 |
|
10-Aug-2008 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI: Avoid bogus EC timeout when EC is in Polling mode When EC is in Polling mode, OS will check the EC status continually by using the following source code: clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags); while (time_before(jiffies, delay)) { if (acpi_ec_check_status(ec, event)) return 0; msleep(1); } But msleep is realized by the function of schedule_timeout. At the same time although one process is already waken up by some events, it won't be scheduled immediately. So maybe there exists the following phenomena: a. The current jiffies is already after the predefined jiffies. But before timeout happens, OS has no chance to check the EC status again. b. If preemptible schedule is enabled, maybe preempt schedule will happen before checking loop. When the process is resumed again, maybe timeout already happens, which means that OS has no chance to check the EC status. In such case maybe EC status is already what OS expects when timeout happens. But OS has no chance to check the EC status and regards it as AE_TIME. So it will be more appropriate that OS will try to check the EC status again when timeout happens. If the EC status is what we expect, it won't be regarded as timeout. Only when the EC status is not what we expect, it will be regarded as timeout, which means that EC controller can't give a response in time. http://bugzilla.kernel.org/show_bug.cgi?id=9823 http://bugzilla.kernel.org/show_bug.cgi?id=11141 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
#
2500822b |
|
11-Aug-2008 |
Zhao Yakui <yakui.zhao@intel.com> |
ACPI : Add the EC dmi table to fix the incorrect ECDT table On some ASUS laptops the ECDT gives the incorrect command/status & Data I/O register address. AK: it seems like the command/data addresses are exchanged. In such case it will cause that EC device can't be initialized correctly. To add the EC dmi table is to fix this issue. If the laptop falls into the EC dmi table, the EC command/data I/O address will be fixed. AK: Add comments describing this better http://bugzilla.kernel.org/show_bug.cgi?id=9399 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> tested-by : Jan Kasprzak <kas@fi.muni.cz> Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
#
1b7fc5aa |
|
06-Jun-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Use msleep instead of udelay while waiting for event. http://bugzilla.kernel.org/show_bug.cgi?id=10724 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
cf7acfab |
|
29-Apr-2008 |
Denis V. Lunev <den@openvz.org> |
acpi: use non-racy method for proc entries creation Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data be setup before gluing PDE to main tree. Add correct ->owner to proc_fops to fix reading/module unloading race. Signed-off-by: Denis V. Lunev <den@openvz.org> Cc: Len Brown <lenb@kernel.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ce52ddf5 |
|
24-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't delete boot EC Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6d9e1120 |
|
24-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Use default setup handler Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fa95ba04 |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Detect irq storm Problem seems to be that hw fails to clear GPE after we service it and write 1 into corresponding bit. Thus, as soon as we get interrupts enabled again, we receive a new one. Google gives too many results for "acer interrupt storm" for this being one-broken-machine case. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9998 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
223883b7 |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Switch off GPE mode during suspend/resume Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b77d81b2 |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Replace broken controller workarounds with poll mode. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dc0e8490 |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Improve debug output Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
845625cd |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add poll timer If we can not use interrupt mode of EC for some reason, start polling EC for events periodically. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e6e82a30 |
|
21-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Restore udelay in poll mode This fixes keyboard event handling on some systems. Note that this delay was thought unnecessary, and removed from linux-2.6.20 with 50c1e1138cb94f6aca0f8555777edbcefe0324e2 'ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead.' Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d7a0e1f5 |
|
18-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
Revert "ACPI: EC: Handle IRQ storm on Acer laptops" This reverts commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26. It caused several new troubles (eg suspend slowdown bisected down to this patch by Pavel Machek), so just revert it for now. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Cc: Pavel Machek <pavel@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
2c81ce4c |
|
11-Mar-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Handle IRQ storm on Acer laptops On some Acer systems, the HW fails to clear the GPE source, causing an interrupt storm. So in EC interrupt mode, we count how many interrupts we receive when waiting. If we get more than 5, we give up on interrupt mode and revert to polling mode. Also, for polling mode to work on Acers, we need to insert a delay. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4af8e10a |
|
10-Mar-2008 |
Len Brown <len.brown@intel.com> |
Revert "ACPI: EC: Use proper handle for boot EC" This reverts commit 208c70a45624400fafd7511b96bc426bf01f8f5e. http://bugzilla.kernel.org/show_bug.cgi?id=10100 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
208c70a4 |
|
14-Feb-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Use proper handle for boot EC Fall back to ACPI_ROOT_HANDLE only in case of error. ACPI: EC: EC description table is found, configuring boot EC ACPI Error (evregion-0316): No handler for Region [ECOR] (ffff81007a651620) [EmbeddedControl] [20070126] ACPI Error (exfldio-0289): Region EmbeddedControl(3) has no handler [20070126] http://bugzilla.kernel.org/show_bug.cgi?id=9916 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d772b3b3 |
|
23-Jan-2008 |
Márton Németh <nm127@freemail.hu> |
ACPI: EC: "DEBUG" needs to be defined earlier The "DEBUG" symbol needs to be defined before #including <linux/kernel.h> to get the pr_debug() working. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
86dae015 |
|
23-Jan-2008 |
Márton Németh <nm127@freemail.hu> |
ACPI: EC: add leading zeros to debug messages Add leading zeros to pr_debug() calls. For example if x=0x0a, the format "0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a". Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
03d1d99c |
|
23-Jan-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: fix dmesg spam regression Return OBF_1 optimization workaround http://bugzilla.kernel.org/show_bug.cgi?id=8459 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b3b233c7 |
|
10-Jan-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Some hardware requires burst mode to operate properly Burst mode temporary (50 ms) locks EC to do only transactions with driver, without it some hardware returns abstract garbage. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3e71a87d |
|
10-Jan-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Do the byte access with a fast path Specification allows only byte access for EC region, so make it separate from bug-compatible multi-byte access. Also do not allow return of garbage in supplied *value. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c04209a7 |
|
01-Jan-2008 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Enable boot EC before bus_scan Some _STA methods called during bus_scan() might require EC region handler, which might be enabled later in the scan. Enable it explicitly before scan to avoid errors. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9627 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e790cc8b |
|
20-Nov-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Workaround for optimized controllers (version 3) Some controllers fail to send confirmation GPE after address or data write. Detect this and don't expect such confirmation in future. This is a generalization of previous workaround (66c5f4e7367b0085652931b2f3366de29e7ff5ec), which did only read address. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9327 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Romano Giannetti <romano.giannetti@gmail.com> Tested-by: Mats Johannesson Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3ebe08a7 |
|
20-Nov-2007 |
Márton Németh <nm127@freemail.hu> |
ACPI: EC: use printk_ratelimit(), add some DEBUG mode messages Sometimes it is usefull to see raw protocol dump. Uncomment '#define DEBUG' at the beginning of file to make EC really verbose. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0af2f653 |
|
20-Nov-2007 |
Len Brown <len.brown@intel.com> |
Revert "ACPI: EC: Workaround for optimized controllers" This reverts commit f2d68935ba08cf80f151bbdb5628381184e4a498.
|
#
4fdb2a05 |
|
19-Nov-2007 |
Joe Perches <joe@perches.com> |
ACPI: Add missing spaces to printk format Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5870a8cd |
|
15-Nov-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't init EC early if it has no _INI Option to init EC early inserted to handle #8598 ASUS problem, introduced several others. EC driver in this particular case has fake _INI method, not present on other machines, which don't need or break from this workaround, so lets use its presence as a flag for early init. http://bugzilla.kernel.org/show_bug.cgi?id=9262 http://bugzilla.kernel.org/show_bug.cgi?id=8598 https://bugzilla.novell.com/show_bug.cgi?id=334806 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f2d68935 |
|
18-Nov-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Workaround for optimized controllers Some controllers fail to send confirmation GPE after address write. Detect this and don't expect such confirmation in future. This is a generalization of previous workaround (66c5f4e7367b0085652931b2f3366de29e7ff5ec), which did only read address. http://bugzilla.kernel.org/show_bug.cgi?id=9327 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Romano Giannetti <romano.giannetti@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1544fdbc |
|
24-Oct-2007 |
Adrian Bunk <bunk@kernel.org> |
ACPI: EC: fix use-after-free This patch fixes a use-after-free introduced by commit 30c08574da0ead1a47797ce028218ce5b2de61c7 (ACPI: EC: Add new query handler to list head) Spotted by the Coverity checker. Signed-off-by: Adrian Bunk <bunk@kernel.org> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
95b937e3 |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Output changes to operational mode Insert printk() for every change in operational mode. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
66c5f4e7 |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add workaround for "optimized" controllers Some controllers do not send interrupts for OBF=1 event, but send them for IBF=0. Add workaround for them. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=8459 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1c55053c |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't re-enable GPE for each transaction. With the auto selection of operation mode, absence of GPEs does not really degrade performance, so let PM code to handle enabling/disabling GPEs. This is a revert of 5d57a6a55ec0bdcb952dbcd3f8ffcde8a3ee9413, which was meant to be temporary. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=7977 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7843932a |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: auto select interrupt mode Start in POLL mode, and if we receive confirmation GPE, switch to INT mode. If confirmations are not sent, switch back to POLL. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0c5d31f4 |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Don't expect interrupt after last read There is no interrupt after last read according to spec, so don't set bit that we are expecting one. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
080e412c |
|
22-Oct-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Replace atomic variables with bits Number of flags is about to be increased, so it is better to put them all into bits. No functional changes. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
30c08574 |
|
26-Sep-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Add new query handler to list head. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4c611060 |
|
05-Sep-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Drop ECDT-based boot_ec as soon as we find DSDT-based one. ASUS notebooks have numerous problems with EC initialization This patch tries to work around three known issues reported in bugzilla 8598, 8709 and 8909/8919. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2d8348b4 |
|
30-Aug-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Check if boot_ec was really found in DSDT acpi_get_devices() returns success if it did not find any device. We have to check for this case. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Daniel Ritz <daniel.ritz-ml@swissonline.ch> Tested-by: Luca <kronos.it@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f9319f90 |
|
23-Aug-2007 |
Alexey Starikovskiy <astarikovskiy@novell.com> |
ACPI: EC: revert fix for bugzilla 8709 This is a manual revert of 7c010de7506954e973abfab5c5999c5a97f7a73e, a fix that broke another ASUS in 8909 and 8919. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c019b193 |
|
13-Aug-2007 |
Alexey Starikovskiy <astarikivskiy@suse.de> |
ACPI: EC: Fix "no battery" regression Restore deleted call to register query methods. http://bugzilla.kernel.org/show_bug.cgi?id=8886 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
199e9e7d |
|
10-Aug-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI EC: remove potential deadlock from EC Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
0a524509 |
|
25-Jul-2007 |
Meelis Roos <mroos@linux.ee> |
ACPI: EC: fix run-together printk lines Signed-off-by: Meelis Roos <mroos@linux.ee> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
07ddf768 |
|
29-Jul-2007 |
Adrian Bunk <bunk@stusta.de> |
ACPI: EC: acpi_ec_remove(): fix use-after-free This patch fixes an obvious use-after-free introduced by commit 837012ede14a8fc088be3682c964da7fc6af026b. Spotted by the Coverity checker. Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7c010de7 |
|
03-Aug-2007 |
Alexey Starikovskiy <astarikivskiy@suse.de> |
ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT. Some ASUS laptops fail to use boot time EC and need to eventually switch to one described in DSDT. http://bugzilla.kernel.org/show_bug.cgi?id=8709 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
52fe4bdf |
|
03-Aug-2007 |
Len Brown <len.brown@intel.com> |
ACPI: EC: fix build warning drivers/acpi/ec.c:657: warning: ‘acpi_ec_register_query_methods’ defined but not used Signed-off-by: Len Brown <len.brown@intel.com>
|
#
cd8c93a4 |
|
03-Aug-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: If ECDT is not found, look up EC in DSDT. Some ASUS laptops access EC space from device _INI methods, but do not provide ECDT for early EC setup. In order to make them function properly, there is a need to find EC is DSDT before any _INI is called. Similar functionality was turned on by acpi_fake_ecdt=1 command line before. Now it is on all the time. http://bugzilla.kernel.org/show_bug.cgi?id=8598 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f1cd1fe6 |
|
03-Aug-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI: EC: Remove noisy debug printk fron EC driver. ACPI: EC: Handler for query 0x57 is not found! Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1ba90e3a |
|
23-Jul-2007 |
Thomas Renninger <trenn@suse.de> |
ACPI: autoload modules - Create __mod_acpi_device_table symbol for all ACPI drivers modpost is going to use these to create e.g. acpi:ACPI0001 in modules.alias. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
837012ed |
|
29-May-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI EC: Add support for non-AML EC query handlers Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4350933a |
|
29-May-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI EC: drop usage of ACPI_DEBUG_PRINT as too heavy weight Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5b7734b4 |
|
29-May-2007 |
Alexey Starikovskiy <astarikovskiy@suse.de> |
ACPI EC: Re-factor EC space handler to avoid using label/goto for cycle. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
00eb43a1 |
|
04-May-2007 |
Lennart Poettering <mzxreary@0pointer.de> |
acpi,msi-laptop: Fall back to EC polling mode for MSI laptop specific EC commands The ACPI EC that is used in MSI laptops knows some non-standard commands for changing the screen brighntess and a few other things, which are used by the msi-laptop.c driver. Unfortunately for these commands no GPE events for IBF and OBF are triggered. Since nowadays the EC code uses the ec_intr=1 mode by default, this causes these operations to timeout, although they don't fail. In result, all operations that you can do with the msi-laptop.c driver take more or less 1s to complete, which is awfully slow. In one of the more recent kernels (2.6.20?) the EC subsystem has been revamped. With that change the EC timeout has been increased. before that increase the MSI EC accesses were slow -- but not *that* slow, hence I took notice of this limitation of the MSI EC hardware only very recently. The standard EC operations on the MSI EC as defined in the ACPI spec support GPE events properly. The following patch adds a new argument "force_poll" to the ec_transaction() function (and friends). If set to 1, the function will poll for IBF/OBF even if ec_intr=1 is enabled. If set to 0 the current behaviour is used. The msi-laptop driver is modified to make use of this new flag, so that OBF/IBF is polled for the special MSI EC transactions -- but only for them. Signed-off-by: Lennart Poettering <mzxreary@0pointer.de> Acked-by: Alexey Starikovskiy <aystarik@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9fd9f8e8 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Block queries until EC is fully initialized Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
01f22462 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Cleanup of EC initialization Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d033879c |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: first_ec is better to be acpi_ec than acpi_device. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d66d969d |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Rename ec_ecdt to more informative boot_ec Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c0900c35 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Clean ECDT and namespace parsing. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e8284321 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Put install handlers into separate function. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3d02b90b |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Remove casts to/from void* from ec.c Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c45aac43 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: enable burst functionality in EC. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
33c7a073 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: "Fake ECDT" workaround is not needed any longer. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a5f8dee2 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: EC: Don't use Global Lock if not asked to do so Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9e197219 |
|
07-Mar-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: fix race in status register access Delay the read of the EC status register until after the event that caused it occurs -- otherwise it is possible to read and act on stale status that was associated with the previous event. Do this with a perpetually incrementing "event_count" to detect when a new event occurs and it is safe to read status. There is no workaround for polling mode -- it is inherently exposed to reading and acting on stale status, since it doesn't have an interrupt to tell it the event completed. http://bugzilla.kernel.org/show_bug.cgi?id=8110 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c24e912b |
|
15-Feb-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> |
ACPI: ec: add unlock in error path Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7cda93e0 |
|
12-Feb-2007 |
Len Brown <len.brown@intel.com> |
ACPI: delete extra #defines in /drivers/acpi/ drivers Cosmetic only. Except in a single case, #define ACPI_*_DRIVER_NAME were invoked 0 or 1 times. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c2b6705b |
|
12-Feb-2007 |
Len Brown <len.brown@intel.com> |
ACPI: fix acpi_driver.name usage It was erroneously used as a description rather than a name. ie. turn this: lenb@se7525gp2:/sys> ls bus/acpi/drivers ACPI AC Adapter Driver ACPI Embedded Controller Driver ACPI Power Resource Driver ACPI Battery Driver ACPI Fan Driver ACPI Processor Driver ACPI Button Driver ACPI PCI Interrupt Link Driver ACPI Thermal Zone Driver ACPI container driver ACPI PCI Root Bridge Driver hpet into this: lenb@se7525gp2:~> ls /sys/bus/acpi/drivers ac battery button container ec fan hpet pci_link pci_root power processor thermal Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f52fd66d |
|
12-Feb-2007 |
Len Brown <len.brown@intel.com> |
ACPI: clean up ACPI_MODULE_NAME() use cosmetic only Make "module name" actually match the file name. Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care. Fix indentation where Lindent did get confused. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
15a58ed1 |
|
02-Feb-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPICA: Remove duplicate table definitions (non-conflicting), cont Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ad363f80 |
|
02-Feb-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPICA: Remove duplicate table definitions. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ad71860a |
|
02-Feb-2007 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPICA: minimal patch to integrate new tables into Linux Signed-off-by: Len Brown <len.brown@intel.com>
|
#
723fe2ca |
|
05-Jan-2007 |
Len Brown <len.brown@intel.com> |
ACPI: ec: enable printk on cmdline use if somebody uses "ec_intr=", lets be sure to capture that in the dmesg even in the non-debug case. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c6e19194 |
|
24-Dec-2006 |
Guillaume Chazarain <guichaz@yahoo.fr> |
ACPI: EC: move verbose printk to debug build only The recent EC cleanup left a printk enabled on handler evaluation resulting in a bunch of messages on normal operation, like so: ACPI: EC: evaluating _Q60 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
36bcbec7 |
|
19-Dec-2006 |
Burman Yan <yan_952@hotmail.com> |
ACPI: replace kmalloc+memset with kzalloc Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a854e08a |
|
19-Dec-2006 |
Adrian Bunk <bunk@stusta.de> |
ACPI: make drivers/acpi/ec.c:ec_ecdt static Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6ccedb10 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Lindent once again Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3261ff4d |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Change #define to enums there possible. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
78d0af33 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Style changes. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
523953b4 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Acquire Global Lock under EC mutex. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50c1e113 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a86e2772 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Rename gpe_bit to gpe Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c787a855 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Change semaphore to mutex. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5d0c288b |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Query only single query at a time. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
e41334c0 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Remove calls to clear_gpe() and enable_gpe(), as these are handled at dispatch_gpe() level. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
af3fd140 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Remove expect_event and all races around it. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
bec5a1e0 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Read status register from check_status() function Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5c406412 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Increase timeout from 50 to 500 ms to handle old slow machines. http://bugzilla.kernel.org/show_bug.cgi?id=7466 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5d57a6a5 |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Enable EC GPE at beginning of transaction Temporary measure until resume sequence is right. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d91df1aa |
|
07-Dec-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: ec: Allow for write semantics in any command. Check for transaction attributes, not command index to decide on event to expect. Signed-off-by: Len Brown <len.brown@intel.com>
|
#
616362de |
|
26-Oct-2006 |
Randy Dunlap <randy.dunlap@oracle.com> |
ACPI: make ec_transaction not extern Fix sparse warning: drivers/acpi/ec.c:372:12: warning: function 'ec_transaction' with external linkage has definition Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50dd0969 |
|
30-Sep-2006 |
Jan Engelhardt <jengelh@linux01.gwdg.de> |
ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ab9e43c6 |
|
03-Oct-2006 |
Lennart Poettering <mzxreary@0pointer.de> |
ACPI: EC: export ec_transaction() for msi-laptop driver Signed-off-by: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6ffb221a |
|
26-Sep-2006 |
Denis M. Sadykov <denis.m.sadykov@intel.com> |
ACPI: EC: Simplify acpi_hw_low_level*() with inb()/outb(). Simplify acpi_hw_low_level_xxx() functions to inb() and outb(). Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
8e0341ba |
|
26-Sep-2006 |
Denis M. Sadykov <denis.m.sadykov@intel.com> |
ACPI: EC: Unify poll and interrupt gpe handlers Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3576cf61 |
|
26-Sep-2006 |
Denis M. Sadykov <denis.m.sadykov@intel.com> |
ACPI: EC: Unify poll and interrupt mode transaction functions Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
703959d4 |
|
26-Sep-2006 |
Denis M. Sadykov <denis.m.sadykov@intel.com> |
ACPI: EC: Remove unused variables and duplicated code Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7c6db5e5 |
|
26-Sep-2006 |
Denis M. Sadykov <denis.m.sadykov@intel.com> |
ACPI: EC: Remove unnecessary delay added by previous transation patch. Remove unnecessary delay (50 ms) while reading data from EC in interrupt mode. Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d7a76e4c |
|
04-Sep-2006 |
Lennart Poettering <mzxreary@0pointer.de> |
ACPI: consolidate functions in acpi ec driver Unify the following functions: acpi_ec_poll_read() acpi_ec_poll_write() acpi_ec_poll_query() acpi_ec_intr_read() acpi_ec_intr_write() acpi_ec_intr_query() into: acpi_ec_poll_transaction() acpi_ec_intr_transaction() These new functions take as arguments an ACPI EC command, a few bytes to write to the EC data register and a buffer for a few bytes to read from the EC data register. The old _read(), _write(), _query() are just special cases of these functions. Then unified the code in acpi_ec_poll_transaction() and acpi_ec_intr_transaction() a little more. Both functions are now just wrappers around the new acpi_ec_transaction_unlocked() function. The latter contains the EC access logic, the two original function now just do their special way of locking and call the the new function for the actual work. This saves a lot of very similar code. The primary reason for doing this, however, is that my driver for MSI 270 laptops needs to issue some non-standard EC commands in a safe way. Due to this I added a new exported function similar to ec_write()/ec_write() which is called ec_transaction() and is essentially just a wrapper around acpi_ec_{poll,intr}_transaction(). Signed-off-by: Lennart Poettering <mzxreary@0pointer.de> Acked-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d7508032 |
|
04-Jul-2006 |
Arjan van de Ven <arjan@infradead.org> |
ACPI: add 'const' to several ACPI file_operations Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
49fee981 |
|
20-Jun-2006 |
Vladimir Lebedev <vladimir.p.lebedev@intel.com> |
ACPI: fix battery on HP NX6125 EC problem was cause of both battery and AC issues. http://bugzilla.kernel.org/show_bug.cgi?id=6455 Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d550d98d |
|
26-Jun-2006 |
Patrick Mochel <mochel@linux.intel.com> |
ACPI: delete tracing macros from drivers/acpi/*.c Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6468463a |
|
26-Jun-2006 |
Len Brown <len.brown@intel.com> |
ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...) Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a6fc6720 |
|
26-Jun-2006 |
Thomas Renninger <trenn@suse.de> |
ACPI: Enable ACPI error messages w/o CONFIG_ACPI_DEBUG Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b8d35192 |
|
05-May-2006 |
Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> |
ACPI: execute Notify() handlers on new thread http://bugzilla.kernel.org/show_bug.cgi?id=5534 Thanks to Peter Wainwright for isolating the issue. Thanks to Andi Kleen and Bob Moore for feedback. Thanks to Richard Mace and others for testing. Updates by Konstantin Karasyov. Signed-off-by: Konstantin Karasyov <konstantin.a.karasyov@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f9a6ee1a |
|
19-Dec-2005 |
Rich Townsend <rhdt@bartol.udel.edu> |
ACPI: replace spin_lock_irq with mutex for ec poll mode http://bugzilla.kernel.org/show_bug.cgi?id=5764 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ff2fc3e9 |
|
28-Mar-2006 |
Jiri Slaby <jirislaby@kernel.org> |
ACPI: EC acpi-ecdt-uid-hack On some boxes ecdt uid may be equal to 0, so do not test for uids equality, so that fake handler will be unconditionally removed to allow loading the real one. See http://bugzilla.kernel.org/show_bug.cgi?id=6111 Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Luming Yu <luming.yu@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9b41046c |
|
31-Mar-2006 |
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> |
[PATCH] Don't pass boot parameters to argv_init[] The boot cmdline is parsed in parse_early_param() and parse_args(,unknown_bootoption). And __setup() is used in obsolete_checksetup(). start_kernel() -> parse_args() -> unknown_bootoption() -> obsolete_checksetup() If __setup()'s callback (->setup_func()) returns 1 in obsolete_checksetup(), obsolete_checksetup() thinks a parameter was handled. If ->setup_func() returns 0, obsolete_checksetup() tries other ->setup_func(). If all ->setup_func() that matched a parameter returns 0, a parameter is seted to argv_init[]. Then, when runing /sbin/init or init=app, argv_init[] is passed to the app. If the app doesn't ignore those arguments, it will warning and exit. This patch fixes a wrong usage of it, however fixes obvious one only. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
858119e1 |
|
14-Jan-2006 |
Arjan van de Ven <arjan@infradead.org> |
[PATCH] Unlinline a bunch of other functions Remove the "inline" keyword from a bunch of big functions in the kernel with the goal of shrinking it by 30kb to 40kb Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
50eca3eb |
|
30-Sep-2005 |
Bob Moore <robert.moore@intel.com> |
[ACPI] ACPICA 20050930 Completed a major overhaul of the Resource Manager code - specifically, optimizations in the area of the AML/internal resource conversion code. The code has been optimized to simplify and eliminate duplicated code, CPU stack use has been decreased by optimizing function parameters and local variables, and naming conventions across the manager have been standardized for clarity and ease of maintenance (this includes function, parameter, variable, and struct/typedef names.) All Resource Manager dispatch and information tables have been moved to a single location for clarity and ease of maintenance. One new file was created, named "rsinfo.c". The ACPI return macros (return_ACPI_STATUS, etc.) have been modified to guarantee that the argument is not evaluated twice, making them less prone to macro side-effects. However, since there exists the possibility of additional stack use if a particular compiler cannot optimize them (such as in the debug generation case), the original macros are optionally available. Note that some invocations of the return_VALUE macro may now cause size mismatch warnings; the return_UINT8 and return_UINT32 macros are provided to eliminate these. (From Randy Dunlap) Implemented a new mechanism to enable debug tracing for individual control methods. A new external interface, acpi_debug_trace(), is provided to enable this mechanism. The intent is to allow the host OS to easily enable and disable tracing for problematic control methods. This interface can be easily exposed to a user or debugger interface if desired. See the file psxface.c for details. acpi_ut_callocate() will now return a valid pointer if a length of zero is specified - a length of one is used and a warning is issued. This matches the behavior of acpi_ut_allocate(). Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1e8df53c |
|
05-Dec-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Embedded Controller (EC) driver printk syntax update no functional changes Signed-off-by: Len Brown <len.brown@intel.com>
|
#
53f11d4f |
|
05-Dec-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Enable Embedded Controller (EC) interrupt mode by default "ec_intr=0" reverts to polling "ec_burst=" no longer exists. Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Luming Yu <luming.yu@intel.com>
|
#
02b28a33 |
|
05-Dec-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Embedded Controller (EC) driver syntax update "intr" largely replaces "burst" for syntax to follow semantics "poll" largely replaces "polling" for economy of expression append "interrupt mode" or "polling mode" to dmesg line no functional changes Signed-off-by: Len Brown <len.brown@intel.com>
|
#
06a2a385 |
|
26-Sep-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] Disable EC burst mode w/o disabling EC interrupts Need to de-couple the concept of polling/interrupts vs burst/non-burst. http://bugzilla.kernel.org/show_bug.cgi?id=4980 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
eca008c8 |
|
21-Sep-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] handle ACPICA 20050916's acpi_resource.type rename Signed-off-by: Len Brown <len.brown@intel.com>
|
#
50526df6 |
|
11-Aug-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Lindent drivers/acpi/ec.c necessary for clean merge from acpi-2.6.12 to-akpm Signed-off-by: Len Brown <len.brown@intel.com>
|
#
716e084e |
|
09-Aug-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] Fix "ec_burst=1" mode latency issue http://bugzilla.kernel.org/show_bug.cgi?id=3851 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
4be44fcd |
|
04-Aug-2005 |
Len Brown <len.brown@intel.com> |
[ACPI] Lindent all ACPI files Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7b15f5e7 |
|
03-Aug-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12) Burst mode isn't ready for prime time, but can be enabled for test via "ec_burst=1" Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
45bea155 |
|
23-Jul-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] Add "ec_polling" boot option EC burst mode benefits many machines, some of them significantly. However, our current implementation fails on some machines such as Rafael's Asus L5D. This patch restores the alternative EC polling code, which can be enabled at boot time via "ec_polling" http://bugzilla.kernel.org/show_bug.cgi?id=4665 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
668d74c0 |
|
22-Jul-2005 |
Luming Yu <luming.yu@intel.com> |
ACPI: delete unnecessary EC console messages http://bugzilla.kernel.org/show_bug.cgi?id=4534 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
17e9c78a |
|
22-Apr-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] EC GPE-disabled issue http://bugzilla.kernel.org/show_bug.cgi?id=3851 Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
83ea7445 |
|
30-Mar-2005 |
Andrew Morton <akpm@osdl.org> |
[ACPI] fix build warning Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fa9cd547 |
|
18-Mar-2005 |
Luming Yu <luming.yu@intel.com> |
[ACPI] fix EC access width http://bugzilla.kernel.org/show_bug.cgi?id=4346 Written-by: David Shaohua Li and Luming Yu Signed-off-by: Len Brown <len.brown@intel.com>
|
#
451566f4 |
|
18-Mar-2005 |
Dmitry Torokhov <dtor@mail.ru> |
[ACPI] Enable EC Burst Mode Fixes several Embedded Controller issues, including button failure and battery status AE_TIME failure. http://bugzilla.kernel.org/show_bug.cgi?id=3851 Based on patch by: Andi Kleen <ak@suse.de> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Luming Yu <luming.yu@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
|