aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi
Commit message (Collapse)AuthorAge
* ACPI / video: ignore BIOS initial backlight value for Fujitsu E753Lan Tianyu2013-08-04
| | | | | | | | | | | | | | | commit 9657a565a476d517451c10b0bcc106e300785aff upstream. The BIOS of FUjitsu E753 reports an incorrect initial backlight value for WIN8 compatible OS, causing backlight to be dark during startup. This change causes the incorrect initial value from BIOS to be ignored. References: https://bugzilla.kernel.org/show_bug.cgi?id=60161 Reported-and-tested-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / memhotplug: Fix a stale pointer in error pathToshi Kani2013-08-04
| | | | | | | | | | | | | | | | | | commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream. device->driver_data needs to be cleared when releasing its data, mem_device, in an error path of acpi_memory_device_add(). The function evaluates the _CRS of memory device objects, and fails when it gets an unexpected resource or cannot allocate memory. A kernel crash or data corruption may occur when the kernel accesses the stale pointer. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / scan: Do not try to attach scan handlers to devices having themRafael J. Wysocki2013-08-04
| | | | | | | | | | | | | | | | | | | | | | commit 3a391a39593b48341f0908511590a6c0e55cc069 upstream. In acpi_bus_device_attach(), if there is an ACPI device object for the given handle and that device object has a scan handler attached to it already, there's nothing more to do for that handle. Moreover, if acpi_scan_attach_handler() is called then, it may execute the .attach() callback of the ACPI scan handler already attached to the device object and that may lead to interesting breakage. For this reason, make acpi_bus_device_attach() return success immediately when the handle's device object has a scan handler attached to it. Reported-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / scan: Always call acpi_bus_scan() for bus check notificationsRafael J. Wysocki2013-08-04
| | | | | | | | | | | | | | | | | | commit 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f upstream. An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the entire namespace starting from the given handle even if the device represented by that handle is present (other devices below it may just have appeared). For this reason, modify acpi_scan_bus_device_check() to always run acpi_bus_scan() if the notification being handled is of type ACPI_NOTIFY_BUS_CHECK. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / PM: Fix corner case in acpi_bus_update_power()Rafael J. Wysocki2013-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | commit 91bdad0b6237c25a7bf8fd4604d0cc64a2005a23 upstream. The role of acpi_bus_update_power() is to update the given ACPI device object's power.state field to reflect the current physical state of the device (as inferred from the configuration of power resources and _PSC, if available). For this purpose it calls acpi_device_set_power() that should update the power resources' reference counters and set power.state as appropriate. However, that doesn't work if the "new" state is D1, D2 or D3hot and the the current value of power.state means D3cold, because in that case acpi_device_set_power() will refuse to transition the device from D3cold to non-D0. To address this problem, make acpi_bus_update_power() call acpi_power_transition() directly to update the power resources' reference counters and only use acpi_device_set_power() to put the device into D0 if the current physical state of it cannot be determined. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPICA: Do not use extended sleep registers unless HW-reduced bit is setLv Zheng2013-07-21
| | | | | | | | | | | | | | | | | | | | commit 7cec7048fe22e3e92389da2cd67098f6c4284e7f upstream. Previous implementation incorrectly used the ACPI 5.0 extended sleep registers if they were simply populated. This caused problems on some non-HW-reduced machines. As per the ACPI spec, they should only be used if the HW-reduced bit is set. Lv Zheng, ACPICA BZ 1020. Reported-by: Daniel Rowe <bart@fathom13.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=54181 References: https://bugs.acpica.org/show_bug.cgi?id=1020 Bisected-by: Brint E. Kriebel <kernel@bekit.net> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scanLan Tianyu2013-07-21
| | | | | | | | | | | | | | | | commit eff9a4b62b14cf0d9913e3caf1f26f8b7a6105c9 upstream. HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's _REG method will access that region. To allow the CMOS RTC region handler to be installed before the EC _REG method is first invoked, add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI: Add CMOS RTC Operation Region handler supportLan Tianyu2013-07-21
| | | | | | | | | | | | | | | | | | | | | | commit 2fa97feb4406c546b52e35b6b6c50cb8f63425d2 upstream. On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and the EC's _REG methord accesses that region. Thus an appropriate address space handler must be registered for that region before the EC driver is loaded. Introduce a mechanism for adding CMOS RTC address space handlers. Register an ACPI scan handler for CMOS RTC devices such that, when a device of that kind is detected during an ACPI namespace scan, a common CMOS RTC operation region address space handler will be installed for it. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / dock / PCI: Synchronous handling of dock events for PCI devicesRafael J. Wysocki2013-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: Jiang Liu <jiang.liu@huawei.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
* ACPI / dock: Initialize ACPI dock subsystem upfrontJiang Liu2013-06-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3b63aaa70e1 (PCI: acpiphp: Do not use ACPI PCI subdriver mechanism) introduced an ACPI dock support regression, because it changed the relative initialization order of the ACPI dock subsystem and the ACPI-based PCI hotplug (acpiphp). Namely, the ACPI dock subsystem has to be initialized before acpiphp_enumerate_slots() is first run, which after commit 3b63aaa70e1 happens during the initial enumeration of the PCI hierarchy triggered by the initial ACPI namespace scan in acpi_scan_init(). For this reason, the dock subsystem has to be initialized before the initial ACPI namespace scan in acpi_scan_init(). To make that happen, modify the ACPI dock subsystem to be non-modular and add the invocation of its initialization routine, acpi_dock_init(), to acpi_scan_init() directly before the initial namespace scan. [rjw: Changelog, removal of dock_exit().] References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / LPSS: Power up LPSS devices during enumerationRafael J. Wysocki2013-06-19
| | | | | | | | | | | | | | | | | | Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Fix error code path for power resources initializationRafael J. Wysocki2013-06-19
| | | | | | | | | | | | | | | | | | | | Commit 781d737 (ACPI: Drop power resources driver) introduced a bug in the power resources initialization error code path causing a NULL pointer to be referenced in acpi_release_power_resource() if there's an error triggering a jump to the 'err' label in acpi_add_power_resource(). This happens because the list_node field of struct acpi_power_resource has not been initialized yet at this point and doing a list_del() on it is a bad idea. To prevent this problem from occuring, initialize the list_node field of struct acpi_power_resource upfront. Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* ACPI / dock: Take ACPI scan lock in write_undock()Rafael J. Wysocki2013-06-19
| | | | | | | | | | | | | | | | | | | | | Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be called under acpi_scan_lock, but currently the following scenario violating that requirement is possible: write_undock() handle_eject_request() hotplug_dock_devices() dock_remove_acpi_device() acpi_bus_trim() Fix that by making write_undock() acquire acpi_scan_lock before calling handle_eject_request() as appropriate (begin_undock() is under the lock too in analogy with acpi_dock_deferred_cb()). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
* ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resourcesMika Westerberg2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_get_override_irq() was added because there was a problem with buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The commit that added the workaround was 61fd47e0c8476 (ACPI: fix two IRQ8 issues in IOAPIC mode). With ACPI 5 enumerated devices there are typically one or more extended IRQ resources per device (and these IRQs can be shared). However, the acpi_get_override_irq() workaround forces all IRQs in range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high as can be seen from the dmesg below: ACPI: IRQ 6 override to edge, high ACPI: IRQ 7 override to edge, high ACPI: IRQ 7 override to edge, high ACPI: IRQ 13 override to edge, high Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows the same thing: 7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00 The _CSR method for INT33C2 (and INT33C3) device returns following resource: Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, ) { 0x00000007, } which states that this is supposed to be level triggered, active low, shared IRQ instead. Fix this by making sure that acpi_get_override_irq() gets only called when we are dealing with legacy IRQ() or IRQNoFlags() descriptors. While we are there, correct pr_warning() to print the right triggering value. This change turns out to be necessary to make DMA work correctly on systems based on the Intel Lynxpoint PCH (Platform Controller Hub). [rjw: Changelog] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / video: Do not bind to device objects with a scan handlerRafael J. Wysocki2013-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of ACPI scan handlers, ACPI device objects with an ACPI scan handler attached to them must not be bound to by ACPI drivers any more. Unfortunately, however, the ACPI video driver attempts to do just that if there is a _ROM ACPI control method defined under a device object with an ACPI scan handler. Prevent that from happening by making the video driver's "add" routine check if the device object already has an ACPI scan handler attached to it and return an error code in that case. That is not sufficient, though, because acpi_bus_driver_init() would then clear the device object's driver_data that may be set by its scan handler, so for the fix to work acpi_bus_driver_init() has to be modified to leave driver_data as is on errors. References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com> Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com> Tracked-down-by: Aaron Lu <aaron.lu@intel.com> Cc: 3.9+ <stable@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* Revert "ACPI / scan: do not match drivers against objects having scan handlers"Rafael J. Wysocki2013-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects having scan handlers") introduced a boot regression on Tony's ia64 HP rx2600. Tony says: "It panics with the message: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel [...] my problem comes from arch/ia64/hp/common/sba_iommu.c where the code in sba_init() says: acpi_bus_register_driver(&acpi_sba_ioc_driver); if (!ioc_list) { but because of this change we never managed to call ioc_init() so ioc_list doesn't get set up, and we die." Revert it to avoid this breakage and we'll fix the problem it attempted to address later. Reported-by: Tony Luck <tony.luck@gmail.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'acpi-fixes'Rafael J. Wysocki2013-06-07
|\ | | | | | | | | | | | | | | | | | | * acpi-fixes: ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization ACPI / scan: do not match drivers against objects having scan handlers ACPI / APEI: fix error return code in ghes_probe() ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6 ACPI / video: ignore BIOS initial backlight value for HP m4 x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup()
| * ACPI / PM: Do not execute _PS0 for devices without _PSC during initializationRafael J. Wysocki2013-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com> Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / scan: do not match drivers against objects having scan handlersAaron Lu2013-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of ACPI scan handlers, an ACPI device object with an ACPI scan handler attached to it must not be bound to an ACPI driver any more. Therefore it doesn't make sense to match those ACPI device objects against a newly registered ACPI driver in acpi_bus_match(), so make that function return 0 if the device object passed to it has an ACPI scan handler attached. This also addresses a regression related to a broken ACPI table in the BIOS, where it has defined a _ROM method under the PCI root bridge object. This causes the video module to treat that object as a display controller device (since only display devices are supposed to have a _ROM method defined according to the ACPI spec). As a result, the ACPI video driver binds to the PCI root bridge object and overwrites the previously assigned driver_data field of it, causing subsequent calls to acpi_get_pci_dev() to fail. [rjw: Subject and changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell <bluesloth600@gmail.com> Reported-and-bisected-by: Dmitry S. Demin <dmitryy.demin@gmail.com> Cc: 3.9+ <stable@kernel.org> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / APEI: fix error return code in ghes_probe()Wei Yongjun2013-06-05
| | | | | | | | | | | | | | | | | | | | Fix to return a negative error code in the acpi_gsi_to_irq() and request_irq() error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6Ash Willis2013-06-01
| | | | | | | | | | | | | | | | | | | | | | | | This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661 Signed-off-by: Ash Willis <ashwillis@programmer.net> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / video: ignore BIOS initial backlight value for HP m4Alex Hung2013-06-01
| | | | | | | | | | | | | | | | | | | | | | On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501 Cc: All <stable@vger.kernel.org> Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | aerdrv: Move cper_print_aer() call out of interrupt contextLance Ortiz2013-05-30
|/ | | | | | | | | | | | | | | | | | | | | The following warning was seen on 3.9 when a corrected PCIe error was being handled by the AER subsystem. WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90() This occurred because a call to pci_get_domain_bus_and_slot() was added to cper_print_pcie() to setup for the call to cper_print_aer(). The warning showed up because cper_print_pcie() is called in an interrupt context and pci_get* functions are not supposed to be called in that context. The solution is to move the cper_print_aer() call out of the interrupt context and into aer_recover_work_func() to avoid any warnings when calling pci_get* functions. Signed-off-by: Lance Ortiz <lance.ortiz@hp.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* Merge tag 'pm+acpi-3.10-rc3' of ↵Linus Torvalds2013-05-25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI fixes from Rafael Wysocki: - Additional CPU ID for the intel_pstate driver from Dirk Brandewie. - More cpufreq fixes related to ARM big.LITTLE support and locking from Viresh Kumar. - VIA C7 cpufreq build fix from Rafał Bilski. - ACPI power management fix making it possible to use device power states regardless of the CONFIG_PM setting from Rafael J Wysocki. - New ACPI video blacklist item from Bastian Triller. * tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist cpufreq: arm_big_little_dt: Instantiate as platform_driver cpufreq: arm_big_little_dt: Register driver only if DT has valid data cpufreq / e_powersaver: Fix linker error when ACPI processor is a module cpufreq / intel_pstate: Add additional supported CPU ID cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT ACPI / PM: Allow device power states to be used for CONFIG_PM unset
| * ACPI / video: Add "Asus UL30A" to ACPI video detect blacklistBastian Triller2013-05-22
| | | | | | | | | | | | | | | | | | | | | | | | Like on UL30VT, the ACPI video driver can't control backlight correctly on Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30A" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30A" rather than ACPI video driver. Signed-off-by: Bastian Triller <bastian.triller@gmail.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / PM: Allow device power states to be used for CONFIG_PM unsetRafael J. Wysocki2013-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of the functions defined in there are replaced with static inline stubs if that option is unset. However, CONFIG_PM means, roughly, "runtime PM or suspend/hibernation support" and some of those functions are useful regardless of that. For example, they are used by the ACPI fan driver for controlling fans and acpi_device_set_power() is called during device removal. Moreover, device initialization may depend on setting device power states properly. For these reasons, make the routines manipulating ACPI device power states defined in drivers/acpi/device_pm.c available for CONFIG_PM unset too. Reported-by: Zhang Rui <rui.zhang@intel.com> Reported-and-tested-by: Michel Lespinasse <walken@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
* | Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds2013-05-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | Pull slave-dma fixes from Vinod Koul: "We have two patches from Andy & Rafael fixing the Lynxpoint dma" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: ACPI / LPSS: register clock device for Lynxpoint DMA properly dma: acpi-dma: parse CSRT to extract additional resources
| * | ACPI / LPSS: register clock device for Lynxpoint DMA properlyRafael J. Wysocki2013-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To work properly it is using the LPSS root clock as a functional clock. That's why we have to register the clock device accordingly to the ACPI ID of the DMA controller. The acpi_lpss.c module is responsible to do the job. This patch also removes hardcoded name of the DMA device in clk-lpt.c and the name of the root clock in acpi_lpss.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
| * | dma: acpi-dma: parse CSRT to extract additional resourcesAndy Shevchenko2013-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we have CSRT only to get additional DMA controller resources, let's get rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* | | Merge tag 'pci-v3.10-fixes-2' of ↵Linus Torvalds2013-05-23
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI updates from Bjorn Helgaas: "Here are some more fixes for v3.10. The Moorestown update broke Intel Medfield devices, so I reverted it. The acpiphp change fixes a regression: we broke hotplug notifications to host bridges when we split acpiphp into the host-bridge related part and the endpoint-related part. Moorestown Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0" Hotplug PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check" * tag 'pci-v3.10-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0" PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check
| * | PCI: acpiphp: Re-enumerate devices when host bridge receives Bus CheckYinghai Lu2013-05-17
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a PCI host bridge device receives a Bus Check notification, we must re-enumerate starting with the bridge to discover changes (devices that have been added or removed). Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that commit, _handle_hotplug_event_bridge() is not installed for host bridges, and the host bridge notify handler, _handle_hotplug_event_root() did not re-enumerate. This patch adds re-enumeration to _handle_hotplug_event_root(). This fixes cases where we don't notice the addition or removal of PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below. [bhelgaas: changelog, references] Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961 Reported-by: Gavin Guo <tuffkidtt@gmail.com> Tested-by: Gavin Guo <tuffkidtt@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.9+
* | ACPI / scan: Fix memory leak on acpi_scan_init_hotplug() error pathCatalin Marinas2013-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following commit 6b772e8f9 (ACPI: Update PNPID match handling for notify), the acpi_scan_init_hotplug() calls acpi_set_pnp_ids() which allocates acpi_hardware_id and copies a few strings (kstrdup). If the devices does not have hardware_id set, the function exits without freeing the previously allocated ids (and kmemleak complains). This patch calls simply changes 'return' on error to a 'goto out' which calls acpi_free_pnp_ids(). Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / AC: Add sleep quirk for Thinkpad e530Lan Tianyu2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Thinkpad e530's BIOS notifies the AC device first and then sleeps for certain amount of time before doing real work in the EC event handler (_Qxx): Method (_Q27, 0, NotSerialized) { Notify (AC, 0x80) Sleep (0x03E8) Store (Zero, PWRS) PNOT () } This causes the AC driver to report an outdated AC state to user space, because it reads the state information from the device while the EC handler is sleeping. Introduce a quirk to cause the AC driver to wait in acpi_ac_notify() before calling acpi_ac_get_state() on systems known to have this problem and add Thinkpad e530 to the list of quirky machines (with a 1s delay which has been verified to be sufficient for that machine). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=45221 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / EC: Restart transaction even when the IBF flag setLan Tianyu2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EC driver works abnormally with IBF flag always set. IBF means "The host has written a byte of data to the command or data port, but the embedded controller has not yet read it". If IBF is set in the EC status and not cleared, this will cause all subsequent EC requests to fail with a timeout error. Change the EC driver so that it doesn't refuse to restart a transaction if IBF is set in the status. Also increase the number of transaction restarts to 5, as it turns out that 2 is not sufficient in some cases. This bug happens on several different machines (Asus V1S, Dell Latitude E6530, Samsung R719, Acer Aspire 5930G, Sony Vaio SR19VN and others). [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=14733 References: https://bugzilla.kernel.org/show_bug.cgi?id=15560 References: https://bugzilla.kernel.org/show_bug.cgi?id=15946 References: https://bugzilla.kernel.org/show_bug.cgi?id=42945 References: https://bugzilla.kernel.org/show_bug.cgi?id=48221 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI video: ignore BIOS initial backlight value for HP 1000Alex Hung2013-05-12
| | | | | | | | | | | | | | | | | | | | On HP 1000 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References:: https://bugs.launchpad.net/bugs/1167760 Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PM: Move processor suspend/resume to syscore_opsRafael J. Wysocki2013-05-12
|/ | | | | | | | | | | | | | | The system suspend routine of the ACPI processor driver saves the BUS_MASTER_RLD register and its resume routine restores it. However, there can be only one such register in the system and it really should be saved after non-boot CPUs have been offlined and restored before they are put back online during resume. For this reason, move the saving and restoration of BUS_MASTER_RLD to syscore suspend and syscore resume, respectively, and drop the no longer necessary suspend/resume callbacks from the ACPI processor driver. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'acpi-fixes-3.10-rc1' of ↵Linus Torvalds2013-05-09
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPICA fixes from Rafael Wysocki: - _INI regression fix from Tomasz Nowicki. - Fix for a possible memory leak in _OSI support routine from Jung-uk Kim. - Fix for a possible buffer overflow during field unit read operation from Bob Moore. * tag 'acpi-fixes-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPICA: ACPICA: Fix for _INI regression ACPICA: _OSI support: Fix possible memory leak ACPICA: Fix possible buffer overflow during a field unit read operation
| * ACPICA: ACPICA: Fix for _INI regressionTomasz Nowicki2013-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a problem introduced by recent commit c34c82b (ACPICA: Predefine names: Add allowed argument types to master info table) in 20130328 where _INI methods are no longer executed properly because of a memory block that is not initialized properly. ACPICA BZ1016. Tomasz Nowicki <tomasz.nowicki@linaro.org> References: https://bugs.acpica.org/show_bug.cgi?id=1016 Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPICA: _OSI support: Fix possible memory leakJung-uk Kim2013-05-08
| | | | | | | | | | | | | | | | | | | | | | | | Fixes a possible memory leak in the error exit path introduced by recent commit 388a990 ("ACPICA: _OSI Support: handle any errors from acpi_os_acquire_mutex()"). [rjw: Changelog] Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPICA: Fix possible buffer overflow during a field unit read operationBob Moore2013-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | Can only happen under these conditions: 1) The DSDT version is 1, meaning integers are 32-bits. 2) The field is between 33 and 64 bits long. It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+). Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 2.6.37+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'for-linus' of ↵Linus Torvalds2013-05-01
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull VFS updates from Al Viro, Misc cleanups all over the place, mainly wrt /proc interfaces (switch create_proc_entry to proc_create(), get rid of the deprecated create_proc_read_entry() in favor of using proc_create_data() and seq_file etc). 7kloc removed. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits) don't bother with deferred freeing of fdtables proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h proc: Make the PROC_I() and PDE() macros internal to procfs proc: Supply a function to remove a proc entry by PDE take cgroup_open() and cpuset_open() to fs/proc/base.c ppc: Clean up scanlog ppc: Clean up rtas_flash driver somewhat hostap: proc: Use remove_proc_subtree() drm: proc: Use remove_proc_subtree() drm: proc: Use minor->index to label things, not PDE->name drm: Constify drm_proc_list[] zoran: Don't print proc_dir_entry data in debug reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show() proc: Supply an accessor for getting the data from a PDE's parent airo: Use remove_proc_subtree() rtl8192u: Don't need to save device proc dir PDE rtl8187se: Use a dir under /proc/net/r8180/ proc: Add proc_mkdir_data() proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h} proc: Move PDE_NET() to fs/proc/proc_net.c ...
| * | proc: Supply a function to remove a proc entry by PDEDavid Howells2013-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supply a function (proc_remove()) to remove a proc entry (and any subtree rooted there) by proc_dir_entry pointer rather than by name and (optionally) root dir entry pointer. This allows us to eliminate all remaining pde->name accesses outside of procfs. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Grant Likely <grant.likely@linaro.or> cc: linux-acpi@vger.kernel.org cc: openipmi-developer@lists.sourceforge.net cc: devicetree-discuss@lists.ozlabs.org cc: linux-pci@vger.kernel.org cc: netdev@vger.kernel.org cc: netfilter-devel@vger.kernel.org cc: alsa-devel@alsa-project.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | procfs: new helper - PDE_DATA(inode)Al Viro2013-04-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only part of proc_dir_entry the code outside of fs/proc really cares about is PDE(inode)->data. Provide a helper for that; static inline for now, eventually will be moved to fs/proc, along with the knowledge of struct proc_dir_entry layout. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | Merge tag 'pm+acpi-3.10-rc1' of ↵Linus Torvalds2013-04-30
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI updates from Rafael J Wysocki: - ARM big.LITTLE cpufreq driver from Viresh Kumar. - exynos5440 cpufreq driver from Amit Daniel Kachhap. - cpufreq core cleanup and code consolidation from Viresh Kumar and Stratos Karafotis. - cpufreq scalability improvement from Nathan Zimmer. - AMD "frequency sensitivity feedback" powersave bias for the ondemand cpufreq governor from Jacob Shin. - cpuidle code consolidation and cleanups from Daniel Lezcano. - ARM OMAP cpuidle fixes from Santosh Shilimkar and Daniel Lezcano. - ACPICA fixes and other improvements from Bob Moore, Jung-uk Kim, Lv Zheng, Yinghai Lu, Tang Chen, Colin Ian King, and Linn Crosetto. - ACPI core updates related to hotplug from Toshi Kani, Paul Bolle, Yasuaki Ishimatsu, and Rafael J Wysocki. - Intel Lynxpoint LPSS (Low-Power Subsystem) support improvements from Rafael J Wysocki and Andy Shevchenko. * tag 'pm+acpi-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (192 commits) cpufreq: Revert incorrect commit 5800043 cpufreq: MAINTAINERS: Add co-maintainer cpuidle: add maintainer entry ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points ARM: s3c64xx: cpuidle: use init/exit common routine cpufreq: pxa2xx: initialize variables ACPI: video: correct acpi_video_bus_add error processing SH: cpuidle: use init/exit common routine ARM: S5pv210: compiling issue, ARM_S5PV210_CPUFREQ needs CONFIG_CPU_FREQ_TABLE=y ACPI: Fix wrong parameter passed to memblock_reserve cpuidle: fix comment format pnp: use %*phC to dump small buffers isapnp: remove debug leftovers ARM: imx: cpuidle: use init/exit common routine ARM: davinci: cpuidle: use init/exit common routine ARM: kirkwood: cpuidle: use init/exit common routine ARM: calxeda: cpuidle: use init/exit common routine ARM: tegra: cpuidle: use init/exit common routine for tegra3 ARM: tegra: cpuidle: use init/exit common routine for tegra2 ARM: OMAP4: cpuidle: use init/exit common routine ...
| * | Merge branch 'pm-cpuidle'Rafael J. Wysocki2013-04-27
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-cpuidle: (51 commits) cpuidle: add maintainer entry ARM: s3c64xx: cpuidle: use init/exit common routine SH: cpuidle: use init/exit common routine cpuidle: fix comment format ARM: imx: cpuidle: use init/exit common routine ARM: davinci: cpuidle: use init/exit common routine ARM: kirkwood: cpuidle: use init/exit common routine ARM: calxeda: cpuidle: use init/exit common routine ARM: tegra: cpuidle: use init/exit common routine for tegra3 ARM: tegra: cpuidle: use init/exit common routine for tegra2 ARM: OMAP4: cpuidle: use init/exit common routine ARM: shmobile: cpuidle: use init/exit common routine ARM: tegra: cpuidle: use init/exit common routine ARM: OMAP3: cpuidle: use init/exit common routine ARM: at91: cpuidle: use init/exit common routine ARM: ux500: cpuidle: use init/exit common routine cpuidle: make a single register function for all ARM: ux500: cpuidle: replace for_each_online_cpu by for_each_possible_cpu cpuidle: remove en_core_tk_irqen flag ARM: OMAP3: remove cpuidle_wrap_enter ...
| | * | cpuidle: remove en_core_tk_irqen flagDaniel Lezcano2013-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The en_core_tk_irqen flag is set in all the cpuidle driver which means it is not necessary to specify this flag. Remove the flag and the code related to it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Kevin Hilman <khilman@linaro.org> # for mach-omap2/* Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | Merge branch 'acpi-assorted' into linux-nextRafael J. Wysocki2013-04-08
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-assorted: PCI / ACPI: Don't query OSC support with all possible controls ACPI / processor_thermal: avoid null pointer deference error ACPI / fan: avoid null pointer deference error ACPI / video: Fix applying indexed initial brightness value. ACPI / video: Make logic a little easier to understand. ACPI / video: Fix brightness control initialization for some laptops. ACPI: Use resource_size() in osl.c ACPI / acpi_pad: Used PTR_RET ACPI: suppress compiler warning in container.c ACPI: suppress compiler warning in battery.c ACPI: suppress compiler warnings in processor_throttling.c ACPI: suppress compiler warnings in button.c ACPI: replace kmalloc+memcpy with kmemdup ACPI: Remove acpi_pci_bind_root() definition ACPI video: ignore BIOS backlight value for HP dm4
| | * \ \ Merge branch 'acpi-pm' into linux-nextRafael J. Wysocki2013-04-08
| | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * acpi-pm: ACPI / PM: Fix potential problem in acpi_device_get_power()
| | * \ \ \ Merge branch 'acpica' into linux-nextRafael J. Wysocki2013-04-08
| | |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpica: (22 commits) ACPI: Set length even for TYPE_END_TAG acpi resource ACPICA: Update version to 20130214 ACPICA: Object repair: Allow 0-length packages for variable-length packages ACPICA: Disassembler: Add warnings for unresolved control methods ACPICA: Return object repair: Add resource template repairs ACPICA: Return object repair: Add string-to-unicode conversion ACPICA: Split object conversion functions to a new file ACPICA: Add mechanism for early object repairs on a per-name basis ACPICA: Remove trailing comma in enum declarations ACPICA: Add exception descriptions to exception info table ACPICA: Add macros to exception code definitions ACPICA: Regression fix: reinstate safe exit macros ACPICA: Update for ACPI 5 hardware-reduced feature ACPICA: Add parens within macros around parameter names ACPICA: Add macros to access pointer to next object in the descriptor list ACPICA: Update error/debug messages for fixed events ACPICA: Fix a long-standing bug in local cache ACPICA: iASL/Disassembler: Add support for MTMR table ACPICA: iASL/Disassembler: Add support for VRTC table ACPICA: Update RASF table definition ...
| | * \ \ \ \ Merge branch 'acpi-lpss' into linux-nextRafael J. Wysocki2013-04-08
| | |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-lpss: ACPI / LPSS: make code less confusing for reader ACPI / LPSS: Add support for exposing LTR registers to user space ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-22 17:40:39 -0500