linux/drivers/acpi, branch v3.19

Revert "ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA"

2015-02-03T13:29:43Z

Revert commit 6c17ee44d524 (ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA), as it introduced registration and probe ordering problems between devices on the LPSS that may lead to full hard system hang on boot in some cases.

ACPI: pci: Do not clear pci_dev->irq in acpi_pci_irq_disable()

2015-01-20T10:44:40Z

Xen pciback driver assumes that pci_dev->irq won't change after calling pci_disable_device(). But commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ("x86, irq: Keep balance of IOAPIC pin reference count") frees irq resources and resets pci_dev->irq to zero when pci_disable_device() is called. So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and another proper fix will be prepared for next merging window. Signed-off-by: Jiang Liu Tested-by: Sander Eikelenboom Cc: Tony Luck Cc: Konrad Rzeszutek Wilk Cc: David Vrabel Cc: Rafael J. Wysocki Cc: Len Brown Link: http://lkml.kernel.org/r/1421720467-7709-3-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner

Merge branch 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux

2015-01-13T18:53:51Z

Pull thermal management fixes from Zhang Rui: "Specifics: - Fix a problem that Intel SoC DTS thermal driver does not work when CONFIG_THERMAL_INT340X is not set. - Fix a NULL pointer dereference when processor_thermal_device driver is loaded on a platform without ACPI support" * 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: int340x_thermal/processor_thermal_device: return failure when ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRT

Merge branches 'acpi-pm', 'acpi-processor' and 'acpi-video'

2015-01-06T22:35:43Z

* acpi-pm: ACPI / PM: Fix PM initialization for devices that are not present * acpi-processor: ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() ACPI / processor: Convert apic_id to phys_id to make it arch agnostic * acpi-video: ACPI / video: Add disable_native_backlight quirk for Dell XPS15 L521X

ACPI / video: Add disable_native_backlight quirk for Dell XPS15 L521X

2015-01-06T22:34:48Z

The L521X variant of the Dell XPS15 has integrated nvidia graphics, and backlight control does not work properly when using the native interfaces. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1163574 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver

2015-01-06T00:17:14Z

Intel SoC DTS thermal driver on Baytrail platform uses IRQ 86 for critical overheating notification. But this IRQ 86 is described in the _CRS control method of INT3401 device, thus we should enumerate INT3401 to set the IRQ descriptor when Intel SoC DTS thermal driver is built. Signed-off-by: Zhang Rui Tested-by: Srinivas Pandruvada

ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRT

2015-01-06T00:17:06Z

For some INT340X thermal devices, even if they are not referred in _TRT/_ART table, they still can be used by userspace for thermal control. Thus change the code to enumerated all the INT340X devices, no matter if they're referred in _TRT/_ART or not. Signed-off-by: Zhang Rui Tested-by: Srinivas Pandruvada

ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu()

2015-01-05T22:34:26Z

acpi_map_lsapic() will allocate a logical CPU number and map it to physical CPU id (such as APIC id) for the hot-added CPU, it will also do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will do the reverse. We can see that the name of the function is a little bit confusing and arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch agnostic and explicit. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / processor: Convert apic_id to phys_id to make it arch agnostic

2015-01-05T22:32:42Z

apic_id in MADT table is the CPU hardware id which identify it self in the system for x86 and ia64, OSPM will use it for SMP init to map APIC ID to logical cpu number in the early boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the ACPI processor driver is probed and the driver will use acpi_id in DSDT to get the apic_id, then map to the logical cpu number which is needed by the processor driver. Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec, so apic_id is used both in arch code and ACPI core which is pretty fine. Since ACPI 5.0, ARM is supported by ACPI and APIC is not available on ARM, this will confuse people when apic_id is both used by x86 and ARM in one function. So convert apic_id to phys_id (which is the original meaning) in ACPI processor dirver to make it arch agnostic, but leave the arch dependent code unchanged, no functional change. Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix PM initialization for devices that are not present

2015-01-05T21:49:52Z

If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Cc: 3.10+ # 3.10+