- 12 1月, 2011 9 次提交
-
-
由 Rafael J. Wysocki 提交于
Use the new function acpi_bus_update_power() for manipulating power resources used by ACPI fan devices, which allows them to be put into the right state during initialization and resume. Consequently, remove the flags.force_power_state field from struct acpi_device, which is not necessary any more. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Depending on the organization of the ACPI namespace, power resource device objects may generally be scanned after the "regular" device objects that they are referred from through _PRn. This, in turn, may cause acpi_bus_get_power_flags() to attempt to access them through acpi_bus_init_power() before they are registered (and initialized by acpi_power_driver). [This is not a theoretical issue, it actually happens for one PnP device on my testbed HP nx6325.] To fix this problem, make acpi_bus_get_power_flags() attempt to register power resource devices as soon as they have been found in the _PRn output for any other devices. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
The ACPI device driver used for handling power resources, acpi_power_driver, creates a struct acpi_power_resource object for each ACPI device representing a power resource. These objects are then used when setting and reading the power states of devices using the corresponding power resources. Unfortunately, acpi_power_driver is registered after acpi_scan_init() that may add devices using the power resources before acpi_power_driver has a chance to create struct acpi_power_resource objects for them (specifically, the power resources may be referred to during the scanning process through acpi_bus_get_power() before they have been initialized). As the first step towards fixing this issue, move the registration of acpi_power_driver into acpi_scan_init() so that power resource devices can be initialized by it as soon as they have been found in the namespace. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Add function acpi_bus_update_power() for reading the actual power state of an ACPI device and updating its device->power.state field in such a way that its power resources' reference counters will remain consistent with that field. For this purpose introduce __acpi_bus_set_power() setting the power state of an ACPI device without updating its device->power.state field and make acpi_bus_set_power() and acpi_bus_update_power() use it (acpi_bus_set_power() retains the current behavior for now). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Add function acpi_bus_init_power() for getting the initial power state of an ACPI device and reference counting its power resources as appropriate. Make acpi_bus_get_power_flags() use the new function instead of acpi_bus_get_power() that updates device->power.state without reference counting the device's power resources. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
It sometimes is necessary to get the power state of an ACPI device without updating its device->power.state field, for example to avoid inconsistencies between device->power.state and the reference counters of the device's power resources. For this purpose introduce __acpi_bus_get_power() that will return the given device's power state via a pointer (instead of modifying device->power.state) and make acpi_bus_get_power() use it. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Introduce function acpi_power_on_resources() that reference counts and possibly turns on ACPI power resources for a given device and a given power state of it. This function will be used for reference counting device power resources during initialization. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
ACPI device power resources should be reference counted during device initialization, so that their reference counters are always up to date. It is convenient to do that with the help of a function that will reference count and possibly turn on power resources in a given list, so introduce that function, acpi_power_on_list(). For symmetry, introduce acpi_power_off_list() for performing the reverse operation and use the both of them to simplify acpi_power_transition(). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
acpi_power_get_inferred_state() should not update device->power.state behind the back of its caller, so make it return the state via a pointer instead. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 27 12月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
GPEs with corresponding _Lxx/_Exx control methods need to be disabled during initialization in case they have been enabled by the BIOS, so that they don't fire up until they are enabled by acpi_update_gpes(). References: https://bugzilla.kernel.org/show_bug.cgi?id=25412Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 12月, 2010 1 次提交
-
-
由 Len Brown 提交于
This reverts commit 3138b32d. as it caused a crash upon battery removal: https://bugzilla.kernel.org/show_bug.cgi?id=25302Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 18 12月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
If a device is reported as inactive or not present by its _STA control method, acpi_bus_check_add() skips it without evaluating its _PRW method. This leads to a problem when the device's _PRW method points to a GPE, because in that case the GPE may be enabled by ACPICA during the subsequent acpi_update_gpes() call which, in turn, may cause a GPE storm to appear. To avoid this issue, make acpi_bus_check_add() evaluate _PRW for inactive or not present devices and register the wakeup GPE information returned by them, so that acpi_update_gpes() does not enable their GPEs unnecessarily. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 12月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The saving of the NVS memory area during suspend and restoring it during resume causes problems to appear on Sony Vaio VGN-NW130D, so blacklist that machine to avoid those problems. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=23002Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NAdriano <adriano.vilela@yahoo.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 11 12月, 2010 7 次提交
-
-
由 Jan Beulich 提交于
Properly const-, __init-, and __read_mostly-annotate this code. Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Jan Beulich 提交于
Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
When CONFIG_CPU_FREQ=n ... drivers/acpi/processor_thermal.c:159:12: warning: ‘acpi_thermal_cpufreq_increase’ defined but not used drivers/acpi/processor_thermal.c:163:12: warning: ‘acpi_thermal_cpufreq_decrease’ defined but not used Remove unused declaration of ‘acpi_thermal_cpufreq_increase’ and ‘acpi_thermal_cpufreq_decrease’ Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 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>
-
由 Huang Ying 提交于
ERST writing may be used in NMI or Machine Check Exception handler. So it need to use raw spinlock instead of normal spinlock. This patch fixes it. Signed-off-by: NHuang Ying <ying.huang@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>
-
- 10 12月, 2010 3 次提交
-
-
由 Alexey Starikovskiy 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=15418Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> cc: stable@kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Sometimes the Battery driver doesn't get notifications when it's plugged/unplugged. And this results in the incorrect Battery status reported by the power supply sysfs I/F. Update Battery status first when querying from sysfs. http://marc.info/?l=linux-acpi&m=128855015826728&w=2 Tested_by: Seblu <seblu@seblu.net> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
http://marc.info/?l=linux-acpi&m=128855015826728&w=2 https://bugzilla.kernel.org/show_bug.cgi?id=21722 Tested_by: Seblu <seblu@seblu.net> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 02 12月, 2010 2 次提交
-
-
由 Rafael J. Wysocki 提交于
If turning on a power resource fails, do not reference count it, since it cannot be in use in that case. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Commit 3e384ee6 (ACPI / PM: Fix reference counting of power resources) introduced a regression by causing fan power resources to be turned on and reference counted unnecessarily during resume, so on some boxes fans are always on after resume. Fix the problem by checking if the current device state is different from the new state before reference counting and turning on power resources in acpi_power_transition(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22932 . Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 11月, 2010 1 次提交
-
-
由 Dave Jones 提交于
Currently we have: --w--w--w-. 1 root root 0 2010-11-11 14:56 /sys/kernel/debug/acpi/custom_method which is just crazy. Change this to --w-------. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com> Cc: stable@kernel.org (for 2.6.36) Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 10月, 2010 2 次提交
-
-
由 Zhang Rui 提交于
ACPI table sysfs I/F is broken by commit 78f16996 Author: Alex Chiang <achiang@hp.com> Date: Sun Dec 20 12:19:09 2009 -0700 ACPI: processor: call _PDC early because dynamic SSDT tables may be loaded in _PDC, before installing the ACPI table handler. As a result, the sysfs I/F of these dynamic tables are located at /sys/firmware/acpi/tables instead of /sys/firmware/acpi/tables/dynamic, which is not true. Invoke acpi_sysfs_init() before acpi_early_processor_set_pdc(), so that the table handler is installed before any dynamic tables loaded. https://bugzilla.kernel.org/show_bug.cgi?id=21142 CC: Dennis Jansen <dennis.jansen@web.de> CC: Alex Chiang <achiang@hp.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Sony Vaio VPCEB1Z1E is reported to require acpi_sleep=nonvs for suspend/resume to work on it correctly, so blacklist it. Reported-by: NEmanuele Bigiarini <pulmro@gmail.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> 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>
-
- 24 10月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The function acpi_battery_get_property() is called by the power supply framework's function power_supply_show_property() implementing the sysfs interface for power supply devices as the ACPI battery driver's ->get_property() callback. Thus it is supposed to return error code if the value of the given property is unknown. Unfortunately, however, it returns 0 in those cases and puts a wrong (negative) value into the intval field of the union power_supply_propval object provided by power_supply_show_property(). In consequence, wrong negative values are read by user space from the battery's sysfs files. Fix this by making acpi_battery_get_property() return -ENODEV for properties with unknown values (-ENODEV is returned, because power_supply_uevent() returns with error for any other error code returned by power_supply_show_property()). Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 10月, 2010 2 次提交
-
-
由 Rafael J. Wysocki 提交于
The reference counting of ACPI power resources is currently broken for a few reasons. First, instead of using a simple reference counter per power resource it uses a list of objects representing refereces to the given power resource from devices. This leads to the second breakage, because it prevents power resources from being referenced more than once by one device, which is necessary if the device is configured to signal wakeup. Namely, when putting the device into a low power state we first call acpi_enable_wakeup_device_power() that should reference count power resources needed for signaling wakeup and then we call acpi_power_transition() to power off the device. The latter call drops references to the device's power resources, possibly including the ones added by acpi_enable_wakeup_device_power(), so the device can't signal wakeup as a result. Apart from this, the locking in acpi_power_on() and acpi_power_off_device() doesn't prevent all possible races from happening, which may be problematic for runtime PM and asynchronous suspend and resume. Fix the problem by using a counter for power resources reference counting and putting the evaluation of ACPI _ON and _OFF methods under the power resource mutex. Reported-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bob Moore 提交于
Some Panasonic Toughbooks create nodes in module level code. Module level code is the executable AML code outside of control method, for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL If (\_OSI ("Windows 2006")) { Scope (\_SB.PCI0.GFX0.DD02) { Name (CUBL, Ones) ... } } Scope() op does not actually create a new object, it refers to an existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for Scope(), we want to indeed open a new scope, so the child nodes(CUBL in above example) can be created correctly under it. https://bugzilla.kernel.org/show_bug.cgi?id=19462Signed-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>
-
- 22 10月, 2010 2 次提交
-
-
由 Zhang Rui 提交于
According to the ACPI spec, some kinds of primary battery can report percentage battery remaining capacity directly to OS. In this case, it reports the LastFullChargedCapacity == 100, BatteryPresentRate = 0xFFFFFFFF, and BatteryRemaingCapacity a percentage value, which actually means RemainingBatteryPercentage. Now we found some battery follows this rule even if it's a rechargeable. https://bugzilla.kernel.org/show_bug.cgi?id=15979 Handle these batteries correctly in ACPI battery driver so that they won't break userspace. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Thomas Renninger 提交于
Here and then there show up machines which need higher timeout values. Finding this on affected machines can be cumbersome, because ACPI_EC_DELAY is a compile option -> make it configurable via boot param. This can even be provided writable at runtime via: /sys/modules/acpi/parameters/ec_delay Known machines where this helps: Some HP machines where for whatever reasons specific EC accesses take very long at resume from S3 (in _WAK function). The AE_TIME error is passed upwards and the ACPI interpreter will not execute the rest of the _WAK function which results in not properly initialized devices/variables with different side-effects. Afaik, on some MSI machines this helped as well. If this param is needed there probably are underlying problems like: - EC firmware bug - A kernel EC driver bug - An ACPI interpreter behavior (e.g. timings when specific EC accesses happen and how) which the EC does not like - ... which should get evaluated further, but often are nasty or impossible to fix from OS side. Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 10月, 2010 1 次提交
-
-
由 Uwe Kleine-König 提交于
find_dock and find_bay are only called by dock_init which lives in .init.text dock_add is only called by find_dock and find_bay. So all three functions can be moved to .init.text, too. This fixes: WARNING: vmlinux.o(.text+0x2134b7): Section mismatch in reference from the function dock_add() to the function .init.text:platform_device_register_resndata() The function dock_add() references the function __init platform_device_register_resndata(). This is often because dock_add lacks a __init annotation or the annotation of platform_device_register_resndata is wrong. for a build with unset CONFIG_MODULES. Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-