kernel.git/drivers/pnp/pnpacpi, branch linux-3.1.y

Merge 'akpm' patch series

2011-07-26T04:00:19Z

* Merge akpm patch series: (122 commits) drivers/connector/cn_proc.c: remove unused local Documentation/SubmitChecklist: add RCU debug config options reiserfs: use hweight_long() reiserfs: use proper little-endian bitops pnpacpi: register disabled resources drivers/rtc/rtc-tegra.c: properly initialize spinlock drivers/rtc/rtc-twl.c: check return value of twl_rtc_write_u8() in twl_rtc_set_time() drivers/rtc: add support for Qualcomm PMIC8xxx RTC drivers/rtc/rtc-s3c.c: support clock gating drivers/rtc/rtc-mpc5121.c: add support for RTC on MPC5200 init: skip calibration delay if previously done misc/eeprom: add eeprom access driver for digsy_mtc board misc/eeprom: add driver for microwire 93xx46 EEPROMs checkpatch.pl: update $logFunctions checkpatch: make utf-8 test --strict checkpatch.pl: add ability to ignore various messages checkpatch: add a "prefer __aligned" check checkpatch: validate signature styles and To: and Cc: lines checkpatch: add __rcu as a sparse modifier checkpatch: suggest using min_t or max_t ... Did this as a merge because of (trivial) conflicts in - Documentation/feature-removal-schedule.txt - arch/xtensa/include/asm/uaccess.h that were just easier to fix up in the merge than in the patch series.

pnpacpi: register disabled resources

2011-07-26T03:57:17Z

When parsing PnP ACPI resource structures, it may happen that some of the resources are disabled (in which case "the size" of the resource equals zero). The current solution is to skip these resources completely - with the unfortunate side effect that they are not registered despite the fact that they exist, after all. (The downside of this approach is that these resources cannot be used as templates for setting the actual device's resources because they are missing from the template.) The kernel's APM implementation does not suffer from this problem and registers all resources regardless of "their size". This patch fixes a problem with (at least) the vintage IBM ThinkPad 600E (and most likely also with the 600, 600X, and 770X which have a very similar layout) where some of its PnP devices support options where either an IRQ, a DMA, or an IO port is disabled. Without this patch, the devices can not be configured using the "/sys/bus/pnp/devices/*/resources" interface. The manipulation of these resources is important because the 600E has very demanding requirements. For instance, the number of IRQs is not sufficient to support all devices of the 600E. Fortunately, some of the devices, like the sound card's MPU-401 UART, can be configured to not use any IRQ, hence freeing an IRQ for a device that requires one. (Still, the device's "ResourceTemplate" requires an IRQ resource descriptor which cannot be created if the resource has not been registered in the first place.) As an example, the dependent sets of the 600E's CSC0103 device (the MPU-401 UART) are listed, with the patch applied, as: Dependent: 00 - Priority preferred port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding irq High-Edge Dependent: 01 - Priority acceptable port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding irq 5,7,2/9,10,11,15 High-Edge (The same result is obtained when PNPBIOS is used instead of PnP ACPI.) Without the patch, the IRQ resource in the preferred option is not listed at all: Dependent: 00 - Priority preferred port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding Dependent: 01 - Priority acceptable port 0x300-0x330, align 0xf, size 0x4, 16-bit address decoding irq 5,7,2/9,10,11,15 High-Edge And in fact, the 600E's DSDT lists the disabled IRQ as an option, as can be seen from the following excerpt from the DSDT: Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0300, 0x0330, 0x10, 0x04) IRQNoFlags () {} } StartDependentFn (0x01, 0x00) { IO (Decode16, 0x0300, 0x0330, 0x10, 0x04) IRQNoFlags () {5,7,9,10,11,15} } EndDependentFn () }) With this patch applied, a user space program - or maybe even the kernel - can allocate all devices' resources optimally. For the 600E, this means to find optimal resources for (at least) the serial port, the parallel port, the infrared port, the MWAVE modem, the sound card, and the MPU-401 UART. The patch applies the idea to register disabled resources to all types of resources, not just to IRQs, DMAs, and IO ports. At the same time, it mimics the behavior of the "pnp_assign_xxx" functions from "drivers/pnp/manager.c" where resources with "no size" are considered disabled. No regressions were observed on hardware that does not require this patch. The patch is applied against 2.6.39. NB: The kernel's current PnP interface does not allow for disabling individual resources using the "/sys/bus/pnp/devices/$device/resources" file. Assuming this could be done, a device could be configured to use a disabled resource using a simple series of calls: echo disable > /sys/bus/pnp/devices/$device/resources echo clear > /sys/bus/pnp/devices/$device/resources echo set irq disabled > /sys/bus/pnp/devices/$device/resources echo fill > /sys/bus/pnp/devices/$device/resources echo activate > /sys/bus/pnp/devices/$device/resources This patch addresses only the parsing of PnP ACPI devices. ChangeLog (v1 -> v2): - extend patch description - fix typo in patch itself Signed-off-by: Witold Szczeponik Cc: Len Brown Cc: Adam Belay Cc: Bjorn Helgaas Cc: Bjorn Helgaas Cc: Henrique de Moraes Holschuh Cc: Matthew Garrett Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

treewide: Convert uses of struct resource to resource_size(ptr)

2011-06-10T12:55:36Z

Several fixes as well where the +1 was missing. Done via coccinelle scripts like: @@ struct resource *ptr; @@ - ptr->end - ptr->start + 1 + resource_size(ptr) and some grep and typing. Mostly uncompiled, no cross-compilers. Signed-off-by: Joe Perches Signed-off-by: Jiri Kosina

Merge branch 'pnp' into release

2011-01-12T09:59:44Z

PNP / ACPI: Use DEVICE_ACPI_HANDLE() for device ACPI handle access

2011-01-11T20:20:40Z

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 Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Signed-off-by: Len Brown

ACPI/PNP: avoid section mismatch warning

2010-12-11T07:01:47Z

Signed-off-by: Jan Beulich Signed-off-by: Len Brown

PNP: Compile all pnp built-in stuff in one module namespace

2010-10-27T06:23:44Z

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 Signed-off-by: Bjorn Helgaas Signed-off-by: Len Brown

Merge branch 'pnpacpi-invalid-device-id' into release

2010-10-25T06:13:44Z

ACPI/PNP: A HID value of an object never changes -> make it const

2010-10-01T23:28:51Z

Signed-off-by: Thomas Renninger Signed-off-by: Len Brown

PNPACPI: cope with invalid device IDs

2010-10-01T06:08:59Z

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 Signed-off-by: Dmitry Torokhov Signed-off-by: Len Brown