2019-05-31 16:09:32 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2007-09-26 23:43:28 +08:00
|
|
|
/*
|
|
|
|
* SMBus driver for ACPI Embedded Controller (v0.1)
|
|
|
|
*
|
|
|
|
* Copyright (c) 2007 Alexey Starikovskiy
|
|
|
|
*/
|
|
|
|
|
2021-06-02 16:54:36 +08:00
|
|
|
#define pr_fmt(fmt) "ACPI: " fmt
|
|
|
|
|
2013-12-03 08:49:16 +08:00
|
|
|
#include <linux/acpi.h>
|
2007-09-26 23:43:28 +08:00
|
|
|
#include <linux/wait.h>
|
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>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2007-09-26 23:43:28 +08:00
|
|
|
#include <linux/delay.h>
|
2011-07-02 02:30:49 +08:00
|
|
|
#include <linux/module.h>
|
2007-09-26 23:43:28 +08:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include "sbshc.h"
|
|
|
|
|
2010-04-28 05:06:05 +08:00
|
|
|
#define ACPI_SMB_HC_CLASS "smbus_host_ctl"
|
2007-09-26 23:43:28 +08:00
|
|
|
#define ACPI_SMB_HC_DEVICE_NAME "ACPI SMBus HC"
|
|
|
|
|
|
|
|
struct acpi_smb_hc {
|
|
|
|
struct acpi_ec *ec;
|
|
|
|
struct mutex lock;
|
|
|
|
wait_queue_head_t wait;
|
|
|
|
u8 offset;
|
|
|
|
u8 query_bit;
|
|
|
|
smbus_alarm_callback callback;
|
|
|
|
void *context;
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
bool done;
|
2007-09-26 23:43:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static int acpi_smbus_hc_add(struct acpi_device *device);
|
2013-01-24 07:24:48 +08:00
|
|
|
static int acpi_smbus_hc_remove(struct acpi_device *device);
|
2007-09-26 23:43:28 +08:00
|
|
|
|
|
|
|
static const struct acpi_device_id sbs_device_ids[] = {
|
|
|
|
{"ACPI0001", 0},
|
|
|
|
{"ACPI0005", 0},
|
|
|
|
{"", 0},
|
|
|
|
};
|
|
|
|
|
|
|
|
MODULE_DEVICE_TABLE(acpi, sbs_device_ids);
|
|
|
|
|
|
|
|
static struct acpi_driver acpi_smb_hc_driver = {
|
|
|
|
.name = "smbus_hc",
|
|
|
|
.class = ACPI_SMB_HC_CLASS,
|
|
|
|
.ids = sbs_device_ids,
|
|
|
|
.ops = {
|
|
|
|
.add = acpi_smbus_hc_add,
|
|
|
|
.remove = acpi_smbus_hc_remove,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
union acpi_smb_status {
|
|
|
|
u8 raw;
|
|
|
|
struct {
|
|
|
|
u8 status:5;
|
|
|
|
u8 reserved:1;
|
|
|
|
u8 alarm:1;
|
|
|
|
u8 done:1;
|
|
|
|
} fields;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum acpi_smb_status_codes {
|
|
|
|
SMBUS_OK = 0,
|
|
|
|
SMBUS_UNKNOWN_FAILURE = 0x07,
|
|
|
|
SMBUS_DEVICE_ADDRESS_NACK = 0x10,
|
|
|
|
SMBUS_DEVICE_ERROR = 0x11,
|
|
|
|
SMBUS_DEVICE_COMMAND_ACCESS_DENIED = 0x12,
|
|
|
|
SMBUS_UNKNOWN_ERROR = 0x13,
|
|
|
|
SMBUS_DEVICE_ACCESS_DENIED = 0x17,
|
|
|
|
SMBUS_TIMEOUT = 0x18,
|
|
|
|
SMBUS_HOST_UNSUPPORTED_PROTOCOL = 0x19,
|
|
|
|
SMBUS_BUSY = 0x1a,
|
|
|
|
SMBUS_PEC_ERROR = 0x1f,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum acpi_smb_offset {
|
|
|
|
ACPI_SMB_PROTOCOL = 0, /* protocol, PEC */
|
|
|
|
ACPI_SMB_STATUS = 1, /* status */
|
|
|
|
ACPI_SMB_ADDRESS = 2, /* address */
|
|
|
|
ACPI_SMB_COMMAND = 3, /* command */
|
|
|
|
ACPI_SMB_DATA = 4, /* 32 data registers */
|
|
|
|
ACPI_SMB_BLOCK_COUNT = 0x24, /* number of data bytes */
|
|
|
|
ACPI_SMB_ALARM_ADDRESS = 0x25, /* alarm address */
|
|
|
|
ACPI_SMB_ALARM_DATA = 0x26, /* 2 bytes alarm data */
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline int smb_hc_read(struct acpi_smb_hc *hc, u8 address, u8 *data)
|
|
|
|
{
|
|
|
|
return ec_read(hc->offset + address, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int smb_hc_write(struct acpi_smb_hc *hc, u8 address, u8 data)
|
|
|
|
{
|
|
|
|
return ec_write(hc->offset + address, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int wait_transaction_complete(struct acpi_smb_hc *hc, int timeout)
|
|
|
|
{
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
if (wait_event_timeout(hc->wait, hc->done, msecs_to_jiffies(timeout)))
|
2007-09-26 23:43:28 +08:00
|
|
|
return 0;
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
return -ETIME;
|
2007-09-26 23:43:28 +08:00
|
|
|
}
|
|
|
|
|
2007-10-25 00:24:42 +08:00
|
|
|
static int acpi_smbus_transaction(struct acpi_smb_hc *hc, u8 protocol,
|
|
|
|
u8 address, u8 command, u8 *data, u8 length)
|
2007-09-26 23:43:28 +08:00
|
|
|
{
|
|
|
|
int ret = -EFAULT, i;
|
|
|
|
u8 temp, sz = 0;
|
|
|
|
|
2008-02-09 16:22:13 +08:00
|
|
|
if (!hc) {
|
2021-06-02 16:54:36 +08:00
|
|
|
pr_err("host controller is not configured\n");
|
2008-02-09 16:22:13 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-09-26 23:43:28 +08:00
|
|
|
mutex_lock(&hc->lock);
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
hc->done = false;
|
2007-09-26 23:43:28 +08:00
|
|
|
if (smb_hc_read(hc, ACPI_SMB_PROTOCOL, &temp))
|
|
|
|
goto end;
|
|
|
|
if (temp) {
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
smb_hc_write(hc, ACPI_SMB_COMMAND, command);
|
|
|
|
if (!(protocol & 0x01)) {
|
|
|
|
smb_hc_write(hc, ACPI_SMB_BLOCK_COUNT, length);
|
|
|
|
for (i = 0; i < length; ++i)
|
|
|
|
smb_hc_write(hc, ACPI_SMB_DATA + i, data[i]);
|
|
|
|
}
|
|
|
|
smb_hc_write(hc, ACPI_SMB_ADDRESS, address << 1);
|
|
|
|
smb_hc_write(hc, ACPI_SMB_PROTOCOL, protocol);
|
|
|
|
/*
|
|
|
|
* Wait for completion. Save the status code, data size,
|
|
|
|
* and data into the return package (if required by the protocol).
|
|
|
|
*/
|
|
|
|
ret = wait_transaction_complete(hc, 1000);
|
|
|
|
if (ret || !(protocol & 0x01))
|
|
|
|
goto end;
|
|
|
|
switch (protocol) {
|
|
|
|
case SMBUS_RECEIVE_BYTE:
|
|
|
|
case SMBUS_READ_BYTE:
|
|
|
|
sz = 1;
|
|
|
|
break;
|
|
|
|
case SMBUS_READ_WORD:
|
|
|
|
sz = 2;
|
|
|
|
break;
|
|
|
|
case SMBUS_READ_BLOCK:
|
|
|
|
if (smb_hc_read(hc, ACPI_SMB_BLOCK_COUNT, &sz)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
sz &= 0x1f;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
for (i = 0; i < sz; ++i)
|
|
|
|
smb_hc_read(hc, ACPI_SMB_DATA + i, &data[i]);
|
|
|
|
end:
|
|
|
|
mutex_unlock(&hc->lock);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int acpi_smbus_read(struct acpi_smb_hc *hc, u8 protocol, u8 address,
|
|
|
|
u8 command, u8 *data)
|
|
|
|
{
|
|
|
|
return acpi_smbus_transaction(hc, protocol, address, command, data, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_smbus_read);
|
|
|
|
|
|
|
|
int acpi_smbus_write(struct acpi_smb_hc *hc, u8 protocol, u8 address,
|
|
|
|
u8 command, u8 *data, u8 length)
|
|
|
|
{
|
|
|
|
return acpi_smbus_transaction(hc, protocol, address, command, data, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_smbus_write);
|
|
|
|
|
|
|
|
int acpi_smbus_register_callback(struct acpi_smb_hc *hc,
|
2020-11-05 10:06:00 +08:00
|
|
|
smbus_alarm_callback callback, void *context)
|
2007-09-26 23:43:28 +08:00
|
|
|
{
|
|
|
|
mutex_lock(&hc->lock);
|
|
|
|
hc->callback = callback;
|
|
|
|
hc->context = context;
|
|
|
|
mutex_unlock(&hc->lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_smbus_register_callback);
|
|
|
|
|
|
|
|
int acpi_smbus_unregister_callback(struct acpi_smb_hc *hc)
|
|
|
|
{
|
|
|
|
mutex_lock(&hc->lock);
|
|
|
|
hc->callback = NULL;
|
|
|
|
hc->context = NULL;
|
|
|
|
mutex_unlock(&hc->lock);
|
2018-10-01 10:53:13 +08:00
|
|
|
acpi_os_wait_events_complete();
|
2007-09-26 23:43:28 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_smbus_unregister_callback);
|
|
|
|
|
2007-12-08 18:02:40 +08:00
|
|
|
static inline void acpi_smbus_callback(void *context)
|
2007-09-26 23:43:28 +08:00
|
|
|
{
|
|
|
|
struct acpi_smb_hc *hc = context;
|
|
|
|
if (hc->callback)
|
|
|
|
hc->callback(hc->context);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int smbus_alarm(void *context)
|
|
|
|
{
|
|
|
|
struct acpi_smb_hc *hc = context;
|
|
|
|
union acpi_smb_status status;
|
2007-12-08 18:02:40 +08:00
|
|
|
u8 address;
|
2007-09-26 23:43:28 +08:00
|
|
|
if (smb_hc_read(hc, ACPI_SMB_STATUS, &status.raw))
|
|
|
|
return 0;
|
|
|
|
/* Check if it is only a completion notify */
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
if (status.fields.done && status.fields.status == SMBUS_OK) {
|
|
|
|
hc->done = true;
|
2007-09-26 23:43:28 +08:00
|
|
|
wake_up(&hc->wait);
|
ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-13 02:05:37 +08:00
|
|
|
}
|
2007-09-26 23:43:28 +08:00
|
|
|
if (!status.fields.alarm)
|
|
|
|
return 0;
|
|
|
|
mutex_lock(&hc->lock);
|
2007-12-08 18:02:40 +08:00
|
|
|
smb_hc_read(hc, ACPI_SMB_ALARM_ADDRESS, &address);
|
2007-12-08 18:02:33 +08:00
|
|
|
status.fields.alarm = 0;
|
2007-09-26 23:43:28 +08:00
|
|
|
smb_hc_write(hc, ACPI_SMB_STATUS, status.raw);
|
2007-12-08 18:02:40 +08:00
|
|
|
/* We are only interested in events coming from known devices */
|
|
|
|
switch (address >> 1) {
|
|
|
|
case ACPI_SBS_CHARGER:
|
|
|
|
case ACPI_SBS_MANAGER:
|
|
|
|
case ACPI_SBS_BATTERY:
|
2009-12-30 20:53:03 +08:00
|
|
|
acpi_os_execute(OSL_NOTIFY_HANDLER,
|
2007-12-08 18:02:40 +08:00
|
|
|
acpi_smbus_callback, hc);
|
|
|
|
}
|
2007-09-26 23:43:28 +08:00
|
|
|
mutex_unlock(&hc->lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef int (*acpi_ec_query_func) (void *data);
|
|
|
|
|
|
|
|
extern int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
|
|
|
|
acpi_handle handle, acpi_ec_query_func func,
|
|
|
|
void *data);
|
|
|
|
|
|
|
|
static int acpi_smbus_hc_add(struct acpi_device *device)
|
|
|
|
{
|
|
|
|
int status;
|
2008-10-10 14:22:59 +08:00
|
|
|
unsigned long long val;
|
2007-09-26 23:43:28 +08:00
|
|
|
struct acpi_smb_hc *hc;
|
|
|
|
|
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
status = acpi_evaluate_integer(device->handle, "_EC", NULL, &val);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2021-06-02 16:54:36 +08:00
|
|
|
pr_err("error obtaining _EC.\n");
|
2007-09-26 23:43:28 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
strcpy(acpi_device_name(device), ACPI_SMB_HC_DEVICE_NAME);
|
|
|
|
strcpy(acpi_device_class(device), ACPI_SMB_HC_CLASS);
|
|
|
|
|
|
|
|
hc = kzalloc(sizeof(struct acpi_smb_hc), GFP_KERNEL);
|
|
|
|
if (!hc)
|
|
|
|
return -ENOMEM;
|
|
|
|
mutex_init(&hc->lock);
|
|
|
|
init_waitqueue_head(&hc->wait);
|
|
|
|
|
|
|
|
hc->ec = acpi_driver_data(device->parent);
|
|
|
|
hc->offset = (val >> 8) & 0xff;
|
|
|
|
hc->query_bit = val & 0xff;
|
2008-09-23 05:37:34 +08:00
|
|
|
device->driver_data = hc;
|
2007-09-26 23:43:28 +08:00
|
|
|
|
|
|
|
acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
|
2018-01-19 17:06:03 +08:00
|
|
|
dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
|
|
|
|
hc->offset, hc->query_bit);
|
2007-09-26 23:43:28 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8 query_bit);
|
|
|
|
|
2013-01-24 07:24:48 +08:00
|
|
|
static int acpi_smbus_hc_remove(struct acpi_device *device)
|
2007-09-26 23:43:28 +08:00
|
|
|
{
|
|
|
|
struct acpi_smb_hc *hc;
|
|
|
|
|
|
|
|
if (!device)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
hc = acpi_driver_data(device);
|
|
|
|
acpi_ec_remove_query_handler(hc->ec, hc->query_bit);
|
2018-10-01 10:53:13 +08:00
|
|
|
acpi_os_wait_events_complete();
|
2007-09-26 23:43:28 +08:00
|
|
|
kfree(hc);
|
2008-09-23 05:37:34 +08:00
|
|
|
device->driver_data = NULL;
|
2007-09-26 23:43:28 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-09-07 15:31:42 +08:00
|
|
|
module_acpi_driver(acpi_smb_hc_driver);
|
2007-09-26 23:43:28 +08:00
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_AUTHOR("Alexey Starikovskiy");
|
|
|
|
MODULE_DESCRIPTION("ACPI SMBus HC driver");
|