21 May, 2019
1 commit
-
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
25 Feb, 2019
1 commit
-
Signed-off-by: Erik Schmauss
Signed-off-by: Bob Moore
Signed-off-by: Rafael J. Wysocki
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
08 Jul, 2017
1 commit
-
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.13 series.Some administrativa:
I have a slew of 8250 serial patches and the new IOT2040 serial+GPIO
driver coming in through this tree, along with a whole bunch of Exar
8250 fixes. These are ACKed by Greg and also hit drivers/platform/*
where they are ACKed by Andy Shevchenko.Speaking about drivers/platform/* there is also a bunch of ACPI stuff
coming through that route, again ACKed by Andy.The MCP23S08 changes are coming in here as well. You already have the
commits in your tree, so this is just a result of sharing an immutable
branch between pin control and GPIO.Core:
- Export add/remove for lookup tables so that modules can export GPIO
descriptor tables.
- Handle GPIO sleep states: it is now possible to flag that a GPIO
line may loose its state during suspend/resume of the system to
save power. This is used in the Wolfson Micro Arizona driver.
- ACPI-based GPIO was tightened up a lot around the edges.
- Use bitmap_fill() to speed up a loop.New drivers:
- Exar XRA1403 SPI-based GPIO.
- MVEBU driver now supports Armada 7K and 8K.
- LP87565 PMIC GPIO.
- Renesas R-CAR R8A7743 (RZ/G1M).
- The new IOT2040 8250 serial/GPIO also comes in through this
changeset.Substantial driver changes:
- Seriously fix the Exar 8250 GPIO portions to work.
- The MCP23S08 was moved out to a pin control driver.
- Convert MEVEBU to use regmap for register access.
- Drop Vulcan support from the Broadcom driver.
- Serious cleanup and improvement of the mockup driver, giving us a
better test coverage.Misc:
- Lots of janitorial clean up.
- A bunch of documentation fixes"* tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (70 commits)
serial: exar: Add support for IOT2040 device
gpio-exar/8250-exar: Make set of exported GPIOs configurable
platform: Accept const properties
serial: exar: Factor out platform hooks
gpio-exar/8250-exar: Rearrange gpiochip parenthood
gpio: exar: Fix iomap request
gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
serial: uapi: Add support for bus termination
gpio: rcar: Add R8A7743 (RZ/G1M) support
gpio: gpio-wcove: Fix GPIO control register offset calculation
gpio: lp87565: Add support for GPIO
gpio: dwapb: fix missing first irq for edgeboth irq type
MAINTAINERS: Take maintainership for GPIO ACPI support
gpio: exar: Fix reading of directions and values
gpio: exar: Allocate resources on behalf of the platform device
gpio-exar/8250-exar: Fix passing in of parent PCI device
gpio: mockup: use devm_kcalloc() where applicable
gpio: mockup: add myself as author
gpio: mockup: improve the error message
gpio: mockup: don't return magic numbers from probe()
...
28 Jun, 2017
1 commit
-
Currently, there are two separate ways of handling device wakeup
settings in the ACPI core, depending on whether this is runtime
wakeup or system wakeup (from sleep states). However, after the
previous commit eliminating the run_wake ACPI device wakeup flag,
there is no difference between the two any more at the ACPI level,
so they can be combined.For this reason, introduce acpi_pm_set_device_wakeup() to replace both
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it
check the ACPI device object's wakeup.valid flag to determine whether
or not the device can be set up to generate wakeup signals.Also notice that zpodd_enable/disable_run_wake() only call
device_set_run_wake() because acpi_pm_device_run_wake() called
device_run_wake(), which is not done by acpi_pm_set_device_wakeup(),
so drop the now redundant device_set_run_wake() calls from there.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas
29 May, 2017
3 commits
-
There is no point in keeping an address in the file since it's subject
to change.Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Linus Walleij -
Simply join string literals back for better maintenance and debugging.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Linus Walleij -
The PNP ACPI driver parses ACPI interrupt resource but not
GpioInt resource. When the firmware passes GpioInt resource
for IRQ the PNP ACPI driver ignores it and hence the interrupt for
the particular driver will not work.
One such example is 8042 keyboard which uses PNP driver for obtaining
the interrupt resource. On Intel Braswell project GpioInt is used
instead of interrupt resource and the keyboard driver fails to
register interrupt.
Fix the issue by parsing GpioInt resource type.Signed-off-by: Jagadish Krishnamoorthy
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
[Fixed a parenthesis coding style thing]
Signed-off-by: Linus Walleij
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