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
07 Jun, 2017
1 commit
-
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use guid_t type. At the same time we
convert current users.acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.Acked-by: Rafael J. Wysocki
Cc: Borislav Petkov
Acked-by: Dan Williams
Cc: Amir Goldstein
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Jani Nikula
Acked-by: Jani Nikula
Cc: Ben Skeggs
Acked-by: Benjamin Tissoires
Acked-by: Joerg Roedel
Acked-by: Adrian Hunter
Cc: Yisen Zhuang
Acked-by: Bjorn Helgaas
Acked-by: Felipe Balbi
Acked-by: Mathias Nyman
Reviewed-by: Heikki Krogerus
Acked-by: Mark Brown
Signed-off-by: Andy Shevchenko
Signed-off-by: Christoph Hellwig
07 Dec, 2016
1 commit
-
pci_mcfg_lookup() is the external interface to the generic MCFG code.
Previously it merely looked up the ECAM base address for a given domain and
bus range. We want a way to add MCFG quirks, some of which may require
special config accessors and adjustments to the ECAM address range.Extend pci_mcfg_lookup() so it can return a pointer to a pci_ecam_ops
structure and a struct resource for the ECAM address space. For now, it
always returns &pci_generic_ecam_ops (the standard accessor) and the
resource described by the MCFG.No functional changes intended.
[bhelgaas: changelog]
Signed-off-by: Tomasz Nowicki
Signed-off-by: Bjorn Helgaas
11 Jun, 2016
1 commit
-
On ACPI systems that support memory-mapped config space access, i.e., ECAM,
the PCI Firmware Specification says the OS can learn where the ECAM space
is from either:- the static MCFG table (for non-hotpluggable bridges), or
- the _CBA method (for hotpluggable bridges)The current MCFG table handling code cannot be easily generalized owing to
x86-specific quirks, which makes it hard to reuse on other architectures.Implement generic MCFG handling from scratch, including:
- Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86)
- MCFG region lookup for a (domain, bus_start, bus_end) tuple[bhelgaas: changelog]
Signed-off-by: Tomasz Nowicki
Signed-off-by: Jayachandran C
Signed-off-by: Bjorn Helgaas
Reviewed-by: Lorenzo Pieralisi
17 Oct, 2015
1 commit
-
Introduce common interface acpi_pci_root_create() and related data
structures to create PCI root bus for ACPI PCI host bridges. It will
be used to kill duplicated arch specific code for IA64 and x86. It may
also help ARM64 in future.Reviewed-by: Lorenzo Pieralisi
Tested-by: Tony Luck
Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
Signed-off-by: Rafael J. Wysocki
09 Apr, 2015
2 commits
-
The PCI "ACPI additions for FW latency optimizations" ECN (link below)
defines two functions in the PCI _DSM:Function 8, "Reset Delay," applies to the entire hierarchy below a PCI
host bridge. If it returns one, the OS may assume that all devices in
the hierarchy have already completed power-on reset delays.Function 9, "Device Readiness Durations," applies only to the object
where it is located. It returns delay durations required after various
events if the device requires less time than the spec requires. Delays
from this function take precedence over the Reset Delay function.Add support for Reset Delay and part of Device Readiness Durations.
[bhelgaas: changelog, comments]
Link: https://www.pcisig.com/specifications/conventional/pci_firmware/ECN_fw_latency_optimization_final.pdf
Signed-off-by: Aaron Lu
Signed-off-by: Bjorn Helgaas -
The PCI Firmware Specification, r3.0, sec 4.6.4.1.3, defines a single UUID
for an ACPI _DSM method to provide device-specific control functions. This
_DSM method support several functions, including PCI Express Slot
Information, PCI Express Slot Number, PCI Bus Capabilities, etc.Move the UUID definition from pci/pci-label.c, where it could be used only
for one function, to pci/pci-acpi.c where it can be shared for all these
functions.[bhelgaas: changelog]
Signed-off-by: Aaron Lu
Signed-off-by: Bjorn Helgaas
Acked-by: Rafael J. Wysocki
06 Nov, 2014
1 commit
-
acpi_pci_get_bridge_handle() returns the ACPI handle for the bridge device
(either a host bridge or a PCI-to-PCI bridge) leading to a PCI bus. But
SR-IOV virtual functions can be on a virtual bus with no bridge leading to
it. Return a NULL acpi_handle in this case instead of trying to
dereference the NULL pointer to the bridge.This fixes a NULL pointer dereference oops in pci_get_hp_params() when
adding SR-IOV VF devices on virtual buses.[bhelgaas: changelog, add comment in code]
Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=87591
Reported-by: Chao Zhou
Reported-by: Joerg Roedel
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
23 Jul, 2014
1 commit
-
Since ACPI wakeup GPEs are going to be enabled during system suspend
as well as for runtime wakeup by a subsequent patch and the same
notify handlers will be used in both cases, rework the ACPI device
wakeup notification framework so that the part specific to physical
devices is always run asynchronously from the PM workqueue. This
prevents runtime resume callbacks for those devices from being
run during system suspend and resume which may not be appropriate,
among other things.Also make ACPI device wakeup notification handling a bit more robust
agaist subsequent removal of ACPI device objects, whould that ever
happen, and create a wakeup source object for each ACPI device
configured for wakeup so that wakeup notifications for those
devices can wake up the system from the "freeze" sleep state.Signed-off-by: Rafael J. Wysocki
07 Feb, 2014
1 commit
-
Since the only existing caller of acpiphp_check_host_bridge(),
which is acpi_pci_root_scan_dependent(), already has a struct
acpi_device pointer needed to obtain the ACPIPHP context, it
doesn't make sense to execute acpi_bus_get_device() on its
handle in acpiphp_handle_to_bridge() just in order to get that
pointer back.For this reason, modify acpiphp_check_host_bridge() to take
a struct acpi_device pointer as its argument and rearrange the
code accordingly.Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
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
23 Jul, 2013
1 commit
-
Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get
the ACPI device handle they need from bus->bridge, it is not
necessary to pass that handle to them as an argument.Drop the second argument of acpi_pci_slot_enumerate() and
acpiphp_enumerate_slots(), rework them to obtain the ACPI handle
from bus->bridge and make acpi_pci_add_bus() and
acpi_pci_remove_bus() entirely symmetrical.Tested-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
18 May, 2013
1 commit
-
When a PCI host bridge device receives a Bus Check notification, we
must re-enumerate starting with the bridge to discover changes (devices
that have been added or removed).Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to
pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that
commit, _handle_hotplug_event_bridge() is not installed for host bridges,
and the host bridge notify handler, _handle_hotplug_event_root() did not
re-enumerate.This patch adds re-enumeration to _handle_hotplug_event_root().
This fixes cases where we don't notice the addition or removal of
PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below.[bhelgaas: changelog, references]
Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961
Reported-by: Gavin Guo
Tested-by: Gavin Guo
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Reviewed-by: Jiang Liu
Acked-by: Rafael J. Wysocki
CC: stable@vger.kernel.org # v3.9+
13 Apr, 2013
3 commits
-
Previously the acpiphp driver registered itself as an ACPI PCI subdriver,
so its callbacks were invoked when creating/destroying PCI root
buses to manage ACPI-based PCI hotplug slots. But it doesn't handle
P2P bridge hotplug events, so it will cause strange behaviour if there
are hotplug slots associated with a hot-removed P2P bridge.This patch fixes this issue by:
1) Directly hooking into PCI core to update hotplug slot devices when
creating/destroying PCI buses through:
pci_{add|remove}_bus() -> acpi_pci_{add|remove}_bus()
2) Getting rid of unused ACPI PCI subdriver-related codeIt also cleans up unused code in the acpiphp driver.
[bhelgaas: keep acpi_pci_add_bus() stub for CONFIG_ACPI=n]
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Reviewed-by: Yinghai Lu
Cc: "Rafael J. Wysocki"
Cc: Toshi Kani -
Currently the pci_slot driver doesn't update PCI slot devices when PCI
device hotplug event happens, which may cause memory leak and returning
stale information to user.Now the pci_slot driver has been changed as built-in driver, so invoke
PCI slot enumeration and destroy routines directly from the PCI core.
And remove ACPI PCI sub-driver related code because it isn't needed
any more.[bhelgas: removed "extern" from function declarations]
Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Reviewed-by: Yinghai Lu
Acked-by: Rafael J. Wysocki
Cc: Toshi Kani -
Prepare two stub functions to handle ACPI PCI slots and ACPI PCI hotplug
slots, which will be invoked by the PCI core when creating/destroying
PCI buses.It will be used to get rid of ACPI PCI subdrivers for pci_slot and
acpiphp, and eventually remove the ACPI PCI subdriver mechanism.And it will also be used to handle ACPI PCI (hotplug) slots in a unified
way, both at boot time and for PCI hotplug operations.Signed-off-by: Jiang Liu
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Reviewed-by: Yinghai Lu
Cc: "Rafael J. Wysocki"
Cc: Toshi Kani
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Myron Stowe
25 Sep, 2012
1 commit
-
When we bind a device to an ACPI handle, the handle is stored in
dev->archdata.acpi_handle. For such devices, there's no need to
search the acpi_pci_roots list with acpi_get_pci_rootbridge_handle();
we can just use DEVICE_ACPI_HANDLE(dev) directly.[bhelgaas: changelog, reorder "if" to avoid negation]
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Cc: Len Brown
Cc: linux-acpi@vger.kernel.org
23 Jun, 2012
1 commit
-
This patch provide MMCONFIG address for PCI host bridges, which will
be used to support host bridge hotplug. It gets MMCONFIG address
by evaluating _CBA method if available.Reviewed-by: Yinghai Lu
Signed-off-by: Jiang Liu
Signed-off-by: Bjorn Helgaas
17 Jan, 2011
1 commit
-
After commit 415e12b23792 ("PCI/ACPI: Request _OSC control once for each
root bridge (v3)") include/linux/pci-acpi.h is included by
drivers/pci/pcie/aer/aerdrv.c and if CONFIG_ACPI is unset, the bogus and
unnecessary alternative definition of acpi_find_root_bridge_handle()
causes a build error to occur.Remove the offending piece of garbage.
Reported-and-tested-by: Stephen Rothwell
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Linus Torvalds
15 Jan, 2011
1 commit
-
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
Tested-by: Ozan Caglayan
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
23 Feb, 2010
1 commit
-
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 .
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
17 Jun, 2009
2 commits
-
Use pci_is_root_bus() in acpi_find_root_bridge_handle() to check if
the pci bus is root, for code consistency.Reviewed-by: Alex Chiang
Reviewed-by: Grant Grundler
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Use pci_is_root_bus() in acpi_pci_get_bridge_handle() to check if the
pci bus is root, for code consistency.Reviewed-by: Grant Grundler
Reviewed-by: Alex Chiang
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
21 Mar, 2009
2 commits
-
Current acpi_find_root_bridge_handle() has a assumption that
pci_bus->self is NULL on the root pci bus. But it might not be true on
some platforms. Because of this wrong assumption, current
acpi_find_root_bridge_handle() might cause endless loop. We must check
pci_bus->parent instead.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
Current acpi_pci_get_bridge_handle() has an assumption that
pci_bus->self is NULL on the root pci bus. But it might not true on
some platforms. Because of this wrong assumption, current
acpi_pci_get_bridge_handle() might return improper ACPI handle. We
must check pci_bus->parent instead.This bug is the root cause of the following kernel panic reported by
James Bottomley. This problem was introduced by the commit
e8c331e963c58b83db24b7d0e39e8c07f687dbc6. The immediate cause was
acpi_pci_get_bridge_handle() returned NULL unexpectedly and it was
passed as the second argument of acpi_walk_namespace().pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [] acpi_ns_get_next_node+0xb/0x3c
PGD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.28 #1
RIP: 0010:[] [] acpi_ns_get_next_node+0xb/0x3c
RSP: 0018:ffff88007f87fd30 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff8037d260 R09: ffff88007f87fdfc
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff80742040(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000010 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88007f87e000, task ffff88007f875040)
Stack:
0000000000000000 ffffffff803964f5 ffff88007f81b728 0000000000001001
ffff88007f87fdfc ffffffff8037d260 0000000600000001 0000000000000000
ffffffff8037d260 0000000000000000 0000000000000001 ffff88007f87fdfc
Call Trace:
[] acpi_ns_walk_namespace+0x55/0x138
[] is_pci_dock_device+0x0/0x20
[] is_pci_dock_device+0x0/0x20
[] acpi_walk_namespace+0x5f/0x83
[] detect_ejectable_slots+0x53/0x70
[] add_bridge+0xe8/0x200
[] acpi_walk_namespace+0x6b/0x83
[] acpi_pci_register_driver+0x48/0x61
[] acpiphp_init+0x0/0x58
[] acpiphp_glue_init+0x4c/0x5a
[] acpiphp_init+0x37/0x58
[] _stext+0x3b/0x180
[] create_proc_entry+0x58/0xa0
[] register_irq_proc+0xc1/0xe0
[] kernel_init+0x152/0x1ac
[] finish_task_switch+0x0/0x110
[] child_rip+0xa/0x20
[] restore_args+0x0/0x30
[] kernel_init+0x0/0x1ac
[] child_rip+0x0/0x20
Code: 89 c2 48 8b 00 48 85 c0 75 f5 48 8b 45 00 48 89 02 44 88 65 09 48 89 5d 00 31 c0 5b 5d 41 5c c3 53 48 85 d2 89 fb 48 89 d7 75 06 8b 56 10 eb 08 e8 73 f1 ff ff 48 89 c2 85 db 74 1a eb 13 0f
RIP [] acpi_ns_get_next_node+0xb/0x3c
RSP
CR2: 0000000000000010
---[ end trace a7919e7f17c0a725 ]---Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
20 Mar, 2009
2 commits
-
- Rename pci_osc_control_set() to acpi_pci_osc_control_set() according
to the other API names in drivers/acpi/pci_root.c.- Move _OSC related definitions to include/linux/acpi.h because _OSC
related API is implemented in drivers/acpi/pci_root.c now.Signed-off-by: Kenji Kaneshige
Reviewed-by: Andrew Patterson
Tested-by: Andrew Patterson
Signed-off-by: Jesse Barnes -
Move PCI _OSC management code from drivers/pci/pci-acpi.c to
drivers/acpi/pci_root.c. The benefits are- We no longer need struct osc_data and its management code (contents
are moved to struct acpi_pci_root). This simplify the code, and we
no longer care about kmalloc() failure.- We can make pci_acpi_osc_support() be a static function, which is
called only from drivers/acpi/pci_root.c.Signed-off-by: Kenji Kaneshige
Reviewed-by: Andrew Patterson
Tested-by: Andrew Patterson
Acked-by: Alex Chiang
Signed-off-by: Jesse Barnes
08 Jan, 2009
4 commits
-
Some ACPI related PCI hotplug code can be shared among PCI hotplug
drivers. This patch introduces the following functions in
drivers/pci/hotplug/acpi_pcihp.c to share the code, and changes
acpiphp and pciehp to use them.- int acpi_pci_detect_ejectable(struct pci_bus *pbus)
This checks if the specified PCI bus has ejectable slots.- int acpi_pci_check_ejectable(struct pci_bus *pbus, acpi_handle handle)
This checks if the specified handle is ejectable ACPI PCI slot. The
'pbus' parameter is needed to check if 'handle' is PCI related ACPI
object.This patch also introduces the following inline function in
include/linux/pci-acpi.h, which is useful to get ACPI handle of the
PCI bridge from struct pci_bus of the bridge's secondary bus.- static inline acpi_handle acpi_pci_get_bridge_handle(struct pci_bus *pbus)
This returns ACPI handle of the PCI bridge which generates PCI bus
specified by 'pbus'.Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
The acpi_query_osc, __pci_osc_support_set, pci_osc_support_set, and
pcie_osc_support_set functions have been obsoleted in favor of setting
these capabilities during root bridge discovery with
pci_acpi_osc_support. There are no longer any callers of these
functions, so remove them.Signed-off-by: Andrew Patterson
Signed-off-by: Jesse Barnes -
Add pci_acpi_osc_support() and call it when a PCI bridge is added. This
allows us to avoid having every individual PCI root bridge driver call
_OSC support for every root bridge in their probe functions, a
significant savings in boot time.Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes -
The pci-acpi.h file will not compile without including linux/acpi.h.
Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes
19 Aug, 2008
1 commit
-
Consolidate finding of a root bridge and getting its handle to the one
inline function. It's cut & pasted on multiple places. Use this new
inline in those.Cc: kristen.c.accardi@intel.com
Acked-by: Alex Chiang
Signed-off-by: Jiri Slaby
Signed-off-by: Jesse Barnes
02 Feb, 2008
1 commit
-
The function pci_osc_support_set() traverses every root bridge when
checking for _OSC support for a capability. It quits as soon as it finds a
device/bridge that doesn't support the requested capability. This won't
work for systems that have mixed PCI and PCIe bridges when checking for
PCIe features. I split this function into two -- pci_osc_support_set() and
pcie_osc_support_set(). The latter is used when only PCIe devices should be
traversed.Signed-off-by: Andrew Patterson
Signed-off-by: Greg Kroah-Hartman
12 Jun, 2006
1 commit
-
Fix build error when CONFIG_ACPI not defined
Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman
11 Nov, 2005
1 commit
-
This patch tweaks the way pciehp requests control of the hotplug
hardware from BIOS. It now tries to invoke the ACPI _OSC method
for a specific hotplug controller only, rather than walking the
entire acpi namespace invoking all possible _OSC methods under
all host bridges. This allows us to gain control of each hotplug
controller individually, even if BIOS fails to give us control of
some other hotplug controller in the system.Signed-off-by: Rajesh Shah
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
