linux-stable.git/drivers/acpi, branch v3.16.46

ACPI / power: Avoid maybe-uninitialized warning

2017-07-18T17:40:37+00:00

commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream.

gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
is enterered at least once, so it assumes that cur_state might not get
initialized:

drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This sets the variable to zero at the start of the loop, to ensure that
there is well-defined behavior even for an empty list. This gets rid of
the warning.

The warning first showed up when the -Os flag got removed in a bug fix
patch in linux-4.11-rc5.

I would suggest merging this addon patch on top of that bug fix to avoid
introducing a new warning in the stable kernels.

Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing)
Signed-off-by: Arnd Bergmann 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI: Fix incompatibility with mcount-based function graph tracing

2017-07-18T17:40:25+00:00

commit 61b79e16c68d703dde58c25d3935d67210b7d71b upstream.

Paul Menzel reported a warning:

  WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0
  Bad frame pointer: expected f6919d98, received f6919db0
    from func acpi_pm_device_sleep_wake return to c43b6f9d

The warning means that function graph tracing is broken for the
acpi_pm_device_sleep_wake() function.  That's because the ACPI Makefile
unconditionally sets the '-Os' gcc flag to optimize for size.  That's an
issue because mcount-based function graph tracing is incompatible with
'-Os' on x86, thanks to the following gcc bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109

I have another patch pending which will ensure that mcount-based
function graph tracing is never used with CONFIG_CC_OPTIMIZE_FOR_SIZE on
x86.

But this patch is needed in addition to that one because the ACPI
Makefile overrides that config option for no apparent reason.  It has
had this flag since the beginning of git history, and there's no related
comment, so I don't know why it's there.  As far as I can tell, there's
no reason for it to be there.  The appropriate behavior is for it to
honor CONFIG_CC_OPTIMIZE_FOR_{SIZE,PERFORMANCE} like the rest of the
kernel.

Reported-by: Paul Menzel 
Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt (VMware) 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal

2017-07-18T17:40:24+00:00

commit 7d64f82cceb21e6d95db312d284f5f195e120154 upstream.

When removing a GHES device notified by SCI, list_del_rcu() is used,
ghes_remove() should call synchronize_rcu() before it goes on to call
kfree(ghes), otherwise concurrent RCU readers may still hold this list
entry after it has been freed.

Signed-off-by: James Morse 
Reviewed-by: "Huang, Ying" 
Fixes: 81e88fdc432a (ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support)
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI: Do not create a platform_device for IOAPIC/IOxAPIC

2017-07-18T17:40:24+00:00

commit 08f63d97749185fab942a3a47ed80f5bd89b8b7d upstream.

No platform-device is required for IO(x)APICs, so don't even
create them.

[ rjw: This fixes a problem with leaking platform device objects
  after IOAPIC/IOxAPIC hot-removal events.]

Signed-off-by: Joerg Roedel 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI / APEI: Fix incorrect return value of ghes_proc()

2017-02-23T03:54:20+00:00

commit 806487a8fc8f385af75ed261e9ab658fc845e633 upstream.

Although ghes_proc() tests for errors while reading the error status,
it always return success (0). Fix this by propagating the return
value.

Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support)
Signed-of-by: Punit Agrawal 
Tested-by: Tyler Baicar 
Reviewed-by: Borislav Petkov 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI / processor: Avoid reserving IO regions too early

2016-08-22T21:38:07+00:00

commit 86314751c7945fa0c67f459beeda2e7c610ca429 upstream.

Roland Dreier reports that one of his systems cannot boot because of
the changes made by commit ac212b6980d8 (ACPI / processor: Use common
hotplug infrastructure).

The problematic part of it is the request_region() call in
acpi_processor_get_info() that used to run at module init time before
the above commit and now it runs much earlier.  Unfortunately, the
region(s) reserved by it fall into a range the PCI subsystem attempts
to reserve for AHCI IO BARs.  As a result, the PCI reservation fails
and AHCI doesn't work, while previously the PCI reservation would
be made before acpi_processor_get_info() and it would succeed.

That request_region() call, however, was overlooked by commit
ac212b6980d8, as it is not necessary for the enumeration of the
processors.  It only is needed when the ACPI processor driver
actually attempts to handle them which doesn't happen before
loading the ACPI processor driver module.  Therefore that call
should have been moved from acpi_processor_get_info() into that
module.

Address the problem by moving the request_region() call in question
out of acpi_processor_get_info() and use the observation that the
region reserved by it is only needed if the FADT-based CPU
throttling method is going to be used, which means that it should
be sufficient to invoke it from acpi_processor_get_throttling_fadt().

Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure)
Reported-by: Roland Dreier 
Tested-by: Roland Dreier 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI / sysfs: fix error code in get_status()

2016-08-22T21:37:54+00:00

commit f18ebc211e259d4f591e39e74b2aa2de226c9a1d upstream.

The problem with ornamental, do-nothing gotos is that they lead to
"forgot to set the error code" bugs.  We should be returning -EINVAL
here but we don't.  It leads to an uninitalized variable in
counter_show():

    drivers/acpi/sysfs.c:603 counter_show()
    error: uninitialized symbol 'status'.

Fixes: 1c8fce27e275 (ACPI: introduce drivers/acpi/sysfs.c)
Signed-off-by: Dan Carpenter 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPICA: Dispatcher: Update thread ID for recursive method calls

2016-06-15T20:29:30+00:00

commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da upstream.

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava 

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava 
Tested-by: Andy Lutomirski  # On a Dell XPS 13 9350
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

ACPI: Use correct IRQ when uninstalling ACPI interrupt handler

2015-12-13T17:48:55+00:00

commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.

Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.

Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.

Acked-by: Lv Zheng 
Signed-off-by: Chen Yu 
Signed-off-by: Rafael J. Wysocki 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)

2015-09-28T09:21:41+00:00

commit 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae upstream.

This way this device can be used with irtty-sir -
at least on Toshiba Satellite A20-S103 it is not configured by default
and needs PNP activation before it starts to respond on I/O ports.

This device has actually its own driver (ali-ircc),
but this driver seems to be non-functional for a very long time
(see http://permalink.gmane.org/gmane.linux.irda.general/484
http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).

Signed-off-by: Maciej Szmigiero 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques