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

ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings

2016-06-03T15:30:35+00:00

[ Upstream commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 ]

The order of the _OSI related functionalities is as follows:

  acpi_blacklisted()
    acpi_dmi_osi_linux()
      acpi_osi_setup()
    acpi_osi_setup()
      acpi_update_interfaces() if "!*"
      <<<<<<<<<<<<<<<<<<<<<<<<
  parse_args()
    __setup("acpi_osi=")
      acpi_osi_setup_linux()
        acpi_update_interfaces() if "!*"
        <<<<<<<<<<<<<<<<<<<<<<<<
  acpi_early_init()
    acpi_initialize_subsystem()
      acpi_ut_initialize_interfaces()
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  acpi_bus_init()
    acpi_os_initialize1()
      acpi_install_interface_handler(acpi_osi_handler)
      acpi_osi_setup_late()
        acpi_update_interfaces() for "!"
        >>>>>>>>>>>>>>>>>>>>>>>>
  acpi_osi_handler()

Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
line setting can override the DMI detection. That's why acpi_blacklisted()
is put before __setup("acpi_osi=").

Then we can notice the following wrong invocation order. There are
acpi_update_interfaces() (marked by <<<<) calls invoked before
acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
to use acpi_osi=!* correctly from OSI DMI table or from the command line.
The use of acpi_osi=!* is meant to disable both ACPICA
(acpi_gbl_supported_interfaces) and Linux specific strings
(osi_setup_entries) while the ACPICA part should have stopped working
because of the order issue.

This patch fixes this issue by moving acpi_update_interfaces() to where
it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
specific strings are still handled in the original place in order to make
the following command line working: acpi_osi=!* acpi_osi="Module Device".

Note that since acpi_osi=!* is meant to further disable linux specific
string comparing to the acpi_osi=!, there is no such use case in our bug
fixing work and hence there is no one using acpi_osi=!* either from the
command line or from the DMI quirks, this issue is just a theoretical
issue.

Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings)
Cc: 3.12+  # 3.12+
Tested-by: Lukas Wunner 
Tested-by: Chen Yu 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPICA: Dispatcher: Update thread ID for recursive method calls

2016-05-17T21:30:14+00:00

[ Upstream commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da ]

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 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

x86, irq: Keep balance of IOAPIC pin reference count

2016-04-18T12:49:18+00:00

[ Upstream commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ]

To keep balance of IOAPIC pin reference count, we need to protect
pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
from reentrance. There are two cases which will cause reentrance.

The first case is caused by suspend/hibernation. If pcibios_disable_irq
is called during suspending/hibernating, we don't release the assigned
IRQ number, otherwise it may break the suspend/hibernation. So late when
pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
number again.

The second case is that function acpi_pci_irq_enable() may be called
twice for PCI devices present at boot time as below:
1) pci_acpi_init()
	--> acpi_pci_irq_enable() if pci_routeirq is true
2) pci_enable_device()
	--> pcibios_enable_device()
		--> acpi_pci_irq_enable()
We can't kill kernel parameter pci_routeirq yet because it's still
needed for debugging purpose.

So flag irq_managed is introduced to track whether IRQ number is
assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
and intel_mid_pci_irq_enable() from reentrance.

Signed-off-by: Jiang Liu 
Cc: Konrad Rzeszutek Wilk 
Cc: Tony Luck 
Cc: Joerg Roedel 
Cc: Greg Kroah-Hartman 
Cc: Benjamin Herrenschmidt 
Cc: Rafael J. Wysocki 
Cc: Bjorn Helgaas 
Cc: Randy Dunlap 
Cc: Yinghai Lu 
Cc: Borislav Petkov 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

ACPI / init: Switch over platform to the ACPI mode later

2015-08-27T17:25:39+00:00

[ Upstream commit cdbbeb69d4b93455a73edff725639216d7fe0b38 ]

commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream.

Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early.  Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".

However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.

To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.

That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().

Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Toshi Kani 
Reviewed-by: Hanjun Guo 
Reviewed-by: Lee, Chun-Yi 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

ACPICA: Tables: Fix an issue that FACS initialization is performed twice

2015-08-04T18:33:56+00:00

[ Upstream commit c04be18448355441a0c424362df65b6422e27bda ]

ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658

This patch adds a new FACS initialization flag for acpi_tb_initialize().
acpi_enable_subsystem() might be invoked several times in OS bootup process,
and we don't want FACS initialization to be invoked twice. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/90f5332a
Cc: All applicable  # All applicable
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI / PM: Add missing pm_generic_complete() invocation

2015-07-04T03:02:26+00:00

[ Upstream commit 3d56402d3fa8d10749eeb36293dd1992bd5ad0c3 ]

Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.

Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
Cc: 3.16+  # 3.16+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

Driver core: Unified device properties interface for platform firmware

2015-06-28T17:39:20+00:00

[ Upstream commit b31384fa5de37a100507751dfb5c0a49d06cee67 ]

Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type.  The purpose of it is to help to
write portable code that won't depend on any particular platform
firmware interface.

The following general helper functions are added:

device_property_present()
device_property_read_u8()
device_property_read_u16()
device_property_read_u32()
device_property_read_u64()
device_property_read_string()
device_property_read_u8_array()
device_property_read_u16_array()
device_property_read_u32_array()
device_property_read_u64_array()
device_property_read_string_array()

The first one allows the caller to check if the given property is
present.  The next 5 of them allow single-valued properties of
various types to be retrieved in a uniform way.  The remaining 5 are
for reading properties with multiple values (arrays of either numbers
or strings).

The interface covers both ACPI and Device Trees.

This change set includes material from Mika Westerberg and Aaron Lu.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Acked-by: Greg Kroah-Hartman 
Acked-by: Grant Likely 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Add support for device specific properties

2015-06-28T17:39:20+00:00

[ Upstream commit ffdcd955c3078af3ce117edcfce80fde1a512bed ]

Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.

ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.

In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.

If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:

	Name (_DSD, Package () {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
			Package () {"name1", },
			Package () {"name2", },
			...
		}
	})

The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].

We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.

The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.

[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Reviewed-by: Hanjun Guo 
Reviewed-by: Josh Triplett 
Reviewed-by: Grant Likely 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI / init: Fix the ordering of acpi_reserve_resources()

2015-06-10T17:42:40+00:00

[ Upstream commit b9a5e5e18fbf223502c0b2264c15024e393da928 ]

Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code.  On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code
path.

Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.

Reported-and-tested-by: George McCollister 
Link: http://marc.info/?t=143092384600002&r=1&w=2
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.

2015-06-09T17:43:42+00:00

[ Upstream commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada ]

ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of
ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().

This patch also removes above replaced macros as there are no users.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Link: https://github.com/acpica/acpica/commit/b6061237
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin