Revision tags: v2.6.38, v2.6.38-rc8 |
|
#
8b8bae90 |
| 05-Mar-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI/ACPI: Report ASPM support to BIOS if not disabled from command line
We need to distinguish the situation in which ASPM support is disabled from the command line or through .config from the situa
PCI/ACPI: Report ASPM support to BIOS if not disabled from command line
We need to distinguish the situation in which ASPM support is disabled from the command line or through .config from the situation in which it is disabled, because the hardware or BIOS can't handle it. In the former case we should not report ASPM support to the BIOS through ACPI _OSC, but in the latter case we should do that.
Introduce pcie_aspm_support_enabled() that can be used by acpi_pci_root_add() to determine whether or not it should report ASPM support to the BIOS through _OSC.
Cc: stable@kernel.org References: https://bugzilla.kernel.org/show_bug.cgi?id=29722 References: https://bugzilla.kernel.org/show_bug.cgi?id=20232 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.38-rc7, v2.6.38-rc6, v2.6.38-rc5, v2.6.38-rc4, v2.6.38-rc3, v2.6.38-rc2, v2.6.38-rc1 |
|
#
d3072e6a |
| 16-Jan-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI: Fix boot problem related to APEI with acpi_disabled set
Commit 415e12b23792 ("PCI/ACPI: Request _OSC control once for each root bridge (v3)") put the acpi_hest_init() call in acpi_pci_root_ini
ACPI: Fix boot problem related to APEI with acpi_disabled set
Commit 415e12b23792 ("PCI/ACPI: Request _OSC control once for each root bridge (v3)") put the acpi_hest_init() call in acpi_pci_root_init() into a wrong place, presumably because the author confused acpi_pci_disabled with acpi_disabled. Bring the code ordering in acpi_pci_root_init() back to sanity.
Additionally, make sure that hest_disable is set when acpi_disabled is set, which is going to prevent acpi_hest_parse(), that still may be executed for acpi_disabled=1 through aer_acpi_firmware_first(), from crashing because of uninitialized hest_tab.
Reported-and-tested-by: Andres Salomon <dilinger@queued.net> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
415e12b2 |
| 06-Jan-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI/ACPI: Request _OSC control once for each root bridge (v3)
Move the evaluation of acpi_pci_osc_control_set() (to request control of PCI Express native features) into acpi_pci_root_add() to avoid
PCI/ACPI: Request _OSC control once for each root bridge (v3)
Move the evaluation of acpi_pci_osc_control_set() (to request control of PCI Express native features) into acpi_pci_root_add() to avoid calling it many times for the same root complex with the same arguments. Additionally, check if all of the requisite _OSC support bits are set before calling acpi_pci_osc_control_set() for a given root complex.
References: https://bugzilla.kernel.org/show_bug.cgi?id=20232 Reported-by: Ozan Caglayan <ozan@pardus.org.tr> Tested-by: Ozan Caglayan <ozan@pardus.org.tr> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.37, v2.6.37-rc8, v2.6.37-rc7, v2.6.37-rc6, v2.6.37-rc5, v2.6.37-rc4, v2.6.37-rc3, v2.6.37-rc2, v2.6.37-rc1, v2.6.36, v2.6.36-rc8 |
|
#
03e7c343 |
| 08-Oct-2010 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: remove unused declaration of proc_fs.h
Remove unused declaration of proc_fs.h.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
Revision tags: v2.6.36-rc7, v2.6.36-rc6, v2.6.36-rc5, v2.6.36-rc4, v2.6.36-rc3, v2.6.36-rc2 |
|
#
28eb5f27 |
| 21-Aug-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI: PCIe: Ask BIOS for control of all native services at once
After commit 852972acff8f10f3a15679be2059bb94916cba5d (ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe) control
PCI: PCIe: Ask BIOS for control of all native services at once
After commit 852972acff8f10f3a15679be2059bb94916cba5d (ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe) control of the PCIe Capability Structure is unconditionally requested by acpi_pci_root_add(), which in principle may cause problems to happen in two ways. First, the BIOS may refuse to give control of the PCIe Capability Structure if it is not asked for any of the _OSC features depending on it at the same time. Second, the BIOS may assume that control of the _OSC features depending on the PCIe Capability Structure will be requested in the future and may behave incorrectly if that doesn't happen. For this reason, control of the PCIe Capability Structure should always be requested along with control of any other _OSC features that may depend on it (ie. PCIe native PME, PCIe native hot-plug, PCIe AER).
Rework the PCIe port driver so that (1) it checks which native PCIe port services can be enabled, according to the BIOS, and (2) it requests control of all these services simultaneously. In particular, this causes pcie_portdrv_probe() to fail if the BIOS refuses to grant control of the PCIe Capability Structure, which means that no native PCIe port services can be enabled for the PCIe Root Complex the given port belongs to. If that happens, ASPM is disabled to avoid problems with mishandling it by the part of the PCIe hierarchy for which control of the PCIe Capability Structure has not been received.
Make it possible to override this behavior using 'pcie_ports=native' (use the PCIe native services regardless of the BIOS response to the control request), or 'pcie_ports=compat' (do not use the PCIe native services at all).
Accordingly, rework the existing PCIe port service drivers so that they don't request control of the services directly.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
75fb60f2 |
| 23-Aug-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI/PCI: Negotiate _OSC control bits before requesting them
It is possible that the BIOS will not grant control of all _OSC features requested via acpi_pci_osc_control_set(), so it is recommended
ACPI/PCI: Negotiate _OSC control bits before requesting them
It is possible that the BIOS will not grant control of all _OSC features requested via acpi_pci_osc_control_set(), so it is recommended to negotiate the final set of _OSC features with the query flag set before calling _OSC to request control of these features.
To implement it, rework acpi_pci_osc_control_set() so that the caller can specify the mask of _OSC control bits to negotiate and the mask of _OSC control bits that are absolutely necessary to it. Then, acpi_pci_osc_control_set() will run _OSC queries in a loop until the mask of _OSC control bits returned by the BIOS is equal to the mask passed to it. Also, before running the _OSC request acpi_pci_osc_control_set() will check if the caller's required control bits are present in the final mask.
Using this mechanism we will be able to avoid situations in which the BIOS doesn't grant control of certain _OSC features, because they depend on some other _OSC features that have not been requested.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
2b8fd918 |
| 23-Aug-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI/PCI: Do not preserve _OSC control bits returned by a query
There is the assumption in acpi_pci_osc_control_set() that it is always sufficient to compare the mask of _OSC control bits to be req
ACPI/PCI: Do not preserve _OSC control bits returned by a query
There is the assumption in acpi_pci_osc_control_set() that it is always sufficient to compare the mask of _OSC control bits to be requested with the result of an _OSC query where all of the known control bits have been checked. However, in general, that need not be the case. For example, if an _OSC feature A depends on an _OSC feature B and control of A, B plus another _OSC feature C is requested simultaneously, the BIOS may return A, B, C, while it would only return C if A and C were requested without B.
That may result in passing a wrong mask of _OSC control bits to an _OSC control request, in which case the BIOS may only grant control of a subset of the requested features. Moreover, acpi_pci_run_osc() will return error code if that happens and the caller of acpi_pci_osc_control_set() will not know that it's been granted control of some _OSC features. Consequently, the system will generally not work as expected.
Apart from this acpi_pci_osc_control_set() always uses the mask of _OSC control bits returned by the very first invocation of acpi_pci_query_osc(), but that is done with the second argument equal to OSC_PCI_SEGMENT_GROUPS_SUPPORT which generally happens to affect the returned _OSC control bits.
For these reasons, make acpi_pci_osc_control_set() always check if control of the requested _OSC features will be granted before making the final control request. As a result, the osc_control_qry and osc_queried members of struct acpi_pci_root are not necessary any more, so drop them and remove the remaining code referring to them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
ab8e8957 |
| 20-Aug-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI/PCI: Make acpi_pci_query_osc() return control bits
Make acpi_pci_query_osc() use an additional pointer argument to return the mask of control bits obtained from the BIOS to the caller.
Signed-
ACPI/PCI: Make acpi_pci_query_osc() return control bits
Make acpi_pci_query_osc() use an additional pointer argument to return the mask of control bits obtained from the BIOS to the caller.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
b879dc4b |
| 20-Aug-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI/PCI: Reorder checks in acpi_pci_osc_control_set()
Make acpi_pci_osc_control_set() attempt to find the handle of the _OSC object under the given PCI root bridge object after verifying that its s
ACPI/PCI: Reorder checks in acpi_pci_osc_control_set()
Make acpi_pci_osc_control_set() attempt to find the handle of the _OSC object under the given PCI root bridge object after verifying that its second argument is correct and that there is a struct acpi_pci_root object for the given root bridge handle, which is more logical than the old code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.36-rc1, v2.6.35, v2.6.35-rc6, v2.6.35-rc5, v2.6.35-rc4 |
|
#
852972ac |
| 22-Jun-2010 |
Matthew Garrett <mjg@redhat.com> |
ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe
The PCI SIG documentation for the _OSC OS/firmware handshaking interface states:
"If the _OSC control method is absent from th
ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe
The PCI SIG documentation for the _OSC OS/firmware handshaking interface states:
"If the _OSC control method is absent from the scope of a host bridge device, then the operating system must not enable or attempt to use any features defined in this section for the hierarchy originated by the host bridge."
The obvious interpretation of this is that the OS should not attempt to use PCIe hotplug, PME or AER - however, the specification also notes that an _OSC method is *required* for PCIe hierarchies, and experimental validation with An Alternative OS indicates that it doesn't use any PCIe functionality if the _OSC method is missing. That arguably means we shouldn't be using MSI or extended config space, but right now our problems seem to be limited to vendors being surprised when ASPM gets enabled on machines when other OSs refuse to do so. So, for now, let's just disable ASPM if the _OSC method doesn't exist or refuses to hand over PCIe capability control.
Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.35-rc3, v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3, v2.6.34-rc2 |
|
#
57283776 |
| 11-Mar-2010 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: pass acpi_pci_root to arch-specific scan
The acpi_pci_root structure contains all the individual items (acpi_device, domain, bus number) we pass to pci_acpi_scan_root(), so just pass
ACPI: pci_root: pass acpi_pci_root to arch-specific scan
The acpi_pci_root structure contains all the individual items (acpi_device, domain, bus number) we pass to pci_acpi_scan_root(), so just pass the single acpi_pci_root pointer directly.
This will make it easier to add _CBA support later. For _CBA, we need the entire downstream bus range, not just the base bus number. We have that in the acpi_pci_root structure, so passing the pointer makes it available to the arch-specific code.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
6ad95513 |
| 11-Mar-2010 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: save downstream bus range
Previously, we only saved the root bus number, i.e., the beginning of the downstream bus range. We now support IORESOURCE_BUS resources, so this patch uses
ACPI: pci_root: save downstream bus range
Previously, we only saved the root bus number, i.e., the beginning of the downstream bus range. We now support IORESOURCE_BUS resources, so this patch uses that to keep track of both the beginning and the end of the downstream bus range.
It's important to know both the beginning and the end for supporting _CBA (see PCI Firmware spec, rev 3.0, sec 4.1.3) and so we know the limits for any possible PCI bus renumbering (we can't renumber downstream buses to be outside the bus number range claimed by the host bridge).
It's clear from the spec that the bus range is supposed to be in _CRS, but if we don't find it there, we'll assume [_BBN - 0xFF] or [0 - 0xFF].
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
5a0e3ad6 |
| 24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being included when bu
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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>
show more ...
|
Revision tags: v2.6.34-rc1, v2.6.33 |
|
#
7bc5e3f2 |
| 23-Feb-2010 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
x86/PCI: use host bridge _CRS info by default on 2008 and newer machines
The main benefit of using ACPI host bridge window information is that we can do better resource allocation in systems with mu
x86/PCI: use host bridge _CRS info by default on 2008 and newer machines
The main benefit of using ACPI host bridge window information is that we can do better resource allocation in systems with multiple host bridges, e.g., http://bugzilla.kernel.org/show_bug.cgi?id=14183
Sometimes we need _CRS information even if we only have one host bridge, e.g., https://bugs.launchpad.net/ubuntu/+source/linux/+bug/341681
Most of these systems are relatively new, so this patch turns on "pci=use_crs" only on machines with a BIOS date of 2008 or newer.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
b67ea761 |
| 17-Feb-2010 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI / ACPI / PM: Platform support for PCI PME wake-up
Although the majority of PCI devices can generate PMEs that in principle may be used to wake up devices suspended at run time, platform support
PCI / ACPI / PM: Platform support for PCI PME wake-up
Although the majority of PCI devices can generate PMEs that in principle may be used to wake up devices suspended at run time, platform support is generally necessary to convert PMEs into wake-up events that can be delivered to the kernel. If ACPI is used for this purpose, PME signals generated by a PCI device will trigger the ACPI GPE associated with the device to generate an ACPI wake-up event that we can set up a handler for, provided that everything is configured correctly.
Unfortunately, the subset of PCI devices that have GPEs associated with them is quite limited. The devices without dedicated GPEs have to rely on the GPEs associated with other devices (in the majority of cases their upstream bridges and, possibly, the root bridge) to generate ACPI wake-up events in response to PME signals from them.
Add ACPI platform support for PCI PME wake-up: o Add a framework making is possible to use ACPI system notify handlers for run-time PM. o Add new PCI platform callback ->run_wake() to struct pci_platform_pm_ops allowing us to enable/disable the platform to generate wake-up events for given device. Implemet this callback for the ACPI platform. o Define ACPI wake-up handlers for PCI devices and PCI root buses and make the PCI-ACPI binding code register wake-up notifiers for all PCI devices present in the ACPI tables. o Add function pci_dev_run_wake() which can be used by PCI drivers to check if given device is capable of generating wake-up events at run time.
Developed in cooperation with Matthew Garrett <mjg@redhat.com>.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.33-rc8, v2.6.33-rc7, v2.6.33-rc6, v2.6.33-rc5, v2.6.33-rc4 |
|
#
c97adf9e |
| 10-Jan-2010 |
Márton Németh <nm127@freemail.hu> |
acpi: make ACPI device id constant
The ids field of the struct acpi_driver is constant in <linux/acpi/acpi_bus.h> so it is worth to make the initialization data also constant.
The semantic match th
acpi: make ACPI device id constant
The ids field of the struct acpi_driver is constant in <linux/acpi/acpi_bus.h> so it is worth to make the initialization data also constant.
The semantic match that finds this kind of pattern is as follows: (http://coccinelle.lip6.fr/)
// <smpl> @r@ disable decl_init,const_decl_init; identifier I1, I2, x; @@ struct I1 { ... const struct I2 *x; ... }; @s@ identifier r.I1, y; identifier r.x, E; @@ struct I1 y = { .x = E, }; @c@ identifier r.I2; identifier s.E; @@ const struct I2 E[] = ... ; @depends on !c@ identifier r.I2; identifier s.E; @@ + const struct I2 E[] = ...; // </smpl>
Signed-off-by: Márton Németh <nm127@freemail.hu> Cc: Julia Lawall <julia@diku.dk> Cc: cocci@diku.dk Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.33-rc3, v2.6.33-rc2, v2.6.33-rc1, v2.6.32, v2.6.32-rc8, v2.6.32-rc7, v2.6.32-rc6 |
|
#
3a9622dc |
| 28-Oct-2009 |
Shaohua Li <shaohua.li@intel.com> |
ACPI: cleanup pci_root _OSC code.
Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
Revision tags: v2.6.32-rc5 |
|
#
497fb54f |
| 12-Oct-2009 |
Rafael J. Wysocki <rjw@sisk.pl> |
ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)
acpi_get_pci_dev() may be called for a non-PCI device, in which case it should return NULL. However, it assumes that every ha
ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)
acpi_get_pci_dev() may be called for a non-PCI device, in which case it should return NULL. However, it assumes that every handle it finds in the ACPI CA name space, between given device handle and the PCI root bridge handle, corresponds to a PCI-to-PCI bridge with an existing secondary bus. For this reason, when it finds a struct pci_dev object corresponding to one of them, it doesn't check if its 'subordinate' field is a valid pointer. This obviously leads to a NULL pointer dereference if acpi_get_pci_dev() is called for a non-PCI device with a PCI parent which is not a bridge.
To fix this issue make acpi_get_pci_dev() check if pdev->subordinate is not NULL for every device it finds on the path between the root bridge and the device it's supposed to get to and return NULL if the "target" device cannot be found.
http://bugzilla.kernel.org/show_bug.cgi?id=14129 (worked in 2.6.30, regression in 2.6.31)
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Danny Feng <dfeng@redhat.com> Reviewed-by: Alex Chiang <achiang@hp.com> Tested-by: chepioq <chepioq@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.32-rc4, v2.6.32-rc3, v2.6.32-rc1, v2.6.32-rc2, v2.6.31, v2.6.31-rc9, v2.6.31-rc8, v2.6.31-rc7, v2.6.31-rc6, v2.6.31-rc5 |
|
#
76d56de5 |
| 23-Jul-2009 |
Alex Chiang <achiang@hp.com> |
ACPI: export acpi_pci_root and friends
We can simplify ACPI drivers if we can tell whether a handle is an ACPI PCI root or not.
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Alex
ACPI: export acpi_pci_root and friends
We can simplify ACPI drivers if we can tell whether a handle is an ACPI PCI root or not.
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
a192a958 |
| 28-Jul-2009 |
Len Brown <len.brown@intel.com> |
ACPI: Move definition of PREFIX from acpi_bus.h to internal..h
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #u
ACPI: Move definition of PREFIX from acpi_bus.h to internal..h
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own.
Add GPL commment to internal.h while we are there.
This does not change any actual console output, asside from a whitespace fix.
Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.31-rc4, v2.6.31-rc3, v2.6.31-rc2 |
|
#
412af978 |
| 25-Jun-2009 |
Troy Moure <twmoure@szypr.net> |
ACPI: video: prevent NULL deref in acpi_get_pci_dev()
ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468
When the ACPI video driver initializes, it does a namespace walk looking fo
ACPI: video: prevent NULL deref in acpi_get_pci_dev()
ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468
When the ACPI video driver initializes, it does a namespace walk looking for for supported devices. When we find an appropriate handle, we walk up the ACPI tree looking for a PCI root bus, and then walk back down the PCI bus, assuming that every device inbetween is a P2P bridge.
This assumption is not correct, and is reported broken on at least:
Dell Latitude E6400 ThinkPad X61 Dell XPS M1330
Add a NULL deref check to prevent boot panics.
Reported-by: Alessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: Troy Moure <twmoure@szypr.net> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.31-rc1 |
|
#
0705495d |
| 18-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: remove unused dev/fn information
We never use the PCI device & function number, so remove it to make it clear that it's not needed. Many PCI host bridges don't even appear in config
ACPI: pci_root: remove unused dev/fn information
We never use the PCI device & function number, so remove it to make it clear that it's not needed. Many PCI host bridges don't even appear in config space, so it's meaningless to look at stuff from _ADR, which doesn't exist in that case.
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>
show more ...
|
#
c1aec834 |
| 18-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: simplify list traversals
Using list_for_each_entry() makes traversing the root list easier.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.
ACPI: pci_root: simplify list traversals
Using list_for_each_entry() makes traversing the root list easier.
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>
show more ...
|
#
caf420c6 |
| 18-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: use driver data rather than list lookup
There's no need to search the list to find the acpi_pci_root structure. We saved it as device->driver_data when we added the device.
Signed-
ACPI: pci_root: use driver data rather than list lookup
There's no need to search the list to find the acpi_pci_root structure. We saved it as device->driver_data when we added the device.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
#
f5eebbe1 |
| 18-Jun-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: pci_root: simplify acpi_pci_root_add() control flow
By looking up the segment & bus number earlier, we don't have to worry about cleaning up if it fails.
Signed-off-by: Bjorn Helgaas <bjorn.h
ACPI: pci_root: simplify acpi_pci_root_add() control flow
By looking up the segment & bus number earlier, we don't have to worry about cleaning up if it fails.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|