- 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>
-
- 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>
-
- 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>
-
- 28 5月, 2010 1 次提交
-
-
由 Jean Delvare 提交于
When the user passes the kernel parameter acpi_enforce_resources=lax, the ACPI resources are no longer protected, so a native driver can make use of them. In that case, we do not want the asus_atk0110 to be loaded. Unfortunately, this driver loads automatically due to its MODULE_DEVICE_TABLE, so the user ends up with two drivers loaded for the same device - this is bad. So I suggest that we prevent the asus_atk0110 driver from loading if acpi_enforce_resources=lax. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NLuca Tettamanti <kronos.it@gmail.com> Cc: Len Brown <lenb@kernel.org>
-
- 05 4月, 2010 1 次提交
-
-
由 Chase Douglas 提交于
By default, ACPI resource conflict messages are logged at level KERN_ERR. This is a rather high level for a message that is more a warning than an indication of a real kernel error. Also, KERN_ERR level messages can appear over some boot splash screens, and this message is not serious enough to warrant such treatment. Thus, the log level has been reduced to KERN_WARNING. [lenb changed to KERN_WARNING rather than all the way to KERN_INFO] Also, cleanup message to use %pR resource printing format. Signed-off-by: NChase Douglas <chase.douglas@canonical.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 3月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
fixes a false alarm from lockdep, as acpi hotplug workqueue waits other workqueues. http://bugzilla.kernel.org/show_bug.cgi?id=14553 https://bugzilla.kernel.org/show_bug.cgi?id=15521 Original-patch-from: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NShaohua Li <shaohua.li@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 3月, 2010 1 次提交
-
-
由 Thomas Weber 提交于
[Ss]ytem => [Ss]ystem udpate => update paramters => parameters orginal => original Signed-off-by: NThomas Weber <swirl@gmx.li> Acked-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 28 1月, 2010 1 次提交
-
-
由 Lin Ming 提交于
acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 12月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
acpi_check_resource_conflict() doesn't change the resource it operates on, so the res parameter can be marked const. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 27 9月, 2009 1 次提交
-
-
由 Jean Delvare 提交于
The message "ACPI: Device needs an ACPI driver" is misleading. The device _may_ need an ACPI driver, if the BIOS implemented a custom API for the device in question (which, AFAIK, can't be checked.) If not, then either a generic ACPI driver may be used (for example "thermal"), or nothing can be done (other than a white list). I propose to reword the message to: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver which I think is more correct. Comments and suggestions welcome. I also added a message warning about possible problems and system instability when users pass acpi_enforce_resources=lax, as suggested by Len. Signed-off-by: NJean Delvare <jdelvare@suse.de> Cc: Thomas Renninger <trenn@suse.de> Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 24 9月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
set_cpus_allowed() is on the way out; replace it with set_cpus_allowed_ptr(). Reference: http://lkml.org/lkml/2008/11/6/448Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 19 9月, 2009 2 次提交
-
-
由 Bjorn Helgaas 提交于
Better to oops and learn about a bug than to silently cover it up. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
We had two functions, acpi_os_execute_deferred() and acpi_os_execute_hp_deferred() that differed only in that the latter did acpi_os_wait_events_complete(NULL) before executing the deferred function. This patch consolidates those two functions and uses a flag in the struct acpi_os_dpc to determine whether to do the wait. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 8月, 2009 1 次提交
-
-
由 Lin Ming 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=13620 If the dynamic region is created and added to resource list over and over again, it has the potential to be a memory leak by growing the list every time. This patch fixes the memory leak, as below 1) add a new field "count" to struct acpi_res_list. When inserting, if the region(addr, len) is already in the resource list, we just increase "count", otherwise, the region is inserted with count=1. When deleting, the "count" is decreased, if it's decreased to 0, the region is deleted from the resource list. With "count", the region with same address and length can only be inserted to the resource list once, so prevent potential memory leak. 2) add a new function acpi_os_invalidate_address, which is called when region is deleted. Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 03 8月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
On some machines, a software-initiated SMI causes corruption unless the SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's done in GPE-related methods that are run via workqueues, so we can avoid the known corruption cases by binding the workqueues to CPU 0. References: http://bugzilla.kernel.org/show_bug.cgi?id=13751 https://bugs.launchpad.net/bugs/157171 https://bugs.launchpad.net/bugs/157691Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 24 6月, 2009 1 次提交
-
-
由 Zhang Rui 提交于
we used to run the hotplug code in keventd_wq. But when hot removing the ACPI battery device, power_supply_unregister invokes flush_scheduled_work. This causes a deadlock. i.e 1. When dock is unplugged, all the hotplug code is run on kevent_wq. 2. the hotplug code removes all the child devices of dock device. 3. removing the child device may invoke flush_scheduled_work 4. flush_scheduled_work waits until all the work on kevent_wq to be finished, while this will never be true because the hotplug code is running on keventd_wq... Introduce a new workqueue for hotplug in this patch. http://bugzilla.kernel.org/show_bug.cgi?id=13533Tested-by: NPaul Martin <pm@debian.org> Tested-by: NVojtech Gondzala <vojtech.gondzala@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 4月, 2009 1 次提交
-
-
由 Len Brown 提交于
This counter may prove useful in debugging some spurious interrupt issues seen in the field. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 03 4月, 2009 1 次提交
-
-
由 Luca Tettamanti 提交于
Enforce strict resource checking - disallowing access by native drivers to IO ports and memory regions claimed by ACPI firmware. The patch is mainly aimed to block native hwmon drivers from touching monitoring chips that ACPI thinks it own. If this causes a regression, boot with "acpi_enforce_resources=lax" which was the previous default. http://bugzilla.kernel.org/show_bug.cgi?id=12376 http://bugzilla.kernel.org/show_bug.cgi?id=12541Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com> Acked-by: NPavel Machek <pavel@suse.cz> Acked-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 3月, 2009 1 次提交
-
-
由 Len Brown 提交于
This reverts commit 5ec5d38a. because it caused spurious dmesg warmings. We'll implement the check for off-limit ports in a more clever way in the future. http://bugzilla.kernel.org/show_bug.cgi?id=12758Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 2月, 2009 1 次提交
-
-
由 Jeremy Fitzhardinge 提交于
early_acpi_os_unmap_memory() is an __init function, and acpi_os_unmap_memory() is allowed to access an __init function until acpi_gbl_permanent_mmap is set up. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 09 2月, 2009 1 次提交
-
-
由 Yinghai Lu 提交于
to prevent wrongly overwriting fixmap that still want to use. ACPI used to rely on low mappings being all linearly mapped and grew a habit: it never really unmapped certain kinds of tables after use. This can cause problems - for example the hypothetical case when some spurious access still references it. v2: remove prev_map and prev_size in __apci_map_table v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to early_acpi_os_unmap_memory v4: fix typo in one acpi_get_table_with_size calling Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Acked-by: NLen Brown <len.brown@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-