summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/internal.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-11-071-5/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-hotplug: ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines ACPI / hotplug: Do not execute "insert in progress" _OST ACPI / hotplug: Carry out PCI root eject directly ACPI / hotplug: Merge device hot-removal routines ACPI / hotplug: Make acpi_bus_hot_remove_device() internal ACPI / hotplug: Simplify device ejection routines ACPI / hotplug: Fix handle_root_bridge_removal() ACPI / hotplug: Refuse to hot-remove all objects with disabled hotplug ACPI / scan: Start matching drivers after trying scan handlers ACPI: Remove acpi_pci_slot_init() headers from internal.h Conflicts: include/acpi/acpiosxf.h (with the 'acpica' branch)
| * ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routinesRafael J. Wysocki2013-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two different interfaces for queuing up work items on the ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host bridge hotplug code and acpi_os_hotplug_execute() used by the common ACPI hotplug code and docking stations. They both are somewhat cumbersome to use and work slightly differently. The users of alloc_acpi_hp_work() have to submit a work function that will extract the necessary data items from a struct acpi_hp_work object allocated by alloc_acpi_hp_work() and then will free that object, while it would be more straightforward to simply use a work function with one more argument and let the interface take care of the execution details. The users of acpi_os_hotplug_execute() also have to deal with the fact that it takes only one argument in addition to the work function pointer, although acpi_os_execute_deferred() actually takes care of the allocation and freeing of memory, so it would have been able to pass more arguments to the work function if it hadn't been constrained by the connection with acpi_os_execute(). Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory allocations, which is correct, because hotplug work items are always queued up from process context, acpi_os_hotplug_execute() uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also, acpi_os_execute_deferred() queued up by it waits for the ACPI event workqueues to flush before executing the work function, whereas alloc_acpi_hp_work() can't do anything similar. That leads to somewhat arbitrary differences in behavior between various ACPI hotplug code paths and has to be straightened up. For this reason, replace both alloc_acpi_hp_work() and acpi_os_hotplug_execute() with a single interface, acpi_hotplug_execute(), combining their behavior and being more friendly to its users than any of the two. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * ACPI / hotplug: Carry out PCI root eject directlyRafael J. Wysocki2013-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | Since _handle_hotplug_event_root() is run from the ACPI hotplug workqueue, it doesn't need to queue up a work item to eject a PCI host bridge on the same workqueue. Instead, it can just carry out the eject by calling acpi_bus_device_eject() directly, so make that happen. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / hotplug: Make acpi_bus_hot_remove_device() internalRafael J. Wysocki2013-11-071-0/+1
| | | | | | | | | | | | | | | | | | Notice that handle_root_bridge_removal() is the only user of acpi_bus_hot_remove_device(), so it doesn't have to be exported any more and can be made internal to the ACPI core. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI: Remove acpi_pci_slot_init() headers from internal.hRafael J. Wysocki2013-11-071-5/+0
| | | | | | | | | | | | | | | | | | | | | | Since acpi_pci_slot_init() is now called from acpi_pci_init() and pci-acpi.h contains its header, remove that header (and the empty definition of that function for CONFIG_ACPI_PCI_SLOT unset) from internal.h as it doesn't have to be there any more. That also avoids a build warning about duplicate function definitions for CONFIG_ACPI_PCI_SLOT unset. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / video: Do not register backlight if win8 and native interface existsAaron Lu2013-10-161-3/+1
|/ | | | | | | | | | | | | | | | | | | | | According to Matthew Garrett, "Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows [8] doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems". So for Win8 systems, if there is native backlight control interface registered by GPU driver, ACPI video does not need to register its own. Since there are systems that don't work well with this approach, a parameter for video module named use_native_backlight is introduced and has the value of false by default. For users who have a broken ACPI video backlight interface, video.use_native_backlight=1 is needed in kernel cmdline. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge back earlier 'acpi-assorted' materialRafael J. Wysocki2013-08-141-0/+1
|\
| * ACPI: Cleanup sparse warning on acpi_os_initialize1()Lv Zheng2013-07-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch cleans up the following sparse warning: # make C=2 drivers/acpi/osl.o ... drivers/acpi/osl.c:1775:20: warning: symbol 'acpi_os_initialize1' was not declared. Should it be static? ... CC drivers/acpi/osl.o Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"Rafael J. Wysocki2013-07-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We attempted to address a regression introduced by commit a57f7f9 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which ACPI video backlight support doesn't work on a number of systems, because the relevant AML methods in the ACPI tables in their BIOSes become useless after the BIOS has been told that the OS is compatible with Windows 8. That problem is tracked by the bug entry at: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware expects Windows 8) introduced for this purpose essentially prevented the ACPI backlight support from being used if the BIOS had been told that the OS was compatible with Windows 8 and the i915 driver was loaded, in which case the backlight would always be handled by i915. Unfortunately, however, that turned out to cause problems with backlight to appear on multiple systems with symptoms indicating that i915 was unable to control the backlight on those systems as expected. For this reason, revert commit 8c5bd7a, but leave the function acpi_video_backlight_quirks() introduced by it, because another commit on top of it uses that function. References: https://lkml.org/lkml/2013/7/21/119 References: https://lkml.org/lkml/2013/7/22/261 References: https://lkml.org/lkml/2013/7/23/429 References: https://lkml.org/lkml/2013/7/23/459 References: https://lkml.org/lkml/2013/7/23/81 References: https://lkml.org/lkml/2013/7/24/27 Reported-and-tested-by: James Hogan <james@albanarts.com> Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com> Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com> Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk> Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Reported-by: Kalle Valo <kvalo@adurom.com> Tested-by: Joerg Platte <jplatte@naasa.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / video / i915: No ACPI backlight if firmware expects Windows 8Rafael J. Wysocki2013-07-181-0/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Matthew Garrett, "Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows [8] doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems". There's a problem with that approach, however, because simply avoiding to register the ACPI backlight interface if the firmware calls _OSI for Windows 8 may not work in the following situations: (1) The ACPI backlight interface actually works on the given system and the i915 driver is not loaded (e.g. another graphics driver is used). (2) The ACPI backlight interface doesn't work on the given system, but there is a vendor platform driver that will register its own, equally broken, backlight interface if not prevented from doing so by the ACPI subsystem. Therefore we need to allow the ACPI backlight interface to be registered until the i915 driver is loaded which then will unregister it if the firmware has called _OSI for Windows 8 (or will register the ACPI video driver without backlight support if not already present). For this reason, introduce an alternative function for registering ACPI video, acpi_video_register_with_quirks(), that will check whether or not the ACPI video driver has already been registered and whether or not the backlight Windows 8 quirk has to be applied. If the quirk has to be applied, it will block the ACPI backlight support and either unregister the backlight interface if the ACPI video driver has already been registered, or register the ACPI video driver without the backlight interface otherwise. Make the i915 driver use acpi_video_register_with_quirks() instead of acpi_video_register() in i915_driver_load(). This change is based on earlier patches from Matthew Garrett, Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's. References: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Tested-by: Aaron Lu <aaron.lu@intel.com> Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Tested-by: Yves-Alexis Perez <corsac@debian.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
* Merge branch 'acpi-assorted'Rafael J. Wysocki2013-06-281-0/+5
|\ | | | | | | | | | | | | | | | | | | | | * acpi-assorted: ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan ACPI: Add CMOS RTC Operation Region handler support ACPI: Remove unused flags in acpi_device_flags ACPI: Remove useless initializers ACPI / battery: Make sure all spaces are in correct places ACPI: add _STA evaluation at do_acpi_find_child() ACPI / EC: access user space with get_user()/put_user()
| * ACPI: Add CMOS RTC Operation Region handler supportLan Tianyu2013-06-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-06-281-0/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-hotplug: ACPI: Do not use CONFIG_ACPI_HOTPLUG_MEMORY_MODULE ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq Memory hotplug: Move alternative function definitions to header ACPI / processor: Fix potential NULL pointer dereference in acpi_processor_add() Memory hotplug / ACPI: Simplify memory removal ACPI / scan: Add second pass of companion offlining to hot-remove code Driver core / MM: Drop offline_memory_block() ACPI / processor: Pass processor object handle to acpi_bind_one() ACPI: Drop removal_type field from struct acpi_device Driver core / memory: Simplify __memory_block_change_state() ACPI / processor: Initialize per_cpu(processors, pr->id) properly CPU: Fix sysfs cpu/online of offlined CPUs Driver core: Introduce offline/online callbacks for memory blocks ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes ACPI / processor: Use common hotplug infrastructure ACPI / hotplug: Use device offline/online for graceful hot-removal Driver core: Use generic offline/online for CPU offline/online Driver core: Add offline/online device operations
| * | ACPI / processor: Use common hotplug infrastructureRafael J. Wysocki2013-05-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split the ACPI processor driver into two parts, one that is non-modular, resides in the ACPI core and handles the enumeration and hotplug of processors and one that implements the rest of the existing processor driver functionality. The non-modular part uses an ACPI scan handler object to enumerate processors on the basis of information provided by the ACPI namespace and to hook up with the common ACPI hotplug infrastructure. It also populates the ACPI handle of each processor device having a corresponding object in the ACPI namespace, which allows the driver proper to bind to those devices, and makes the driver bind to them if it is readily available (i.e. loaded) when the scan handler's .attach() routine is running. There are a few reasons to make this change. First, switching the ACPI processor driver to using the common ACPI hotplug infrastructure reduces code duplication and size considerably, even though a new file is created along with a header comment etc. Second, since the common hotplug code attempts to offline devices before starting the (non-reversible) removal procedure, it will abort (and possibly roll back) hot-remove operations involving processors if cpu_down() returns an error code for one of them instead of continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove is unset). That is a more desirable behavior than what the current code does. Finally, the separation of the scan/hotplug part from the driver proper makes it possible to simplify the driver's .remove() routine, because it doesn't need to worry about the possible cleanup related to processor removal any more (the scan/hotplug part is responsible for that now) and can handle device removal and driver removal symmetricaly (i.e. as appropriate). Some user-visible changes in sysfs are made (for example, the 'sysdev' link from the ACPI device node to the processor device's directory is gone and a 'physical_node' link is present instead and a corresponding 'firmware_node' is present in the processor device's directory, the processor driver is now visible under /sys/bus/cpu/drivers/ and bound to the processor device), but that shouldn't affect the functionality that users care about (frequency scaling, C-states and thermal management). Tested on my venerable Toshiba Portege R500. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Toshi Kani <toshi.kani@hp.com>
| * | ACPI / hotplug: Use device offline/online for graceful hot-removalRafael J. Wysocki2013-05-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify the generic ACPI hotplug code to be able to check if devices scheduled for hot-removal may be gracefully removed from the system using the device offline/online mechanism introduced previously. Namely, make acpi_scan_hot_remove() handling device hot-removal call device_offline() for all physical companions of the ACPI device nodes involved in the operation and check the results. If any of the device_offline() calls fails, the function will not progress to the removal phase (which cannot be aborted), unless its (new) force argument is set (in case of a failing offline it will put the devices offlined by it back online). In support of 'forced' device hot-removal, add a new sysfs attribute 'force_remove' that will reside under /sys/firmware/acpi/hotplug/. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com>
* | | ACPI / dock: Initialize ACPI dock subsystem upfrontJiang Liu2013-06-231-0/+5
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | dma: acpi-dma: parse CSRT to extract additional resourcesAndy Shevchenko2013-05-141-1/+0
|/ | | | | | | | | | 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 branch 'acpi-lpss'Rafael J. Wysocki2013-04-281-0/+8
|\ | | | | | | | | | | | | * 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
| * ACPI / scan: Add special handler for Intel Lynxpoint LPSS devicesRafael J. Wysocki2013-03-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Turquette <mturquette@linaro.org>
* | ACPI: Update PNPID set/free interfacesToshi Kani2013-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | This patch introduces acpi_set_pnp_ids() and acpi_free_pnp_ids(), which are updated from acpi_device_set_id() and acpi_free_ids(), to setup and free acpi_device_pnp for a given acpi_handle. They can be called without acpi_device. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: Make memory hotplug driver use struct acpi_scan_handlerRafael J. Wysocki2013-03-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ACPI memory hotplug driver use struct acpi_scan_handler for representing the object used to set up ACPI memory hotplug functionality and to remove hotplug memory ranges and data structures used by the driver before unregistering ACPI device nodes representing memory. Register the new struct acpi_scan_handler object with the help of acpi_scan_add_handler_with_hotplug() to allow user space to manipulate the attributes of the memory hotplug profile. This results in a significant reduction of the drvier's code size and removes some ACPI hotplug code duplication. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com>
* | ACPI / hotplug: Introduce user space interface for hotplug profilesRafael J. Wysocki2013-03-041-0/+6
|/ | | | | | | | | | | | | | | | | | | | | | Introduce user space interface for manipulating hotplug profiles associated with ACPI scan handlers. The interface consists of sysfs directories under /sys/firmware/acpi/hotplug/, one for each hotplug profile, containing an attribute allowing user space to manipulate the enabled field of the corresponding profile. Namely, switching the enabled attribute from '0' to '1' will cause the common hotplug notify handler to be installed for all ACPI namespace objects representing devices matching the scan handler associated with the given hotplug profile (and analogously for the converse switch). Drivers willing to use the new user space interface should add their ACPI scan handlers with the help of new funtion acpi_scan_add_handler_with_hotplug(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com>
* Merge tag 'pm+acpi-fixes-3.9-rc1' of ↵Linus Torvalds2013-02-251-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael Wysocki: - Fixes for blackfin and microblaze build problems introduced by the removal of global pm_idle. From Lars-Peter Clausen. - OPP core build fix from Shawn Guo. - Error condition check fix for the new imx6q-cpufreq driver from Wei Yongjun. - Fix for an AER driver crash related to the lack of APEI initialization for acpi=off. From Rafael J Wysocki. - Fix for a USB breakage on Thinkpad T430 related to ACPI power resources and PCI wakeup from Rafael J. Wysocki. * tag 'pm+acpi-fixes-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / PM: Take unusual configurations of power resources into account imx6q-cpufreq: fix return value check in imx6q_cpufreq_probe() PM / OPP: fix condition for empty of_init_opp_table() ACPI / APEI: Fix crash in apei_hest_parse() for acpi=off microblaze idle: Fix compile error blackfin idle: Fix compile error
| * Merge branch 'acpi-pm' into fixesRafael J. Wysocki2013-02-231-1/+1
| |\ | | | | | | | | | | | | * acpi-pm: ACPI / PM: Take unusual configurations of power resources into account
| | * ACPI / PM: Take unusual configurations of power resources into accountRafael J. Wysocki2013-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) moved the initial disabling of system wakeup for PCI devices into a place where it can actually work and that exposed a hidden old issue with crap^Wunusual system designs where the same power resources are used for both wakeup power and device power control at run time. Namely, say there is one power resource such that the ACPI power state D0 of a PCI device depends on that power resource (i.e. the device is in D0 when that power resource is "on") and it is used as a wakeup power resource for the same device. Then, calling acpi_pci_sleep_wake(pci_dev, false) for the device in question will cause the reference counter of that power resource to drop to 0, which in turn will cause it to be turned off. As a result, the device will go into D3cold at that point, although it should have stayed in D0. As it turns out, that happens to USB controllers on some laptops and USB becomes unusable on those machines as a result, which is a major regression from v3.8. To fix this problem, (1) increment the reference counters of wakup power resources during their initialization if they are "on" initially, (2) prevent acpi_disable_wakeup_device_power() from decrementing the reference counters of wakeup power resources that were not enabled for wakeup power previously, and (3) prevent acpi_enable_wakeup_device_power() from incrementing the reference counters of wakeup power resources that already are enabled for wakeup power. In addition to that, if it is impossible to determine the initial states of wakeup power resources, avoid enabling wakeup for devices whose wakeup power depends on those power resources. Reported-by: Dave Jones <davej@redhat.com> Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org> Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge tag 'pci-v3.9-changes' of ↵Linus Torvalds2013-02-251-0/+6
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI changes from Bjorn Helgaas: "Host bridge hotplug - Major overhaul of ACPI host bridge add/start (Rafael Wysocki, Yinghai Lu) - Major overhaul of PCI/ACPI binding (Rafael Wysocki, Yinghai Lu) - Split out ACPI host bridge and ACPI PCI device hotplug (Yinghai Lu) - Stop caching _PRT and make independent of bus numbers (Yinghai Lu) PCI device hotplug - Clean up cpqphp dead code (Sasha Levin) - Disable ARI unless device and upstream bridge support it (Yijing Wang) - Initialize all hot-added devices (not functions 0-7) (Yijing Wang) Power management - Don't touch ASPM if disabled (Joe Lawrence) - Fix ASPM link state management (Myron Stowe) Miscellaneous - Fix PCI_EXP_FLAGS accessor (Alex Williamson) - Disable Bus Master in pci_device_shutdown (Konstantin Khlebnikov) - Document hotplug resource and MPS parameters (Yijing Wang) - Add accessor for PCIe capabilities (Myron Stowe) - Drop pciehp suspend/resume messages (Paul Bolle) - Make pci_slot built-in only (not a module) (Jiang Liu) - Remove unused PCI/ACPI bind ops (Jiang Liu) - Removed used pci_root_bus (Bjorn Helgaas)" * tag 'pci-v3.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (51 commits) PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS ACPI / PCI: Make pci_slot built-in only, not a module PCI/PM: Clear state_saved during suspend PCI: Use atomic_inc_return() rather than atomic_add_return() PCI: Catch attempts to disable already-disabled devices PCI: Disable Bus Master unconditionally in pci_device_shutdown() PCI: acpiphp: Remove dead code for PCI host bridge hotplug PCI: acpiphp: Create companion ACPI devices before creating PCI devices PCI: Remove unused "rc" in virtfn_add_bus() PCI: pciehp: Drop suspend/resume ENTRY messages PCI/ASPM: Don't touch ASPM if forcibly disabled PCI/ASPM: Deallocate upstream link state even if device is not PCIe PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc PCI: Document hpiosize= and hpmemsize= resource reservation parameters PCI: Use PCI Express Capability accessor PCI: Introduce accessor to retrieve PCIe Capabilities Register PCI: Put pci_dev in device tree as early as possible PCI: Skip attaching driver in device_add() PCI: acpiphp: Keep driver loaded even if no slots found ...
| * | Merge branch 'pci/jiang-pci_slot-kconfig' into nextBjorn Helgaas2013-02-151-0/+5
| |\ \ | | | | | | | | | | | | | | | | * pci/jiang-pci_slot-kconfig: ACPI / PCI: Make pci_slot built-in only, not a module
| | * | ACPI / PCI: Make pci_slot built-in only, not a moduleJiang Liu2013-02-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in thread at https://patchwork.kernel.org/patch/1946851/, there's no value in supporting CONFIG_ACPI_PCI_SLOT=m any more. So change Kconfig and code to only support building pci_slot as built-in driver. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | | PCI: acpiphp: Move host bridge hotplug to pci_root.cYinghai Lu2013-01-251-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The acpiphp driver is confusing because it contains partial support for PCI host bridge hotplug as well as support for hotplug of PCI devices. This patch moves the host bridge hot-add support to pci_root.c and adds hot-remove support in pci_root.c. How to test it: if sci_emu patch is applied, find out root bus number to ACPI root name mapping from dmesg or /sys. To remove root bus: echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify To add back root bus: echo "\_SB.PCIB 1" > /sys/kernel/debug/acpi/sci_notify Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | ACPI / scan: Make container driver use struct acpi_scan_handlerRafael J. Wysocki2013-02-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ACPI container driver use struct acpi_scan_handler for representing the object used to initialize ACPI containers and remove the ACPI driver structure used previously and the data structures created by it, since in fact they were not used for any purpose. This simplifies the code and reduces the kernel's memory footprint by avoiding the registration of a struct device_driver object with the driver core and creation of its sysfs directory which is unnecessary. In addition to that, make the namespace walk callback used for installing the notify handlers for ACPI containers more straightforward. This change includes fixes from Toshi Kani. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com>
* | | ACPI / platform: Use struct acpi_scan_handler for creating devicesRafael J. Wysocki2013-01-301-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the ACPI namespace scanning code creates platform device objects for ACPI device nodes whose IDs match the contents of the acpi_platform_device_ids[] table. However, this adds a superfluous special case into acpi_bus_device_attach() and makes it more difficult to follow than it has to be. It also will make it more difficult to implement removal code for those platform device objects in the future. For the above reasons, introduce a struct acpi_scan_handler object for creating platform devices and move the code related to that from acpi_bus_device_attach() to the .attach() callback of that object. Also move the acpi_platform_device_ids[] table to acpi_platform.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | | ACPI / PCI: Make PCI IRQ link driver use struct acpi_scan_handlerRafael J. Wysocki2013-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ACPI PCI IRQ link driver use struct acpi_scan_handler for representing the object used to set up ACPI interrupt links and to remove data structures used for this purpose before unregistering the corresponding ACPI device nodes. This simplifies the code slightly and reduces the kernel's memory footprint by avoiding the registration of a struct device_driver object with the driver core and creation of its sysfs directory which is unnecessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | | ACPI / PCI: Make PCI root driver use struct acpi_scan_handlerRafael J. Wysocki2013-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ACPI PCI root bridge driver use struct acpi_scan_handler for representing the object used to enumerate the PCI busses under PCI host bridges found in the ACPI namespace (and to tear down data structures representing the bus and devices on it before unregistering the host bridges' ACPI device nodes). This simplifies the code slightly and reduces the kernel's memory footprint by avoiding the registration of a struct device_driver object with the driver core and creation of its sysfs directory which is unnecessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | | Merge branch 'acpi-lpss' into acpi-cleanupRafael J. Wysocki2013-01-291-1/+6
|\ \ \ | |_|/ |/| | | | | The following commits depend on the 'acpi-lpss' material.
| * | ACPI / platform: create LPSS clocks if Lynxpoint devices are found during scanMika Westerberg2013-01-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel Lynxpoint LPSS peripheral drivers depend on LPSS clock tree being created in order to function properly. The clock tree is exposed as a platform driver that binds to a device named 'clk-lpt'. To support this we modify the acpi_create_platform_device() to take one additional parameter called flags. This is passed from acpi_platform_device_ids[] array when acpi_create_platform_device() is called. We then introduce a new flag ACPI_PLATFORM_CLK which is used to tell acpi_create_platform_device() to create the platform clocks as well. Finally we set the ACPI_PLATFORM_CLK flags for all the Lynxpoint LPSS devices and make sure that when this flag is set we create the corresponding clock tree platform device. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI: add support for CSRT tableMika Westerberg2013-01-191-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Core System Resources Table (CSRT) is a proprietary ACPI table that contains resources for certain devices that are not found in the DSDT table. Typically a shared DMA controller might be found here. This patch adds support for this table. We go through all entries in the table and make platform devices of them. The resources from the table are passed with the platform device. There is one special resource in the table and it is the DMA request line base and number of request lines. This information might be needed by the DMA controller driver as it needs to map the ACPI DMA request line number to the actual request line understood by the hardware. This range is passed as IORESOURCE_DMA resource. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: Prevent device add uevents from racing with user spaceRafael J. Wysocki2013-01-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI core adds sysfs device files after the given devices have been registered with device_register(), which is not appropriate, because it may lead to race conditions with user space tools using those files. Fix the problem by delaying the KOBJ_ADD uevent for ACPI devices until after all of the devices' sysfs files have been created. This also fixes a use-after-free in acpi_device_unregister(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | ACPI / PM: Move device power management functions to device_pm.cRafael J. Wysocki2013-01-191-1/+0
| | | | | | | | | | | | | | Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Use system level attribute of wakeup power resourcesRafael J. Wysocki2013-01-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The system level attribute of ACPI power resources is the lowest system sleep level (S0, S2 etc.) in which the given resource can be "on" (ACPI 5.0, Section 7.1). On the other hand, wakeup power resources have to be "on" for devices depending on them to be able to signal wakeup. Therefore devices cannot wake up the system from sleep states higher than the minimum of the system level attributes of their wakeup power resources. Use the wakeup power resources' system level values to get the deepest system sleep state (highest system sleep level) the given device can wake up the system from. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Take power resource initialization errors into accountRafael J. Wysocki2013-01-171-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Some ACPI power resource initialization errors, like memory allocation errors, are not taken into account appropriately in some cases, which may lead to a device having an incomplete list of power resources that one of its power states depends on, for one example. Rework the power resource initialization and namespace scanning code so that power resource initialization errors are treated more seriously. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: Consolidate extraction of power resources listsRafael J. Wysocki2013-01-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The lists of ACPI power resources are currently extracted in two different ways, one for wakeup power resources and one for power resources that device power states depend on. There is no reason why it should be done differently in those two cases, so introduce a common routine for extracting power resources lists from data returned by AML, acpi_extract_power_resources(), and make the namespace scanning code use it for both wakeup and device power states power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PM: Take order attribute of power resources into accountRafael J. Wysocki2013-01-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of power resources that power states of devices depend on (analogous changes will be done separately for power resources used for wakeup). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: Treat power resources in a special wayRafael J. Wysocki2013-01-171-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI power resources need to be treated in a special way by the namespace scanning code, because they need to be ready to use as soon as they have been discovered (even before registering ACPI device nodes using them for power management). For this reason, it doesn't make sense to separate the preparation of struct acpi_device objects representing them in the device hierarchy from the creation of struct acpi_power_resource objects actually used for power resource manipulation. Accordingly, it doesn't make sense to define non-empty .add() and .remove() callbacks in the power resources "driver" (in fact, it is questionable whether or not it is useful to register such a "driver" at all). Rearrange the code in scan.c and power.c so that power resources are initialized entirely by one routine, acpi_add_power_resource(), that also prepares their struct acpi_device objects and registers them with the driver core, telling it to use a special release routine, acpi_release_power_resource(), for removing objects that represent power resources from memory. Make the ACPI namespace scanning code in scan.c always use acpi_add_power_resource() for preparing and registering objects that represent power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / PM: Rework the handling of devices depending on power resourcesRafael J. Wysocki2013-01-171-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Change the ordering of PCI root bridge driver registrarionRafael J. Wysocki2013-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of running acpi_pci_root_init() from a separate subsys initcall, call it directly from acpi_scan_init() before scanning the ACPI namespace for the first time, so that the PCI root bridge driver's .add() routine, acpi_pci_root_start(), is always run before binding ACPI drivers or attaching "companion" device objects to struct acpi_device objects below the root bridge's device node in the ACPI namespace. The first, simpler reason for doing this is that it makes the situation during boot more similar to the situation during hotplug, in which the ACPI PCI root bridge driver is always present. The second reason is that acpi_pci_root_init() causes struct pci_dev objects to be created for all PCI devices below the bridge and these objects may be necessary for whatever is done with the other ACPI device nodes in that namespace scope. For example, devices created by acpi_create_platform_device() sometimes may need to be added to the device hierarchy as children of PCI bridges. For this purpose, however, the struct pci_dev objects representing those bridges need to exist before the platform devices in question are registered. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
* Merge branch 'acpi-general'Rafael J. Wysocki2012-11-291-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-general: (38 commits) ACPI / thermal: _TMP and _CRT/_HOT/_PSV/_ACx dependency fix ACPI: drop unnecessary local variable from acpi_system_write_wakeup_device() ACPI: Fix logging when no pci_irq is allocated ACPI: Update Dock hotplug error messages ACPI: Update Container hotplug error messages ACPI: Update Memory hotplug error messages ACPI: Update CPU hotplug error messages ACPI: Add acpi_handle_<level>() interfaces ACPI: remove use of __devexit ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. ACPI / battery: Correct battery capacity values on Thinkpads Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info" ACPI: create _SUN sysfs file ACPI / memhotplug: bind the memory device when the driver is being loaded ACPI / memhotplug: don't allow to eject the memory device if it is being used ACPI / memhotplug: free memory device if acpi_memory_enable_device() failed ACPI / memhotplug: fix memory leak when memory device is unbound from acpi_memhotplug ACPI / memhotplug: deal with eject request in hotplug queue ACPI / memory-hotplug: add memory offline code to acpi_memory_device_remove() ACPI / memory-hotplug: call acpi_bus_trim() to remove memory device ... Conflicts: include/linux/acpi.h (two additions at the end of the same file)
| * ACPI / EC: Cleanup the member name for spinlock/mutex in structFeng Tang2012-11-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current member names for mutex/spinlock are a little confusing. Change the { struct mutex lock; spinlock_t curr_lock; } to { struct mutex mutex; spinlock_t lock; } So that the code is cleaner and easier to read. Signed-off-by: Feng Tang <feng.tang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Add support for platform bus typeMika Westerberg2012-11-151-0/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | With ACPI 5 it is now possible to enumerate traditional SoC peripherals, like serial bus controllers and slave devices behind them. These devices are typically based on IP-blocks used in many existing SoC platforms and platform drivers for them may already be present in the kernel tree. To make driver "porting" more straightforward, add ACPI support to the platform bus type. Instead of writing ACPI "glue" drivers for the existing platform drivers, register the platform bus type with ACPI to create platform device objects for the drivers and bind the corresponding ACPI handles to those platform devices. This should allow us to reuse the existing platform drivers for the devices in question with the minimum amount of modifications. This changeset is based on Mika Westerberg's and Mathias Nyman's work. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: H. Peter Anvin <hpa@zytor.com> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Cleanup custom_method debug stuffThomas Renninger2011-05-291-1/+2
| | | | | | | | | | | - Move param aml_debug_output to other params into sysfs.c - Split acpi_debugfs_init to prepare custom_method to be an own .config option and driver. Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: rui.zhang@intel.com Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: Remove the unused EC sysdev classRafael J. Wysocki2011-03-181-3/+0
| | | | | | | | The ACPI EC driver defines a sysdev class, but it doesn't use it, so it can be removed. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
OpenPOWER on IntegriCloud