- 21 1月, 2012 2 次提交
-
-
由 Myron Stowe 提交于
This patch adds support for RAM to ACPI's mapping capabilities in order to support APEI error injection (EINJ) actions. This patch re-factors similar functionality introduced in commit 76da3fb3, bringing it into osl.c in preparation for removing ./drivers/acpi/atomicio.[ch]. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
Base ACPI (CA) currently does not support atomic 64-bit reads and writes (acpi_read() and acpi_write() split 64-bit loads/stores into two 32-bit transfers) yet APEI expects 64-bit transfer capability, even when running on 32-bit systems. This patch implements 64-bit read and write routines for APEI usage. This patch re-factors similar functionality introduced in commit 04c25997, bringing it into the ACPI subsystem in preparation for removing ./drivers/acpi/atomicio.[ch]. In the implementation I have replicated acpi_os_read_memory() and acpi_os_write_memory(), creating 64-bit versions for APEI to utilize, as opposed to something more elegant. My thinking is that we should attempt to see if we can get ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write() interfaces are natively 64-bit capable and then subsequently remove the replication. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 1月, 2012 3 次提交
-
-
由 Myron Stowe 提交于
Export remapping and unmapping interfaces - acpi_os_map_generic_address() and acpi_os_unmap_generic_address() - for ACPI generic registers that are backed by memory mapped I/O (MMIO). The acpi_os_map_generic_address() and acpi_os_unmap_generic_address() declarations may more properly belong in include/acpi/acpiosxf.h next to acpi_os_read_memory() but I believe that would require the ACPI CA making them an official part of the ACPI CA - OS interface. ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic hardware registers use the GAS format): ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address Structure" Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
Generic Address Structures (GAS) may reside within ACPI tables which are byte aligned. This patch copies GAS 'address' references to a local variable, which will be naturally aligned, to be used going forward. ACPI Generic Address Structure (GAS) reference: ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address Structure" Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
Allows drivers to determine if any memory or I/O addresses will conflict with addresses used by ACPI operation regions. Introduces a new interface, acpi_check_address_range. http://marc.info/?t=132251388700002&r=1&w=2Reported-and-tested-by: NLuca Tettamanti <kronos.it@gmail.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 15 10月, 2011 1 次提交
-
-
由 Prarit Bhargava 提交于
I originally submitted a patch to workaround this by pushing all Ejection Requests and Device Checks onto the kacpi_hotplug queue. http://marc.info/?l=linux-acpi&m=131678270930105&w=2 The patch is still insufficient in that Bus Checks also need to be added. Rather than add all events, including non-PCI-hotplug events, to the hotplug queue, mjg suggested that a better approach would be to modify the acpiphp driver so only acpiphp events would be added to the kacpi_hotplug queue. It's a longer patch, but at least we maintain the benefit of having separate queues in ACPI. This, of course, is still only a workaround the problem. As Bjorn and mjg pointed out, we have to refactor a lot of this code to do the right thing but at this point it is a better to have this code working. The acpi core places all events on the kacpi_notify queue. When the acpiphp driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the following call sequence occurs: cleanup_p2p_bridge() -> cleanup_bridge() -> acpi_remove_notify_handler() -> acpi_os_wait_events_complete() -> flush_workqueue(kacpi_notify_wq) which is the queue we are currently executing on and the process will hang. Move all hotplug acpiphp events onto the kacpi_hotplug workqueue. In handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply push the rest of the work onto the kacpi_hotplug queue and then avoid the deadlock. Signed-off-by: NPrarit Bhargava <prarit@redhat.com> Cc: mjg@redhat.com Cc: bhelgaas@google.com Cc: linux-acpi@vger.kernel.org Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 03 8月, 2011 1 次提交
-
-
由 Shaohua Li 提交于
Linux supports some optional features, but it should notify the BIOS about them via the _OSI method. Currently Linux doesn't notify any, which might make such features not work because the BIOS doesn't know about them. Jarosz has a system which needs this to make ACPI processor aggregator device work. Reported-by: N"Jarosz, Sebastian" <sebastian.jarosz@intel.com> Signed-off-by: NShaohua Li <shaohua.li@intel.com> Acked-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 02 8月, 2011 1 次提交
-
-
由 Len Brown 提交于
This message gets repeated on some machines: https://bugzilla.kernel.org/show_bug.cgi?id=29292Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 7月, 2011 1 次提交
-
-
由 Takao Indoh 提交于
There is a problem with putting the first kernel in EFI virtual mode, it is that when the second kernel comes up it tries to initialize the EFI again and once we have put EFI in virtual mode we can not really do that. Actually, EFI is not necessary for kdump, we can boot the second kernel with "noefi" parameter, but the boot will mostly fail because 2nd kernel cannot find RSDP. In this situation, we introduced "acpi_rsdp=" kernel parameter, so that kexec-tools can pass the "noefi acpi_rsdp=X" to the second kernel to make kdump works. The physical address of the RSDP can be got from sysfs(/sys/firmware/efi/systab). Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com> Reviewed-by: NWANG Cong <amwang@redhat.com> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 7月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
All ACPICA locks are allocated by the same function, acpi_os_create_lock(), with the help of a local variable called "lock". Thus, when lockdep is enabled, it uses "lock" as the name of all those locks and regards them as instances of the same lock, which causes it to report possible locking problems with them when there aren't any. To work around this problem, define acpi_os_create_lock() as a macro and make it pass its argument to spin_lock_init(), so that lockdep uses it as the name of the new lock. Define this macron in a Linux-specific file, to minimize the resulting modifications of the OS-independent ACPICA parts. This change is based on an earlier patch from Andrea Righi and it addresses a regression from 2.6.39 tracked as https://bugzilla.kernel.org/show_bug.cgi?id=38152Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NBorislav Petkov <bp@alien8.de> Tested-by: NAndrea Righi <andrea@betterlinux.com> Reviewed-by: NFlorian Mickler <florian@mickler.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 3月, 2011 1 次提交
-
-
由 Lin Ming 提交于
Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 2月, 2011 7 次提交
-
-
由 Rafael J. Wysocki 提交于
In principle acpi_os_install_interrupt_handler() may be called multiple times for different interrupts, either from acpi_ev_get_gpe_xrupt_block(), or from acpi_ev_install_sci_handler(). However, it always attempts to request the same interrupt, acpi_gbl_FADT.sci_interrupt and it doesn't check whether or not this interrupt has already been requested. Modify this function so that it refuses to request interrupts other than acpi_gbl_FADT.sci_interrupt and change acpi_os_remove_interrupt_handler() so that it refuses to free such interrupts. Use the observation that the only supported ACPI interrupt must be equal to acpi_gbl_FADT.sci_interrupt and drop an unnecessary variable acpi_irq_irq. This change has been tested on Toshiba Portege R500 and HP nx6325 without introducing any visible problems. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Introduce function acpi_os_get_iomem() that may be used by its callers to get a reference to an ACPI iomap. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The reference counting of ACPI iomaps is carried out entirely under acpi_ioremap_lock, so it is sufficient to use simple counters instead of krefs for this purpose. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Modify acpi_os_map_memory() so that it doesn't call acpi_os_ioremap() unconditionally every time it is executed (except when acpi_gbl_permanent_mmap is unset), which pretty much defeats the purpose of maintaining the list of ACPI iomaps in osl.c. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
Make acpi_os_unmap_generic_address() use acpi_map_lookup() to find the desired iomap and drop the reference to it directly (and eventually remove it if necessary) instead of calling acpi_os_unmap_memory(), which requires us to walk the list of ACPI iomaps twice in a row (first, to get the virtual address associated with the iomap and second, to get the iomap itself). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
There's no reason why acpi_ioremap_lock has to be a spinlock, because all of the functions it is used in may sleep anyway and there's no reason why it should be locked with interrupts off. Use a mutex instead (that's going to allow us to put some more operations under the lock later). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Rafael J. Wysocki 提交于
The functions acpi_os_map_generic_address() and acpi_os_unmap_generic_address() are only used in drivers/acpi/osl.c, so make them static and remove the extern definitions of them from include/linux/acpi_io.h. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 09 2月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The functions acpi_os_read_memory() and acpi_os_write_memory() do two wrong things. First, they shouldn't call rcu_read_unlock() before the looked up address is actually used for I/O, because in that case the iomap it belongs to may be removed before the I/O is done. Second, if they have to create a new mapping, they should check the returned virtual address and tell the caller that the operation failed if it is NULL (in fact, I think they even should not attempt to map an address that's not present in one of the existing ACPI iomaps, because that may cause problems to happen when they are called from nonpreemptible context and their callers ought to know what they are doing and map the requisite memory regions beforehand). Make these functions call rcu_read_unlock() when the I/O is complete (or if it's necessary to map the given address "on the fly") and return an error code if the requested physical address is not present in the existing ACPI iomaps and cannot be mapped. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 01 2月, 2011 1 次提交
-
-
由 Tejun Heo 提交于
ACPI workqueues aren't used during memory reclaming. Use alloc_workqueue() to create workqueues w/o rescuers. If the purpose of the separation between kacpid_wq and kacpi_notify_wq was to give notifications better response time, kacpi_notify_wq can be dropped and kacpi_wq can be created with higher @max_active. Signed-off-by: NTejun Heo <tj@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: linux-acpi@vger.kernel.org
-
- 21 1月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit ca9b600b ("ACPI / PM: Make suspend_nvs_save() use acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c from using different ioremap() variants by making the latter use acpi_os_map_memory() for mapping the NVS pages. However, that also requires acpi_os_unmap_memory() to be used for unmapping them, which causes synchronize_rcu() to be executed many times in a row unnecessarily and introduces substantial delays during resume on some systems. Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c introduce acpi_os_ioremap() calling ioremap_cache() and make the code in both osl.c and nvs.c use it. Reported-by: NJeff Chua <jeff.chua.linux@gmail.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 1月, 2011 1 次提交
-
-
由 Thomas Renninger 提交于
printk("%pR",...) is for formatting struct resource only. But the list built up in drivers/acpi/osl.c uses it's own struct: struct acpi_res_list {} Without this patch you can see wrongly formatted resources (SMRG is of IO type): ACPI: resource 0000:00:1f.3 [io 0x0400-0x041f] conflicts with AC PI region SMRG [mem 0x00000400-0x0000040f 64bit pref disabled] https://bugzilla.kernel.org/show_bug.cgi?id=26342Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Matthew Wilcox <matthew@wil.cx> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 1月, 2011 1 次提交
-
-
由 Len Brown 提交于
Although the temporary boot-time ACPI table mappings were set up with CPU caching enabled, the permanent table mappings and AML run-time region memory accesses were set up with ioremap(), which on x86 is a synonym for ioremap_nocache(). Changing this to ioremap_cache() improves performance as seen when accessing the tables via acpidump, or /sys/firmware/acpi/tables. It should also improve AML run-time performance. No change on ia64. Reported-by: NJack Steiner <steiner@sgi.com> Signed-off-by: NLen Brown <len.brown@intel.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 11 12月, 2010 3 次提交
-
-
由 Zhang Rui 提交于
WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux() The function acpi_os_initialize1() references the function __init set_osi_linux(). Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor) introduced another regression that only one _OSI string can be added or removed. Now multiple _OSI strings can be added or removed, for example acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006" Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor) introduced a regression that _OSI string setup fails. There are 2 paths to setup _OSI string. DMI: acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI string to osi_setup_string Boot command line: acpi_osi_setup -> copy _OSI string to osi_setup_string Later, acpi_osi_setup_late will be called to handle osi_setup_string. If _OSI string is "Linux" or "!Linux", then the call path is, acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI string to osi_setup_string This actually never installs _OSI string(acpi_install_interface not called), but just copy the _OSI string to osi_setup_string. This patch fixes the regression. Reported-and-tested-by: NLukas Hejtmanek <xhejtman@ics.muni.cz> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 10月, 2010 6 次提交
-
-
由 Myron Stowe 提交于
This patch optimizes ACPI MMIO remappings by keeping track of the remappings on a PAGE_SIZE granularity. When an ioremap() occurs, the underlying infrastructure works on a 'page' based granularity. As such, an ioremap() request for 1 byte for example, will end up mapping in an entire (PAGE_SIZE) page. Huang Ying took advantage of this in commit 15651291 by checking if subsequent ioremap() requests reside within any of the list's existing remappings still in place, and if so, incrementing a reference count on the existing mapping as opposed to performing another ioremap(). Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
Convert the simple locking introduced earlier for the ACPI MMIO remappings list to an RCU based locking scheme. Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
During ACPI initialization, pre-map fixed hardware registers that are accessed during ACPI's 'system event' related IRQ handing. ACPI's 'system event' handing accesses specific fixed hardware registers; namely PM1a event, PM1b event, GPE0, and GPE1 register blocks which are declared within the FADT. If these registers are backed by MMIO, as opposed to I/O port space, accessing them within interrupt context will cause a panic as acpi_os_read_memory() depends on ioremap() in such cases - BZ 18012. By utilizing the functionality provided in the previous two patches - ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI: Add interfaces for ioremapping/iounmapping ACPI registers - accesses to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ and/or NMI) provided the area was pre-mapped. This solves BZ 18012. ACPI "System Event" reference(s): ACPI Specification, Revision 4.0, Section 3 "ACPI Overview", 3.8 "System Events", 5.6 "ACPI Event Programming Model". Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012 Reported-by: <bjorn.helgaas@hp.com> Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
Add remapping and unmapping interfaces for ACPI registers that are backed by memory mapped I/O (MMIO). These interfaces, along with the MMIO remapping list, enable accesses of such registers from within interrupt context. ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic hardware registers use the GAS format): ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address Structure". Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
For memory mapped I/O (MMIO) remappings, add a list to maintain the remappings and augment the corresponding mapping and unmapping interface routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to dynamically add to, and delete from, the list. The current ACPI I/O accessing methods - acpi_read() and acpi_write() - end up calling ioremap() when accessing MMIO. This prevents use of these methods within interrupt context (IRQ and/or NMI), since ioremap() may block to allocate memory. Maintaining a list of MMIO remappings enables accesses to such areas from within interrupt context provided they have been pre-mapped. Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Myron Stowe 提交于
The size used for I/O remapping MMIO read and write accesses has not accounted for the basis of ACPI's Generic Address Structure (GAS) 'Register Bit Width' field which is bits, not bytes. This patch adjusts the ioremap() 'size' argument accordingly. ACPI "Generic Register" reference: ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address Structure". Signed-off-by: NMyron Stowe <myron.stowe@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 10月, 2010 1 次提交
-
-
由 Stephen Hemminger 提交于
Found by running make namespacecheck on linux-next Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 10月, 2010 1 次提交
-
-
由 Len Brown 提交于
Linux-2.6.22 initiated a dmesg complaint when it saw BIOS that invoked OSI(Linux). Linux-2.6.23 continued that complaint and started our policy of ignoring the bogus BIOS request. Past-time for Linux to label that complaint with FW_BUG. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 01 10月, 2010 3 次提交
-
-
由 Bob Moore 提交于
This function is not OS-dependent and has been replaced by acpi_hw_derive_pci_id, which is now in the ACPICA core code. Local implementations of acpi_os_derive_pci_id are no longer necessary and are removed. ACPICA BZ 857. http://www.acpica.org/bugzilla/show_bug.cgi?id=857Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
Adds install/remove interfaces so that the host can dynamically alter the global _OSI table. Also adds support for _OSI handlers. Additional support: new debugger command (osi), and test support in the acpiexec utility. Adds new file, utilities/utosi.c. ACPICA bugzilla 836. The Linux OSL _OSI code is also changed. acpi_osi_setup can't call acpi_install/remove_interface because ACPICA is not initialized yet at this early time. So we just save the osi string in acpi_osi_setup and will handle it later in a new function acpi_osi_setup_late. http://www.acpica.org/bugzilla/show_bug.cgi?id=836Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bob Moore 提交于
Prototype in acpiosxf.h had the output value pointer as a (u32 *). Should be a (u64 *). Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 15 8月, 2010 1 次提交
-
-
由 Andi Kleen 提交于
Some minor improvements in error handling, but overall it was mostly dead code. Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 13 7月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, during initialization ACPICA walks the entire ACPI namespace in search of any device objects with assciated _PRW methods. All of the _PRW methods found are executed in the process to extract the GPE information returned by them, so that the GPEs in question can be marked as "able to wakeup" (more precisely, the ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this exercise is to avoid enabling the CAN_WAKE GPEs automatically, even if there are _Lxx/_Exx methods associated with them. However, it is both costly and unnecessary, because the host OS has to execute the _PRW methods anyway to check which devices can wake up the system from sleep states. Moreover, it then uses full information returned by _PRW, including the GPE information, so it can take care of disabling the GPEs if necessary. Remove the code that walks the namespace and executes _PRW from ACPICA and modify comments to reflect that change. Make acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices so that they don't cause spurious wakeup events to be signaled. This not only reduces the complexity of the ACPICA initialization code, but in some cases it should reduce the kernel boot time as well. Unfortunately, for this purpose we need a new ACPICA function, acpi_gpe_can_wake(), to be called by the host OS in order to disable the GPEs that can wake up the system and were previously enabled by acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE should be disabled only once, because the initialization code enables it only once, but it may be pointed to by _PRW for multiple devices and that's why the additional function is necessary). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 6月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
ACPI works need to be executed on cpu0 and acpi/osl.c achieves this by creating singlethread workqueue and then binding it to cpu0 from a work which is quite unorthodox. Make it create regular workqueues and use queue_work_on() instead. This is in preparation of concurrency managed workqueue and the extra workers won't be a problem after it's implemented. Signed-off-by: NTejun Heo <tj@kernel.org>
-