aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pnp/pnpacpi
Commit message (Collapse)AuthorAge
* Merge branch 'pnp' into releaseLen Brown2011-01-12
|\
| * PNP: Compile all pnp built-in stuff in one module namespaceThomas Renninger2010-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is cleanup mostly, nothing urgent. I came up with it when looking at dynamic debug which can enable pr_debug messages at runtime or boot param for a specific module. Advantages: - Any pnp code can make use of the moduleparam.h interface, the modules will show up as pnp.param. - Passing pnp.ddebug as kernel boot param will enable all pnp debug messages with my previous patch and CONFIG_DYNAMIC_DEBUG enabled. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | PNP / ACPI: Use DEVICE_ACPI_HANDLE() for device ACPI handle accessRafael J. Wysocki2011-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PNP ACPI driver squirrels the ACPI handles of PNP devices' ACPI companions, but this isn't correct, because those handles should be accessed using the DEVICE_ACPI_HANDLE() macro operating on struct device objects. Using DEVICE_ACPI_HANDLE() in the PNP ACPI driver instead of the driver's own copies of the ACPI handles allows us to avoid a problem with docking stations where a machine docked before suspend to RAM and undocked while suspended crashes during the subsequent resume (in that case the ACPI companion of the PNP device in question doesn't exist any more while the device is being resumed). It also allows us to avoid the problem where suspend to RAM fails when the machine was undocked while suspended before (again, the ACPI companion of the PNP device is not present any more while it is being suspended). This change doesn't fix all of the the PNP ACPI driver's problems with PNP devices in docking stations (generally speaking, the driver has no idea that devices can come and go and doesn't even attempt to handle such events), but at least it makes suspend work for the users of docking stations who don't use the PNP devices located in there. References: https://bugzilla.kernel.org/show_bug.cgi?id=15100 Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI/PNP: avoid section mismatch warningJan Beulich2010-12-11
| | | | | | | | | | Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'pnpacpi-invalid-device-id' into releaseLen Brown2010-10-25
|\ \
| * | PNPACPI: cope with invalid device IDsDmitry Torokhov2010-10-01
| |/ | | | | | | | | | | | | | | | | | | | | | | | | If primary ID (HID) is invalid try locating first valid ID on compatible ID list before giving up. This helps, for example, to recognize i8042 AUX port on Sony Vaio VPCZ1 which uses SNYSYN0003 as HID. Without the patch users are forced to boot with i8042.nopnp to make use of their touchpads. Tested-by: Jan-Hendrik Zab <jan@jhz.name> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
* / ACPI/PNP: A HID value of an object never changes -> make it constThomas Renninger2010-10-01
|/ | | | | Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: Add support for remote wakeupAlan Stern2010-07-18
| | | | | | | | | | | This patch (as1354) adds remote-wakeup support to the pnpacpi driver. The new can_wakeup method also allows other PNP protocol drivers (pnpbios or iaspnp) to add wakeup support, but I don't know enough about how they work to actually do it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* PNPACPI: compute Address Space length rather than using _LENBjorn Helgaas2010-04-28
| | | | | | | | | | | | | | | | | | | | | ACPI _CRS Address Space Descriptors have _MIN, _MAX, and _LEN. Linux has been computing Address Spaces as [_MIN to _MIN + _LEN - 1]. Based on the tests in the bug reports below, Windows apparently uses [_MIN to _MAX]. Per spec (ACPI 4.0, Table 6-40), for _CRS fixed-size, fixed location descriptors, "_LEN must be (_MAX - _MIN + 1)", and when that's true, it doesn't matter which way we compute the end. But of course, there are BIOSes that don't follow this rule, and we're better off if Linux handles those exceptions the same way as Windows. This patch makes Linux use [_MIN to _MAX], as Windows seems to do. This effectively reverts 3162b6f0c5e and replaces it with simpler code. https://bugzilla.kernel.org/show_bug.cgi?id=14337 (round) https://bugzilla.kernel.org/show_bug.cgi?id=15480 (truncate) Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
*-. Merge branches 'battery', 'bugzilla-14667', 'bugzilla-15096', ↵Len Brown2010-04-06
|\ \ | | | | | | | | | 'bugzilla-15480', 'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 'pxm-fix' and 'video-random-key' into release
| | * PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1Bjorn Helgaas2010-04-04
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | The ACPI spec (sec 6.4.3.5 in v4.0) requires that for Address Space Resource Descriptors, _LEN <= _MAX - _MIN + 1 in all cases, but there are BIOSes that violate this. We experimentally determined that Windows truncates the resource so it doesn't extend past _MAX, so let's do the same thing in Linux. http://bugzilla.kernel.org/show_bug.cgi?id=15480 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-30
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* PNPACPI: add bus number supportBjorn Helgaas2010-03-14
| | | | | | | | Add support for bus number resources. This is for bridges with a range of bus numbers behind them. Previously, PNP ignored bus number resources. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: add window supportBjorn Helgaas2010-03-14
| | | | | | | | | | Add support for resource windows. This is for bridge resources, i.e., regions where a bridge forwards transactions from the primary to the secondary side. This does not add support for *setting* windows via the /proc interface. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNP: add interface to retrieve ACPI device from a PNPACPI deviceBjorn Helgaas2009-12-15
| | | | | | | | | | | | Add pnp_acpi_device(pnp_dev), which takes a PNP device and returns the associated ACPI device (or NULL, if the device is not a PNPACPI device). This allows us to write a PNP driver that can manage both traditional PNPBIOS and ACPI devices, treating ACPI-only functionality as an optional extension. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: save struct acpi_device, not just acpi_handleBjorn Helgaas2009-12-11
| | | | | | | | Some drivers need to look at things in the acpi_device structure besides the handle. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: remove acpi_device.flags.hardware_idBjorn Helgaas2009-09-25
| | | | | | | | | Every acpi_device has at least one ID (if there's no _HID or _CID, we give it a synthetic or default ID). So there's no longer a need to check whether an ID exists; we can just use it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: maintain a single list of _HID and _CID IDsBjorn Helgaas2009-09-25
| | | | | | | | | | | There's no need to treat _HID and _CID differently. Keeping them in a single list makes code that uses the IDs a little simpler because it can just traverse the list rather than checking "do we have a HID?", "do we have any CIDs?" Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: use acpi_device_hid() when possibleBjorn Helgaas2009-09-25
| | | | | | | | Use acpi_device_hid() rather than accessing acpi_device.pnp.hardware_id directly. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPICA: Major update for acpi_get_object_info external interfaceBob Moore2009-08-27
| | | | | | | | | | | | | | | | | | Completed a major update for the acpi_get_object_info external interface. Changes include: - Support for variable, unlimited length HID, UID, and CID strings - Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.) - Call the _SxW power methods on behalf of a device object - Determine if a device is a PCI root bridge - Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO. These changes will require an update to all callers of this interface. See the ACPICA Programmer Reference for details. Also, update all invocations of acpi_get_object_info interface Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
*-. Merge branches 'acerhdf', 'acpi-pci-bind', 'bjorn-pci-root', ↵Len Brown2009-06-24
|\ \ | | | | | | | | | 'bugzilla-12904', 'bugzilla-13121', 'bugzilla-13396', 'bugzilla-13533', 'bugzilla-13612', 'c3_lock', 'hid-cleanups', 'misc-2.6.31', 'pdc-leak-fix', 'pnpacpi', 'power_nocheck', 'thinkpad_acpi', 'video' and 'wmi' into release
| | * PNPACPI: parse Extended Address Space DescriptorsBjorn Helgaas2009-05-27
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extended Address Space Descriptors are new in ACPI 3.0 and allow the BIOS to communicate device resource cacheability attributes (write-back, write-through, uncacheable, etc) to the OS. Previously, PNPACPI ignored these descriptors, so if a BIOS used them, a device could be responding at addresses the OS doesn't know about. This patch adds support for these descriptors in _CRS and _PRS. We don't attempt to encode them for _SRS (just like we don't attempt to encode the existing 16-, 32-, and 64-bit Address Space Descriptors). Unfortunately, I don't have a way to test this. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'linus' into irq/numaIngo Molnar2009-06-01
|\| | | | | | | | | | | | | | | | | | | Conflicts: arch/mips/sibyte/bcm1480/irq.c arch/mips/sibyte/sb1250/irq.c Merge reason: we gathered a few conflicts plus update to latest upstream fixes. Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * ACPI: suspend: don't let device _PS3 failure prevent suspendLen Brown2009-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6328a57401dc5f5cf9931738eb7268fcd8058c49 "Enable PNPACPI _PSx Support, v3" added a call to acpi_bus_set_power(handle, ACPI_STATE_D3) to pnpacpi_disable_resource() before the existing call to evaluate _DIS on the device. This caused suspend to fail on the system in http://bugzilla.kernel.org/show_bug.cgi?id=13243 because the sanity check to verify we entered _PS3 failed on the serial port. As a work-around, that sanity check can be disabled system-wide with "acpi.power_nocheck=1" Or perhaps we should just shrug off the _PS3 failure and carry on with _DIS like we used to -- which is what this patch does. Signed-off-by: Len Brown <len.brown@intel.com>
* | irq: change ACPI GSI APIs to also take a device argumentYinghai Lu2009-04-28
|/ | | | | | | | | | | | | | | | | | | | | We want to use dev_to_node() later on, to be aware of the 'home node' of the GSI in question. [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Len Brown <lenb@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Len Brown <lenb@kernel.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-acpi@vger.kernel.org Cc: linux-ia64@vger.kernel.org LKML-Reference: <49F65560.20904@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Enable PNPACPI _PSx Support, v3Witold Szczeponik2009-04-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is an update to the patch presented earlier in http://lkml.org/lkml/2008/12/8/284, with new error handling.) This patch sets the power of PnP ACPI devices to D0 when they are activated and to D3 when they are disabled. The latter is in correspondence with the ACPI 3.0 specification, whereas the former is added in order to be able to power up a device after it has been previously disabled (or when booting up a system). (As a consequence, the patch makes the PnP ACPI code more ACPI compliant.) Section 6.2.2 of the ACPI Specification (at least versions 1.0b and 3.0a) states: "Prior to running this control method [_DIS], the OS[PM] will have already put the device in the D3 state." Unfortunately, there is no clear statement as to when to put a device in the D0 state. :-( Therefore, the patch executes the method calls as _PS3/_DIS and _SRS/_PS0. What is clear: "If the device is disabled, _SRS enables the device at the specified resources." (From the ACPI 3.0a Specification.) The patch fixes a problem with some IBM ThinkPads (at least the 600E and the 600X) where the serial ports have a dedicated power source that needs to be brought up before the serial port can be used. Without this patch, the serial port is enabled but has no power. (In the past, the tpctl utility had to be utilized to turn on the power, but support for this feature stopped with version 5.9 as it did not support the more recent kernel versions.) The error handlers that handle any errors that can occur during the power up/power down phases return the error codes to the caller directly. Comments welcome! :-) No regressions were observed on hardware that does not require this patch. The patch is applied against 2.6.27.x. Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net> Acked-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: remove private acpica headers from driver filesLin Ming2008-12-31
| | | | | | | External driver files should not include any private acpica headers. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'linus' into testLen Brown2008-10-23
|\ | | | | | | | | | | | | | | | | | | | | | | Conflicts: MAINTAINERS arch/x86/kernel/acpi/boot.c arch/x86/kernel/acpi/sleep.c drivers/acpi/Kconfig drivers/pnp/Makefile drivers/pnp/quirks.c Signed-off-by: Len Brown <len.brown@intel.com>
| * PnP: move pnpacpi/pnpbios_init to after PCI initLinus Torvalds2008-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already did that a long time ago for pnp_system_init, but pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get linked into the kernel before the arch-specific routines that finalize the PCI resources (pci_subsys_init). This means that the PnP routines would either register their resources before the PCI layer could, or would be unable to check whether a PCI resource had already been registered. Both are problematic. I wanted to do this before 2.6.27, but every time we change something like this, something breaks. That said, _every_ single time we trust some firmware (like PnP tables) more than we trust the hardware itself (like PCI probing), the problems have been worse. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'pnp-debug' into testLen Brown2008-10-22
|\ \
| * | PNP: remove old CONFIG_PNP_DEBUG optionBjorn Helgaas2008-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_PNP_DEBUG is no longer used to turn on dev_dbg() in PNP, since we have pnp_dbg() which can be enabled at boot-time, so this patch removes the config option. Note that pnp_dock_event() checks "#ifdef DEBUG". But there's never been a clear path for enabling that via configgery. It happened that CONFIG_PNP_DEBUG enabled it after 1bd17e63a068db6, but that was accidental and only in 2.6.26. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | PNP: convert to using pnp_dbg()Bjorn Helgaas2008-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pnp_dbg() is equivalent to dev_dbg() except that we can turn it on at boot-time with the "pnp.debug" kernel parameter, so we don't have to build a new kernel image. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | PNP: convert the last few pnp_info() uses to printk()Bjorn Helgaas2008-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are only a few remaining uses of pnp_info(), so I just converted them to printk and removed the pnp_err(), pnp_info(), pnp_warn(), and pnp_dbg() wrappers. I also removed a couple debug messages that don't seem useful any more ("driver registered", "driver unregistered", "driver attached"). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | PNPACPI: use dev_printk when possibleBjorn Helgaas2008-10-10
| |/ | | | | | | | | | | | | | | Use dev_printk() when possible for more informative error messages. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* / ACPI : Load device driver according to the status of acpi deviceZhao Yakui2008-10-22
|/ | | | | | | | | | | | | | | | | | | | | | According to ACPI spec when the status of some device is not present but functional, the device is valid and the children of this device should be enumerated. It means that the device should be added to linux acpi device tree. But the device driver for this device should not be loaded. The detailed info can be found in the section 6.3.7 of ACPI 3.0b spec. _STA may return bit 0 clear (not present) with bit 3 set (device is functional). This case is used to indicate a valid device for which no device driver should be loaded (for example, a bridge device.). Children of this device may be present and valid. OS should continue enumeration below a device whose _STA returns this bit combination http://bugzilla.kernel.org/show_bug.cgi?id=3358 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Li Shaohua <shaohua.li@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: ignore the producer/consumer bit for extended IRQ descriptorsBjorn Helgaas2008-08-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Extended Interrupt descriptor has a producer/consumer bit, but it's not clear what that would mean, and existing BIOSes use the bit inconsistently. This patch makes Linux PNPACPI ignore the bit. The ACPI spec contains examples of PCI Interrupt Link devices marked as ResourceProducers, but many BIOSes mark them as ResourceConsumers. I also checked with a Windows contact, who said: Windows uses only "resource consumer" when dealing with interrupts. There's no useful way of looking at a resource producer of interrupts. ... NT-based Windows largely infers the producer/consumer stuff from the device type and ignores the bits in the namespace. This was necessary because Windows 98 ignored them and early namespaces contained random junk. The reason I want to change this is because if PNPACPI devices exclude ResourceProducer IRQ resources, we can't write PNP drivers for those devices. For example, on machines such as the the HP rx7620, rx7640, rx8620, rx8640, and Superdome, HPET interrupts are ResourceProducers. The HPET driver currently has to use acpi_bus_register_driver() and do its own _CRS parsing, even though it requires absolutely no ACPI-specific functionality. It would be better if the HPET driver were a PNP driver and took advantage of the _CRS parsing built into PNPACPI. This producer/consumer check was originally added here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b8de5f50e4a302b83ebcd5b0120621336d50bd6 to fix this bug: http://bugzilla.kernel.org/show_bug.cgi?id=6292 However, the bug was related only to memory and I/O port resources, where the distinction is sensible and important to Linux. Given that the distinction is muddled for IRQ resources, I think it was a mistake to add the check there. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* PNPACPI: add support for HP vendor-specific CCSR descriptorsBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | | The HP CCSR descriptor describes MMIO address space that should appear as a MEM resource. This patch adds support for parsing these descriptors in the _CRS data. The visible effect of this is that these MEM resources will appear in /sys/devices/pnp0/.../resources, which means that "lspnp -v" will report it, user applications can use this to locate device CSR space, and kernel drivers can use the normal PNP resource accessors to locate them. 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>
* PNP: convert resource options to single linked listBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of a device, i.e., the possibilities an OS bus driver has when it assigns I/O port, MMIO, and other resources to the device. PNP used to maintain this "possible resource setting" information in one independent option structure and a list of dependent option structures for each device. Each of these option structures had lists of I/O, memory, IRQ, and DMA resources, for example: dev independent options ind-io0 -> ind-io1 ... ind-mem0 -> ind-mem1 ... ... dependent option set 0 dep0-io0 -> dep0-io1 ... dep0-mem0 -> dep0-mem1 ... ... dependent option set 1 dep1-io0 -> dep1-io1 ... dep1-mem0 -> dep1-mem1 ... ... ... This data structure was designed for ISAPNP, where the OS configures device resource settings by writing directly to configuration registers. The OS can write the registers in arbitrary order much like it writes PCI BARs. However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces that perform device configuration, and it is important to pass the desired settings to those interfaces in the correct order. The OS learns the correct order by using firmware interfaces that return the "current resource settings" and "possible resource settings," but the option structures above doesn't store the ordering information. This patch replaces the independent and dependent lists with a single list of options. For example, a device might have possible resource settings like this: dev options ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ... All the possible settings are in the same list, in the order they come from the firmware "possible resource settings" list. Each entry is tagged with an independent/dependent flag. Dependent entries also have a "set number" and an optional priority value. All dependent entries must be assigned from the same set. For example, the OS can use all the entries from dependent set 0, or all the entries from dependent set 1, but it cannot mix entries from set 0 with entries from set 1. Prior to this patch PNP didn't keep track of the order of this list, and it assigned all independent options first, then all dependent ones. Using the example above, that resulted in a "desired configuration" list like this: ind->io0 -> ind->io1 -> depN-io0 ... instead of the list the firmware expects, which looks like this: ind->io0 -> depN-io0 -> ind-io1 ... Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNP: remove extra 0x100 bit from option priorityBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | When building resource options, ISAPNP and PNPBIOS set the priority to something like "0x100 | PNP_RES_PRIORITY_ACCEPTABLE", but we immediately mask off the 0x100 again in pnp_build_option(), so that bit looks superfluous. Thanks to Rene Herman <rene.herman@gmail.com> for pointing this out. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: ignore _PRS interrupt numbers larger than PNP_IRQ_NRBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | | | | | | | ACPI Extended Interrupt Descriptors can encode 32-bit interrupt numbers, so an interrupt number may exceed the size of the bitmap we use to track possible IRQ settings. To avoid corrupting memory, complain and ignore too-large interrupt numbers. There's similar code in pnpacpi_parse_irq_option(), but I didn't change that because the small IRQ descriptor can only encode IRQs 0-15, which do not exceed bitmap size. In the future, we could handle IRQ numbers greater than PNP_IRQ_NR by replacing the bitmap with a table or list. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNP: centralize resource option allocationsBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | This patch moves all the option allocations (pnp_mem, pnp_port, etc) into the pnp_register_{mem,port,irq,dma}_resource() functions. This will make it easier to rework the option data structures. The non-trivial part of this patch is the IRQ handling. The backends have to allocate a local pnp_irq_mask_t bitmap, populate it, and pass a pointer to pnp_register_irq_resource(). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNP: introduce pnp_irq_mask_t typedefBjorn Helgaas2008-07-16
| | | | | | | | | | | This adds a typedef for the IRQ bitmap, which should cause no functional change, but will make it easier to pass a pointer to a bitmap to pnp_register_irq_resource(). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNP: define PNP-specific IORESOURCE_IO_* flags alongside IRQ, DMA, MEMBjorn Helgaas2008-07-16
| | | | | | | | | | | | PNP previously defined PNP_PORT_FLAG_16BITADDR and PNP_PORT_FLAG_FIXED in a private header file, but put those flags in struct resource.flags fields. Better to make them IORESOURCE_IO_* flags like the existing IRQ, DMA, and MEM flags. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: keep disabled resources when parsing current configBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | | | 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 <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* PNP: replace pnp_resource_table with dynamically allocated resourcesBjorn Helgaas2008-07-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com>
* ACPI PM: acpi_pm_device_sleep_state() cleanupDavid Brownell2008-07-16
| | | | | | | | | | | | | Get rid of a superfluous acpi_pm_device_sleep_state() parameter. The only legitimate value of that parameter must be derived from the first parameter, which is what all the callers already do. (However, this does not address the fact that ACPI still doesn't set up those flags.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* PNPACPI: use _CRS IRQ descriptor length for _SRSBjorn Helgaas2008-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When configuring the resources of an ACPI device, we first evaluate _CRS to get a template of resource descriptors, then fill in the specific resource values we want, and finally evaluate _SRS to actually configure the device. Some resources have optional fields, so the size of encoded descriptors varies depending on the specific values. For example, IRQ descriptors can be either two or three bytes long. The third byte contains triggering information and can be omitted if the IRQ is edge-triggered and active high. The BIOS often assumes that IRQ descriptors in the _SRS buffer use the same format as those in the _CRS buffer, so this patch enforces that constraint. The "Start Dependent Function" descriptor also has an optional byte, but we don't currently encode those descriptors, so I didn't do anything for those. I have tested this patch on a Toshiba Portege 4000. Without the patch, parport_pc claims the parallel port only if I use "pnpacpi=off". This patch makes it work with PNPACPI. This is an extension of a patch by Tom Jaeger: http://bugzilla.kernel.org/show_bug.cgi?id=9487#c42 References: http://bugzilla.kernel.org/show_bug.cgi?id=5832 Enabling ACPI Plug and Play in kernels >2.6.9 kills Parallel support http://bugzilla.kernel.org/show_bug.cgi?id=9487 buggy firmware expects four-byte IRQ resource descriptor (was: Serial port disappears after Suspend on Toshiba R25) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1d5b285da1893b90507b081664ac27f1a8a3dc5b related ACPICA fix Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* pnpacpi: fix shareable IRQ encode/decodeBjorn Helgaas2008-06-11
| | | | | | | | | | | | When we encode IRQ resources, we should use the "shareable" flag we got from _PRS rather than guessing based on the IRQ trigger mode. This is based on a patch by Tom Jaeger: http://bugzilla.kernel.org/show_bug.cgi?id=9487#c32 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* pnpacpi: fix IRQ flag decodingBjorn Helgaas2008-06-11
| | | | | | | | | | | | | | | | | | | | | | | When decoding IRQ trigger mode and polarity, it is not enough to mask by IORESOURCE_BITS because there are now additional bits defined. For example, if IORESOURCE_IRQ_SHAREABLE was set, we failed to set *triggering and *polarity at all. I can't point to a failure that this patch fixes, but bugs in this area have caused problems when resuming after suspend, for example: http://bugzilla.kernel.org/show_bug.cgi?id=6316 http://bugzilla.kernel.org/show_bug.cgi?id=9487 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/152187 This is based on a patch by Tom Jaeger: http://bugzilla.kernel.org/show_bug.cgi?id=9487#c32 [rene.herman@keyaccess.nl: fix comment] Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'pnp' into releaseLen Brown2008-04-30
|\
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-27 05:15:58 -0500