kernel.git/drivers/acpi/sbshc.c, branch linux-4.4.y

ACPI / SBS: Fix rare oops when removing modules

2019-11-25T14:54:46Z

[ Upstream commit 757c968c442397f1249bb775a7c8c03842e3e0c7 ] There was a small race when removing the sbshc module where smbus_alarm() had queued acpi_smbus_callback() for deferred execution but it hadn't been run yet, so that when it did run hc had been freed and the module unloaded, resulting in an invalid paging request. A similar race existed when removing the sbs module with regards to acpi_sbs_callback() (which is called from acpi_smbus_callback()). We therefore need to ensure no callbacks are pending or executing before the cleanups are done and the modules are removed. Signed-off-by: Ronald TschalÃ¤r Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: sbshc: remove raw pointer from printk() message

2018-02-16T19:09:47Z

commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 upstream. There's no need to be printing a raw kernel pointer to the kernel log at every boot. So just remove it, and change the whole message to use the correct dev_info() call at the same time. Reported-by: Wang Qize Signed-off-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Revert "ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook"

2015-11-16T22:26:45Z

Revert commit 3349fb64b292 (ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook), since the delay introduced by it is not necessary any more after commit add68d6aa9e2 (ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code). Signed-off-by: Chris Bainbridge [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki

ACPI / SMBus: Fix boot stalls / high CPU caused by reentrant code

2015-11-16T22:23:45Z

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 Signed-off-by: Rafael J. Wysocki

ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook

2015-04-30T21:18:11Z

Commit 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly' caused the MacBook firmware to expose the SBS, resulting in intermittent hangs of several minutes on boot, and failure to detect or report the battery. Fix this by adding a 5 us delay to the start of each SMBUS transaction. This timing is the result of experimentation - hangs were observed with 3 us but never with 5 us. Fixes: 7bc5a2bad0b8 'ACPI: Support _OSI("Darwin") correctly' Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651 Signed-off-by: Chris Bainbridge Cc: 3.18+ # 3.18+ [ rjw: Subject and changelog ] Signed-off-by: Rafael J. Wysocki

ACPI: Clean up inclusions of ACPI header files

2013-12-07T00:03:14Z

Replace direct inclusions of , and , which are incorrect, with inclusions and remove some inclusions of those files that aren't necessary. First of all, , and 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, 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 be included prior to so that the acpi_pci_root declarations the latter depends on are always there. And 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 as appropriate. Signed-off-by: Lv Zheng Cc: Greg Kroah-Hartman Cc: Matthew Garrett Cc: Tony Luck Cc: "H. Peter Anvin" Acked-by: Bjorn Helgaas (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk (Xen stuff) Signed-off-by: Rafael J. Wysocki

ACPI: Remove useless type argument of driver .remove() operation

2013-01-25T23:37:24Z

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 Reviewed-by: Jiang Liu Acked-by: Toshi Kani Acked-by: Yinghai Lu

ACPI/sbshc: convert to module_acpi_driver()

2012-09-21T17:39:40Z

Signed-off-by: Mika Westerberg Signed-off-by: Len Brown

acpi: add module.h to files implicitly using/relying on it.

2011-10-31T23:30:32Z

These files are using standard module API things like MODULE_AUTHOR etc. and so should not be relying on an implicit presence of the module.h header. Signed-off-by: Paul Gortmaker

sbshc: acpi_device_class "smbus_host_controller" too long

2010-05-06T06:38:25Z

acpi_device_class can only be 19 characters and a NULL terminator. With the current name we get a buffer overflow in acpi_smbus_hc_add() when we do: strcpy(acpi_device_class(device), ACPI_SMB_HC_CLASS); Signed-off-by: Dan Carpenter Cc: Alexey Starikovskiy Signed-off-by: Andrew Morton Signed-off-by: Len Brown