10 Mar, 2016
1 commit
-
An error message is printed for resources of type 19, which is a valid
supported resource type. The Firmware Test Suite tool (fwts) reports
this as a test failure. This change fixes the false test failures
for ASL that use type 19 (ACPI_RESOURCE_TYPE_SERIAL_BUS) resources.Signed-off-by: Harb Abdulhamid
Signed-off-by: Timur Tabi
Signed-off-by: Rafael J. Wysocki
15 Sep, 2015
1 commit
-
This is preparation for using kstrdup_const to initialize that member.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Rafael J. Wysocki
06 May, 2015
2 commits
-
use unsigned int for port, irq, dma and mem used for pnp_get_resource()
This fixes gcc warnings of type "conversion to unsigned int
from int may change the sign of the result"Signed-off-by: Fabian Frederick
Signed-off-by: Rafael J. Wysocki -
acpi_resource_extented_irq variables are all u8.
Use that type for triggering, polarity and shareable.
This fixes gcc warnings of type
"conversion to u8 from int may alter its value"Signed-off-by: Fabian Frederick
Signed-off-by: Rafael J. Wysocki
16 Mar, 2015
1 commit
-
pnpacpi_add_device() calls acpi_bind_one() on an already registered
device, which is a mistake, but it can initialize the ACPI companion
field of the struct device to be registered using ACPI_COMPANION_SET()
instead, so make it do that.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
04 Feb, 2015
1 commit
-
Change function acpi_dev_resource_address_space() and
acpi_dev_resource_ext_address_space() to return address space
translation offset.It's based on a patch from Yinghai Lu .
Signed-off-by: Jiang Liu
Signed-off-by: Rafael J. Wysocki
26 Jan, 2015
1 commit
-
struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
arch/ia64/kernel/acpi-ext.c
arch/ia64/pci/pci.c
arch/x86/pci/acpi.c
arch/x86/pci/mmconfig-shared.c
drivers/xen/xen-acpi-memhotplug.c
drivers/acpi/acpi_memhotplug.c
drivers/acpi/pci_root.c
drivers/acpi/resource.c
drivers/char/hpet.c
drivers/pnp/pnpacpi/rsparser.c
drivers/hv/vmbus_drv.cBuild tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.Original-by: Thomas Gleixner
Original-by: Jiang Liu
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
23 Jul, 2014
1 commit
-
The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.Do that in several places in the ACPI PNP core code.
Also use acpi_device_set_power() and acpi_device_power_manageable()
instead of acpi_bus_set_power() and acpi_bus_power_manageable(),
respectively, because the former two are more efficient if the
ACPI device object is already available.Signed-off-by: Rafael J. Wysocki
07 Jul, 2014
1 commit
-
PNPACPI uses acpi_bus_type to do ACPI binding for the PNPACPI devices.
This is overkill because PNPACPI code already knows which ACPI
device object to bind during PNPACPI device enumeration.This patch removes acpi_pnp_bus and does the binding by invoking
acpi_bind_one() directly after device enumerated.This also fixes a bug in the previous code that some PNPACPI devices failed
to be bound because
1. the ACPI device _HID is not pnpid, e.g. "MSFT0001", but its _CID is,
e.g. "PNP0303", thus ACPI _CID is used as the pnp device device id.
2. device is bound only if the pnp device id matches the ACPI device _HID.Tested-by: Prigent Christophe
Signed-off-by: Zhang Rui
Signed-off-by: Rafael J. Wysocki
30 May, 2014
1 commit
-
ACPI can be used to enumerate PNP devices, but the code does not
handle this in the right way currently. Namely, if an ACPI device
object
1. Has a _CRS method,
2. Has an identification of
"three capital characters followed by four hex digits",
3. Is not in the excluded IDs list,
it will be enumerated to PNP bus (that is, a PNP device object will
be create for it). This means that, actually, the PNP bus type is
used as the default bus type for enumerating _HID devices in ACPI.However, more and more _HID devices need to be enumerated to the
platform bus instead (that is, platform device objects need to be
created for them). As a result, the device ID list in acpi_platform.c
is used to enforce creating platform device objects rather than PNP
device objects for matching devices. That list has been continuously
growing recently, unfortunately, and it is pretty much guaranteed to
grow even more in the future.To address that problem it is better to enumerate _HID devices
as platform devices by default. To this end, change the way of
enumerating PNP devices by adding a PNP ACPI scan handler that
will use a device ID list to create PNP devices for the ACPI
device objects whose device IDs are present in that list.The initial device ID list in the PNP ACPI scan handler contains
all of the pnp_device_id strings from all the existing PNP drivers,
so this change should be transparent to the PNP core and all of the
PNP drivers. Still, in the future it should be possible to reduce
its size by converting PNP drivers that need not be PNP for any
technical reasons into platform drivers.Signed-off-by: Zhang Rui
[rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
01 May, 2014
1 commit
-
The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
present, respectively, but it should not do that, because those
methods are optional. For this reason, modify pnpacpi_set_resources()
and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
or _DIS.This problem has been uncovered by commit 202317a573b2 (ACPI / scan:
Add acpi_device objects for all device nodes in the namespace) and
manifested itself by causing serial port suspend to fail on some
systems.Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
Reported-by: wxg4net
Reported-and-tested-by:
Cc: 3.14+ # 3.14+
Signed-off-by: Rafael J. Wysocki
12 Mar, 2014
1 commit
-
Before commit b355cee88e3b (ACPI / resources: ignore invalid ACPI
device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io()
returns false, it means the the resource is not a memeory/IO resource.But after commit b355cee88e3b, those functions return false if the
given memory/IO resource entry is invalid (the length of the resource
is zero).This breaks pnpacpi_allocated_resource(), because it now recognizes
the invalid memory/io resources as resources of unknown type. Thus
users see confusing warning messages on machines with zero length
ACPI memory/IO resources.Fix the problem by rearranging pnpacpi_allocated_resource() so that
it calls acpi_dev_resource_memory() for memory type and IO type
resources only, respectively.Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Zhang Rui
Reported-and-tested-by: Markus Trippelsdorf
Reported-and-tested-by: Julian Wollrath
Reported-and-tested-by: Paul Bolle
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
13 Jan, 2014
1 commit
-
* pnp:
PNPBIOS: check return value of pnp_add_device()
PNP: Mark the function pnp_build_option() as static in resource.c
PNP / card: add missing put_device() call
PNPACPI: check return value of pnp_add_device()
23 Dec, 2013
1 commit
-
pnp_add_device() may fail so we need to handle errors and avoid leaking
memory. Also, do not use ACPI-specific return codes (AE_OK) but rather
standard one (0).Signed-off-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki
07 Dec, 2013
2 commits
-
Replace the .find_device function pointer in struct acpi_bus_type
with a new one, .find_companion, that is supposed to point to a
function returning struct acpi_device pointer (instead of an int)
and takes one argument (instead of two). This way the role of
this callback is more clear and the implementation of it can
be more straightforward.Update all of the users of struct acpi_bus_type (PCI, PNP/ACPI and
USB) to reflect the structure change.Signed-off-by: Rafael J. Wysocki
Tested-by: Lan Tianyu # for USB/ACPI -
Replace direct inclusions of , and
, which are incorrect, with
inclusions and remove some inclusions of those files that aren't
necessary.First of all, , and
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.Second, there are ordering dependencies between those files that always
have to be met. Namely, it is required that be included
prior to so that the acpi_pci_root declarations the
latter depends on are always there. And which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds. That also is taken care of including
as appropriate.Signed-off-by: Lv Zheng
Cc: Greg Kroah-Hartman
Cc: Matthew Garrett
Cc: Tony Luck
Cc: "H. Peter Anvin"
Acked-by: Bjorn Helgaas (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
Signed-off-by: Rafael J. Wysocki
15 Nov, 2013
1 commit
-
Since DEVICE_ACPI_HANDLE() is now literally identical to
ACPI_HANDLE(), replace it with the latter everywhere and drop its
definition from include/acpi.h.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
24 Sep, 2013
1 commit
-
acpi_has_method() is a new ACPI API introduced to check
the existence of an ACPI control method.It can be used to replace acpi_get_handle() in the case that
1. the calling function doesn't need the ACPI handle of the control method.
and
2. the calling function doesn't care the reason why the method is unavailable.Convert acpi_get_handle() to acpi_has_method()
in drivers/pnp/pnpacpi/core.c in this patch.Signed-off-by: Zhang Rui
CC: Bjorn Helgaas
Signed-off-by: Rafael J. Wysocki
30 Jul, 2013
1 commit
-
There are several places in the tree where ACPI_STATE_D3 is used
instead of ACPI_STATE_D3_COLD which should be used instead for
clarity. Modify them all to use ACPI_STATE_D3_COLD as appropriate.[The definition of ACPI_STATE_D3 itself cannot go away at this point
as it is part of ACPICA.]Signed-off-by: Rafael J. Wysocki
Reviewed-by: Aaron Lu
18 Jul, 2013
1 commit
-
Set temporary variable as 0 to avoid garbage string output from
/proc/iomem after register resources and reset to PNP dev name
later.Signed-off-by: Liu ShuoX
Signed-off-by: Rafael J. Wysocki
24 Mar, 2013
1 commit
-
Found with a network device in QEMU/KVM guest not working anymore.
Bisected to commit c13085e5
ACPICA: Resource Mgr: Prevent infinite loops in resource walksThat commit will check acpi_resource length strictly which causes
acpi_set_current_resources to return failure and IRQ for PCI
devices is not set properly.Set length for all those TYPE_END_TAG acpi_resources.
[rjw: Changelog]
Bisected-by: Yinghai Lu
Signed-off-by: Yinghai Lu
Signed-off-by: Rafael J. Wysocki
04 Mar, 2013
1 commit
-
USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection.What USB actually needs, though, is to call usb_acpi_find_device()
for USB ports that don't have a bus type defined, but have
usb_port_device_type as their device type, as well as for USB
devices.To fix that replace the struct bus_type pointer in struct
acpi_bus_type used for matching devices to specific subsystems
with a .match() callback to be used for this purpose and update
the users of struct acpi_bus_type, including USB, accordingly.
Define the .match() callback routine for USB, usb_acpi_bus_match(),
in such a way that it will cover both USB devices and USB ports
and remove the now redundant .find_bridge() callback pointer from
usb_acpi_bus.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Acked-by: Yinghai Lu
Acked-by: Jeff Garzik
01 Feb, 2013
1 commit
-
acpi_bus_get_device() returns int not acpi_status.
The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Rafael J. Wysocki
08 Dec, 2012
2 commits
-
* acpi-general:
pnpacpi: fix incorrect TEST_ALPHA() test
ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
ACPI : do not use Lid and Sleep button for S5 wakeup -
TEST_ALPHA() is broken and always returns 0.
[akpm@linux-foundation.org: return false for '@' as well, per Bjorn]
Signed-off-by: Alan Cox
Signed-off-by: Andrew Morton
Cc:
Signed-off-by: Rafael J. Wysocki
04 Dec, 2012
1 commit
-
* acpi-general:
ACPI / PNP: Do not crash due to stale pointer use during system resume
ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist
ACPI: do acpisleep dmi check when CONFIG_ACPI_SLEEP is set
30 Nov, 2012
1 commit
-
During resume from system suspend the 'data' field of
struct pnp_dev in pnpacpi_set_resources() may be a stale pointer,
due to removal of the associated ACPI device node object in the
previous suspend-resume cycle. This happens, for example, if a
dockable machine is booted in the docking station and then suspended
and resumed and suspended again. If that happens,
pnpacpi_build_resource_template() called from pnpacpi_set_resources()
attempts to use that pointer and crashes.However, pnpacpi_set_resources() actually checks the device's ACPI
handle, attempts to find the ACPI device node object attached to it
and returns an error code if that fails, so in fact it knows what the
correct value of dev->data should be. Use this observation to update
dev->data with the correct value if necessary and dump a call trace
if that's the case (once).We still need to fix the root cause of this issue, but preventing
systems from crashing because of it is an improvement too.Reported-and-tested-by: Zdenek Kabelac
References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
Cc:
Signed-off-by: Rafael J. Wysocki
24 Nov, 2012
1 commit
-
Make pnpacpi_add_device() ignore ACPI device nodes already associated
with struct device objects representing physical devices.In particular, this will prevent PNP device objects from being
created for ACPI device nodes already associated with platform
devices.This change was originally proposed by Mika Westerberg.
[rjw: Modified the subject and changelog.]
Signed-off-by: Adrian Hunter
Signed-off-by: Rafael J. Wysocki
15 Nov, 2012
1 commit
-
Move some code used for parsing ACPI device resources from the PNP
subsystem to the ACPI core, so that other bus types (platform, SPI,
I2C) can use the same routines for parsing resources in a consistent
way, without duplicating code.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
Tested-by: Mika Westerberg
22 Sep, 2012
1 commit
-
A USB port's position and connectability can't be identified on some boards
via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue
and so it is necessary to bind USB with ACPI. This patch is to allow ACPI
binding with USB-3.0 hub.Current ACPI only can bind one struct-device to one ACPI device node.
This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical
devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem,
those two logical hubs are treated as two seperate devices that have two struct
devices. But in the ACPI DSDT, these two logical hubs share one ACPI device
node. So there is a requirement to bind multi struct-devices to one ACPI
device node. This patch is to resolve such problem.Following is the ACPI device nodes' description under xhci hcd.
Device (XHC)
Device (RHUB)
Device (HSP1)
Device (HSP2)
Device (HSP3)
Device (HSP4)
Device (SSP1)
Device (SSP2)
Device (SSP3)
Device (SSP4)Topology in the Linux
device XHC
USB-2.0 logical hub USB-3.0 logical hub
HSP1 SSP1
HSP2 SSP2
HSP3 SSP3
HSP4 SSP4This patch also modifies the output of /proc/acpi/wakeup. One ACPI node
can be associated with multiple devices:XHC S4 *enabled pci:0000:00:14.0
RHUB S0 disabled usb:usb1
disabled usb:usb2Signed-off-by: Lan Tianyu
Acked-by: Sarah Sharp
Signed-off-by: Len Brown
24 Jun, 2012
1 commit
-
Lower device sleep state can save more power, but has more exit
latency too. Sometimes, to satisfy some power QoS and other
requirement, we need to constrain the lowest device sleep state.In this patch, a parameter to specify lowest allowed state for
acpi_pm_device_sleep_state is added. So that the caller can enforce
the constraint via the parameter.This is needed by PCIe D3cold support, where the lowest power state
allowed may be D3_HOT instead of default D3_COLD.CC: Len Brown
CC: linux-acpi@vger.kernel.org
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Huang Ying
Signed-off-by: Bjorn Helgaas
30 Mar, 2012
1 commit
-
During testing pci root bus removal, found some root bus bridge is not freed.
If booting with pnpacpi=off, those hostbridge could be freed without problem.
It turns out that some devices reference are not released during acpi_pnp_match.
that match should not hold one device ref during every calling.
Add pu_device calling before returning.Signed-off-by: Yinghai Lu
Cc: stable@vger.kernel.org
Signed-off-by: Len Brown
08 Nov, 2011
1 commit
-
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
cpuidle: Single/Global registration of idle states
cpuidle: Split cpuidle_state structure and move per-cpu statistics fields
cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
cpuidle: Move dev->last_residency update to driver enter routine; remove dev->last_state
ACPI: Fix CONFIG_ACPI_DOCK=n compiler warning
ACPI: Export FADT pm_profile integer value to userspace
thermal: Prevent polling from happening during system suspend
ACPI: Drop ACPI_NO_HARDWARE_INIT
ACPI atomicio: Convert width in bits to bytes in __acpi_ioremap_fast()
PNPACPI: Simplify disabled resource registration
ACPI: Fix possible recursive locking in hwregs.c
ACPI: use kstrdup()
mrst pmu: update comment
tools/power turbostat: less verbose debugging
07 Nov, 2011
1 commit
-
The attached patch simplifies 29df8d8f8702f0f53c1375015f09f04bc8d023c1. As
the "pnp_xxx" structs are not designed to cope with IORESOURCE_DISABLED, and
hence no code can test for this value, setting this value is actually a "no op"
and can be skipped altogether. It is sufficient to remove the checks for
"empty" resources and continue processing.The patch is applied against 3.1.
Signed-off-by: Witold Szczeponik
Acked-by: Bjorn Helgaas
Signed-off-by: Len Brown
01 Nov, 2011
1 commit
-
These macros are no longer in module.h and module.h is no longer
present everywhere. Call out export.h for the users who are
making use of these macros.Signed-off-by: Paul Gortmaker
26 Jul, 2011
2 commits
-
* 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. -
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-EdgeAnd 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/resourcesThis patch addresses only the parsing of PnP ACPI devices.
ChangeLog (v1 -> v2):
- extend patch description
- fix typo in patch itselfSigned-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
10 Jun, 2011
1 commit
-
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
12 Jan, 2011
2 commits
-
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
