- Jul 17, 2008
-
-
Bjorn Helgaas authored
Rather than stepping through all IO resources, then stepping through all MMIO resources, etc., we can just iterate over the resource list once directly. This can change the order in /sys, e.g., # cat /sys/devices/pnp0/00:07/resources # OLD state = active io 0x3f8-0x3ff irq 4 # cat /sys/devices/pnp0/00:07/resources # NEW state = active irq 4 io 0x3f8-0x3ff The old code artificially sorted resources by type; the new code just lists them in the order we read them from the ISAPNP hardware or the BIOS. Signed-off-by:Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com>
-
Bjorn Helgaas authored
We used to have a fixed-size resource table. If a device had twenty resources when the table only had space for ten, we didn't need ten warnings, so we added the ratelimit. Now that we can dynamically allocate new resources, we should only get failures if the allocation fails. That should be rare enough that we don't need to ratelimit the messages. Signed-off-by:
-
Bjorn Helgaas authored
When we parse a device's _CRS data (the current resource settings), we should keep track of everything we find, even if it's currently disabled or invalid. This is what we already do for ISAPNP and PNPBIOS, and it helps keep things matched up when we subsequently re-encode resources. For example, consider a device with (mem, irq0, irq1, io), where irq0 is disabled. If we drop irq0 when parsing the _CRS, we will mistakenly put irq1 in the irq0 slot when we encode resources for an _SRS call. Signed-off-by:
-
Bjorn Helgaas authored
PNP used to have a fixed-size pnp_resource_table for tracking the resources used by a device. This table often overflowed, so we've had to increase the table size, which wastes memory because most devices have very few resources. This patch replaces the table with a linked list of resources where the entries are allocated on demand. This removes messages like these: pnpacpi: exceeded the max number of IO resources 00:01: too many I/O port resources References: http://bugzilla.kernel.org/show_bug.cgi?id=9535 http://bugzilla.kernel.org/show_bug.cgi?id=9740 http://lkml.org/lkml/2007/11/30/110 This patch also changes the way PNP uses the IORESOURCE_UNSET, IORESOURCE_AUTO, and IORESOURCE_DISABLED flags. Prior to this patch, the pnp_resource_table entries used the flags like this: IORESOURCE_UNSET This table entry is unused and available for use. When this flag is set, we shouldn't look at anything else in the resource structure. This flag is set when a resource table entry is initialized. IORESOURCE_AUTO This resource was assigned automatically by pnp_assign_{io,mem,etc}(). This flag is set when a resource table entry is initialized and cleared whenever we discover a resource setting by reading an ISAPNP config register, parsing a PNPBIOS resource data stream, parsing an ACPI _CRS list, or interpreting a sysfs "set" command. Resources marked IORESOURCE_AUTO are reinitialized and marked as IORESOURCE_UNSET by pnp_clean_resource_table() in these cases: - before we attempt to assign resources automatically, - if we fail to assign resources automatically, - after disabling a device IORESOURCE_DISABLED Set by pnp_assign_{io,mem,etc}() when automatic assignment fails. Also set by PNPBIOS and PNPACPI for: - invalid IRQs or GSI registration failures - invalid DMA channels - I/O ports above 0x10000 - mem ranges with negative length After this patch, there is no pnp_resource_table, and the resource list entries use the flags like this: IORESOURCE_UNSET This flag is no longer used in PNP. Instead of keeping IORESOURCE_UNSET entries in the resource list, we remove entries from the list and free them. IORESOURCE_AUTO No change in meaning: it still means the resource was assigned automatically by pnp_assign_{port,mem,etc}(), but these functions now set the bit explicitly. We still "clean" a device's resource list in the same places, but rather than reinitializing IORESOURCE_AUTO entries, we just remove them from the list. Note that IORESOURCE_AUTO entries are always at the end of the list, so removing them doesn't reorder other list entries. This is because non-IORESOURCE_AUTO entries are added by the ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the sysfs "set" command. In each of these cases, we completely free the resource list first. IORESOURCE_DISABLED In addition to the cases where we used to set this flag, ISAPNP now adds an IORESOURCE_DISABLED resource when it reads a configuration register with a "disabled" value. Signed-off-by: -
Bjorn Helgaas authored
Some callers use pnp_port_start() and similar functions without making sure the resource is valid. This patch makes us fall back to returning the initial values if the resource is not valid or not even present. This mostly preserves the previous behavior, where we would just return the initial values set by pnp_init_resource_table(). The original 2.6.25 code didn't range-check the "bar", so it would return garbage if the bar exceeded the table size. This code returns sensible values instead. Signed-off-by:
-
Bjorn Helgaas authored
This patch adds a "pnp_resource_type_name(struct resource *)" that returns the string resource type. This will be used by the sysfs "show resources" function and the debug resource dump function. Signed-off-by:
-
Bjorn Helgaas authored
Given a struct resource, this returns the type (IO, MEM, IRQ, DMA). Signed-off-by:
-
Bjorn Helgaas authored
We used pnp_resource.index to keep track of which ISAPNP configuration register a resource should be written to. We needed this only to handle the case where a register is disabled but a subsequent register in the same set is enabled. Rather than explicitly maintaining the pnp_resource.index, this patch adds a resource every time we read an ISAPNP configuration register and marks the resource as IORESOURCE_DISABLED when appropriate. This makes the position in the pnp_resource_table always correspond to the config register index. Signed-off-by:
-
Bjorn Helgaas authored
In the debug resource dump, decode the flags and indicate when a resource is disabled or has been automatically assigned. Signed-off-by:
-
Julia Jomantaite authored
Fix use of uninitialized device->brightness. Signed-off-by:
Julia Jomantaite <julia.jomantaite@gmail.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Len Brown authored
...while Len is on sabbatical from Intel Signed-off-by:
-
Len Brown authored
Reflect that Zhang-Rui has been the sub-maintainer for ACPI THERMAL and FAN for some time now. Also, the Chinese custom is to speak family name first, so rather than "Rui Zhang", write "Zhang Rui", as he does on e-mail. Signed-off-by:
-
Zhao Yakui authored
If a system matches in this DMI table, Linux will disable MWAIT support for idle. ie. "idle=nomwait" is automatically invoked and C1_FFH and C2C3_FFH access mode are disabled. http://bugzilla.kernel.org/show_bug.cgi?id=10807 http://bugzilla.kernel.org/show_bug.cgi?id=10914 Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Li Shaohua <shaohua.li@intel.com> Signed-off-by:
-
Zhao Yakui authored
"idle=nomwait" disables the use of the MWAIT instruction from both C1 (C1_FFH) and deeper (C2C3_FFH) C-states. When MWAIT is unavailable, the BIOS and OS generally negotiate to use the HALT instruction for C1, and use IO accesses for deeper C-states. This option is useful for power and performance comparisons, and also to work around BIOS bugs where broken MWAIT support is advertised. http://bugzilla.kernel.org/show_bug.cgi?id=10807 http://bugzilla.kernel.org/show_bug.cgi?id=10914 Signed-off-by:
-
Zhao Yakui authored
"idle=halt" limits the idle loop to using the halt instruction. No MWAIT, no IO accesses, no C-states deeper than C1. If something is broken in the idle code, "idle=halt" is a less severe workaround than "idle=poll" which disables all power savings. Signed-off-by:
-
Zhao Yakui authored
991528d7 (ACPI: Processor native C-states using MWAIT) started passing C2C3_FFH to _PDC to tell the BIOS that Linux supports MWAIT for deep C-states. However, we should first double check with the hardware that it actually supports MWAIT before potentially exposing a BIOS bug of an MWAIT _CST on HW that doesn't support MWAIT. Signed-off-by:
-
Zhang Rui authored
Allow users to enable/disable/clear a specific & valid GPE/Fixed Event in user space. This is useful for debugging, especially for some interrupt storm issues. All wakeup GPEs are disabled and they can not be enabled at runtime, and we mark them as invalid. All GPEs that don't have a _Lxx/_Exx method are marked as invalid. All Fixed Events that don't have an event handler are marked as invalid and they can't be enabled until an event handler is registered. Signed-off-by:
Ling Ming <ming.m.lin@intel.com> Signed-off-by:
-
Bob Moore authored
Update version to 20080609. Signed-off-by:
-
Bob Moore authored
Loop was terminating one iteration early, missing one of the debugger handshake mutexes. Linn Crosetto. Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
-
Bob Moore authored
Removed extraneous else clauses, other general cleanup. Signed-off-by:
-
Bob Moore authored
Eliminated unnecessary operands; eliminated use of negative index in loop. Operands now displayed in correct order, not backwards. Signed-off-by:
-
Bob Moore authored
This problem was introduced in 20080514 as a result of the elimination of the acpi_native_uint type. Code uses a negative array index, which should be eliminated. Signed-off-by:
-
Bob Moore authored
Now supports the 2007 intel Virtualization Technology for Directed I/O specification. Signed-off-by:
-
Bob Moore authored
Synchronized tables with current specifications. Signed-off-by:
-
Bob Moore authored
Some BIOSs erroneously reverse the _PRT SourceName and the SourceIndex. Detect and repair this problem. MS ACPI also allows and repairs this problem, thus ACPICA must also. Signed-off-by:
-
Bob Moore authored
Update version to 20080514 Signed-off-by:
-
Bob Moore authored
Mostly MODULE_NAME and printf format strings. Signed-off-by:
-
Bob Moore authored
Remove pointer cast warnings and fix for a debug printf. Signed-off-by:
-
Bob Moore authored
From lint. Signed-off-by:
-
Bob Moore authored
No longer needed; replaced mostly with u32, but also acpi_size where a type that changes 32/64 bit on 32/64-bit platforms is required. v2: Fix a cast of a 32-bit int to a pointer in ACPI to avoid a compiler warning. from David Howells Signed-off-by:
-
Bob Moore authored
Added NULL fields to the exception string arrays to eliminate the -1 subtraction on the SubStatus field. Signed-off-by:
-
Jan Beulich authored
Changed ACPI_MODULE_NAME and ACPI_FUNCTION_NAME to use arrays of strings instead of pointers to static strings. Jan Beulich and Bob Moore. Signed-off-by:
-
Bob Moore authored
Fixes problem where the new method argument count validation mechanism will enter an infinite loop when a GPE method is dispatched. Problem fixed be removing the obsolete code that passes GPE block information to the notify handler via the control method parameter pointer. Signed-off-by:
-
Bob Moore authored
Error if too few arguments, warning if too many. This applies only to external programmatic control method execution, not method-to-method calls within the AML. Signed-off-by:
-
Randy Dunlap authored
fujitsu-laptop uses input_* functions, so it should depend on INPUT. drivers/built-in.o: In function `acpi_fujitsu_add': fujitsu-laptop.c:(.text+0xaaec7): undefined reference to `input_allocate_device' fujitsu-laptop.c:(.text+0xaaf39): undefined reference to `input_register_device' fujitsu-laptop.c:(.text+0xab025): undefined reference to `input_free_device' drivers/built-in.o: In function `acpi_fujitsu_notify': fujitsu-laptop.c:(.text+0xab0d8): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab0e5): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab0f5): undefined reference to `input_event' fujitsu-laptop.c:(.text+0xab102): undefined reference to `input_event' drivers/built-in.o: In function `acpi_fujitsu_hotkey_notify': fujitsu-laptop.c:(.text+0xab261): undefined reference to `input_event' drivers/built-in.o:fujitsu-laptop.c:(.text+0xab26e): more undefined references to `input_event' follow drivers/built-in.o: In function `acpi_fujitsu_hotkey_add': fujitsu-laptop.c:(.text+0xab49c): undefined reference to `input_allocate_device' fujitsu-laptop.c:(.text+0xab51a): undefined reference to `input_register_device' fujitsu-laptop.c:(.text+0xab5e4): undefined reference to `input_free_device' make[1]: *** [.tmp_vmlinux1] Error 1 Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Jonathan Woithe <jwoithe@physics.adelaide.edu.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Rafael J. Wysocki authored
We can avoid taking the BKL in snapshot_ioctl() if pm_mutex is used to prevent the ioctls from being executed concurrently. In addition, although it is only possible to open /dev/snapshot once, the task which has done that may spawn a child that will inherit the open descriptor, so in theory they can call snapshot_write(), snapshot_read() and snapshot_release() concurrently. pm_mutex can also be used for mutual exclusion in such cases. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Alan Cox authored
Push BKL down into ioctl handlers - snapshot device. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
The freezer currently attempts to distinguish kernel threads from user space tasks by checking if their mm pointer is unset and it does not send fake signals to kernel threads. However, there are kernel threads, mostly related to networking, that behave like user space tasks and may want to be sent a fake signal to be frozen. Introduce the new process flag PF_FREEZER_NOSIG that will be set by default for all kernel threads and make the freezer only send fake signals to the tasks having PF_FREEZER_NOSIG unset. Provide the set_freezable_with_signal() function to be called by the kernel threads that want to be sent a fake signal for freezing. This patch should not change the freezer's observable behavior. Signed-off-by:
-
Johannes Berg authored
This revamps the apm-emulation code to get suspend notifications regardless of what way pm_suspend() was invoked, whether via the apm ioctl or via /sys/power/state. Also do some code cleanup and add comments while at it. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Rafael J. Wysocki authored
Remove the obsolete workaround for a Toshiba Satellite 4030cdt S1 problem from drivers/acpi/sleep/main.c . Signed-off-by:
-
