linux/drivers/pnp, branch v2.6.27.32

ACPI: suspend: don't let device _PS3 failure prevent suspend

2009-07-30T23:06:11Z

commit 19bde778c1fd2574cc020a618d7d576f260271ca upstream. 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 Signed-off-by: Greg Kroah-Hartman

Enable PNPACPI _PSx Support, v3

2009-07-30T23:06:11Z

commit 6328a57401dc5f5cf9931738eb7268fcd8058c49 upstream. (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 Acked-by: Zhao Yakui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

pnp: make the resource type an unsigned long

2008-12-13T23:29:34Z

commit b563cf59c4d67da7d671788a9848416bfa4180ab upstream. PnP encodes the resource type directly as its struct resource->flags value which is an unsigned long. Make it so... Signed-off-by: Rene Herman Cc: "H. Peter Anvin" Acked-by: Bjorn Helgaas Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI : Load device driver according to the status of acpi device

2008-11-20T22:54:49Z

commit 39a0ad871000d2a016a4fa113a6e53d22aabf25d upstream. 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 Signed-off-by: Li Shaohua Signed-off-by: Zhang Rui Signed-off-by: Andi Kleen Signed-off-by: Len Brown Cc: Holger Macht Signed-off-by: Greg Kroah-Hartman

PNPACPI: ignore the producer/consumer bit for extended IRQ descriptors

2008-08-25T10:04:44Z

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 Signed-off-by: Andi Kleen

PNP: fix formatting of dbg_pnp_show_resources() output

2008-08-01T19:46:41Z

Each resource should be printed on its own line, so start snprintf'ing at the beginning of the buffer every time through the loop. Also, use scnprintf() rather than snprintf() when building up the buffer to print. scnprintf() returns the number of characters actually written into the buffer (not including the trailing NULL). snprintf() returns the number of characters that *would be* written, assuming everything would fit in the buffer. That's nice if we want to resize the buffer to make sure everything fits, but in this case, I just want to keep from overflowing the buffer, and it's OK if the output is truncated. Using snprintf() meant that my "len" could grow to be more than the the buffer size, which makes "sizeof(buf) - len" negative, which causes this alarming WARN_ON: http://marc.info/?l=linux-kernel&m=121736480005656&w=2 More useful snprintf/scnprintf discussion: http://lwn.net/Articles/69419/ Signed-off-by: Bjorn Helgaas Reported-by: Pete Clements Cc: Rene Herman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

make pnp_add_card_id() static

2008-07-26T19:00:11Z

pnp_add_card_id() can now become static. Signed-off-by: Adrian Bunk Cc: Bjorn Helgaas Cc: Rene Herman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

pnp: have quirk_system_pci_resources() include io resources

2008-07-26T19:00:02Z

quirk_system_pci_resources() disables a PnP mem resource that overlaps a PCI BAR so as to not keep the PCI driver from claiming the resource. Have it do the same for io resources. Here, ACPI claims ports that overlap with my soundcard causing the soundcard driver to fail to load. It's unknown why my ACPI BIOS claims those ports; it did not use to but this is not a (kernel) regression. Some odd BIOS reconfig triggered by temporarily removing the card seems to have brought this on. Signed-off-by: Rene Herman Acked-by: Bjorn Helgaas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

pnp: set the pnp_card dma_mask for use by ISAPnP cards

2008-07-26T19:00:02Z

dma_alloc_coherent() on x86 currently takes a passed in NULL device pointer to mean that it should allocate an ISA compatible (24-bit) buffer which is a bit of a hack. The ALSA ISA drivers are the main consumers of this but have a struct device in fact readily available. For the PnP drivers, the specific pnp_dev->dev device pointer is not always available at the right time so for now we want to pass the pnp_card->dev instead which is always available. Set its dma_mask in preparation for doing so. This does not fix a current bug -- 2.6.26-rc1 stumbled over the NULL hack in dma_alloc_coherent() but this has already been fixed in commit 4a367f3a9dbf2e7ffcee4702203479809236ee6e by Takashi Iwai. Signed-off-by: Rene Herman Acked-by: Bjorn Helgaas Acked-by: Takashi Iwai Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PNPACPI: add support for HP vendor-specific CCSR descriptors

2008-07-16T21:27:07Z

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 Signed-off-by: Len Brown Signed-off-by: Andi Kleen