summaryrefslogtreecommitdiff
path: root/drivers/acpi/scan.c
AgeCommit message (Collapse)Author
2011-04-26ACPI / PM: Avoid infinite recurrence while registering power resourcesRafael J. Wysocki
There is at least one BIOS with a DSDT containing a power resource object with a _PR0 entry pointing back to that power resource. In consequence, while registering that power resource acpi_bus_get_power_flags() sees that it depends on itself and tries to register it again, which leads to an infinitely deep recurrence. This problem was introduced by commit bf325f9538d8c89312be305b9779e (ACPI / PM: Register power resource devices as soon as they are needed). To fix this problem use the observation that power resources cannot be power manageable and prevent acpi_bus_get_power_flags() from being called for power resource objects. References: https://bugzilla.kernel.org/show_bug.cgi?id=31872 Reported-and-tested-by: Pascal Dormeau <pdormeau@free.fr> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Len Brown <lenb@kernel.org> Cc: stable@kernel.org
2011-02-24ACPI: Remove the wakeup.run_wake_count device fieldRafael J. Wysocki
The wakeup.run_wake_count ACPI device field is only used by the PCI runtime PM code to "protect" devices from being prepared for generating wakeup signals more than once in a row. However, it really doesn't provide any protection, because (1) all of the functions it is supposed to protect use their own reference counters effectively ensuring that the device will be set up for generating wakeup signals just once and (2) the PCI runtime PM code uses wakeup.run_wake_count in a racy way, since nothing prevents acpi_dev_run_wake() from being called concurrently from two different threads for the same device. Remove the wakeup.run_wake_count ACPI device field which is unnecessary, confusing and used in a wrong way. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-01-12ACPI: Drop device flag wake_capableRafael J. Wysocki
The wake_capable ACPI device flag is not necessary, because it is only used in scan.c for recording the information that _PRW is present for the given device. That information is only used by acpi_add_single_object() to decide whether or not to call acpi_bus_get_wakeup_device_flags(), so the flag may be dropped if the _PRW check is moved to acpi_bus_get_wakeup_device_flags(). Moreover, acpi_bus_get_wakeup_device_flags() always returns 0, so it really should be void. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI: Always check if _PRW is present before trying to evaluate itRafael J. Wysocki
Before evaluating _PRW for devices that are reported as inactive or not present by their _STA control methods we should check if those methods are actually present (otherwise the evaulation of _PRW will obviously fail and a scary message will be printed unnecessarily). Reported-by: Andreas Mohr <andi@lisas.de> Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12Merge branch 'wakeup-etc-rafael' into releaseLen Brown
2011-01-12Merge branch 'power-resource' into releaseLen Brown
2011-01-12ACPI / PM: Register power resource devices as soon as they are neededRafael J. Wysocki
Depending on the organization of the ACPI namespace, power resource device objects may generally be scanned after the "regular" device objects that they are referred from through _PRn. This, in turn, may cause acpi_bus_get_power_flags() to attempt to access them through acpi_bus_init_power() before they are registered (and initialized by acpi_power_driver). [This is not a theoretical issue, it actually happens for one PnP device on my testbed HP nx6325.] To fix this problem, make acpi_bus_get_power_flags() attempt to register power resource devices as soon as they have been found in the _PRn output for any other devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Register acpi_power_driver earlyRafael J. Wysocki
The ACPI device driver used for handling power resources, acpi_power_driver, creates a struct acpi_power_resource object for each ACPI device representing a power resource. These objects are then used when setting and reading the power states of devices using the corresponding power resources. Unfortunately, acpi_power_driver is registered after acpi_scan_init() that may add devices using the power resources before acpi_power_driver has a chance to create struct acpi_power_resource objects for them (specifically, the power resources may be referred to during the scanning process through acpi_bus_get_power() before they have been initialized). As the first step towards fixing this issue, move the registration of acpi_power_driver into acpi_scan_init() so that power resource devices can be initialized by it as soon as they have been found in the namespace. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI / PM: Add function for device power state initializationRafael J. Wysocki
Add function acpi_bus_init_power() for getting the initial power state of an ACPI device and reference counting its power resources as appropriate. Make acpi_bus_get_power_flags() use the new function instead of acpi_bus_get_power() that updates device->power.state without reference counting the device's power resources. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPICA: Implicit notify supportLin Ming
This feature provides an automatic device notification for wake devices when a wakeup GPE occurs and there is no corresponding GPE method or handler. Rather than ignoring such a GPE, an implicit AML Notify operation is performed on the parent device object. This feature is not part of the ACPI specification and is provided for Windows compatibility only. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPICA: Rename some function and variable namesLin Ming
Some function and variable names are renamed to be consistent with ACPICA code base. acpi_raw_enable_gpe -> acpi_ev_add_gpe_reference acpi_raw_disable_gpe -> acpi_ev_remove_gpe_reference acpi_gpe_can_wake -> acpi_setup_gpe_for_wake acpi_gpe_wakeup -> acpi_set_gpe_wake_mask acpi_update_gpes -> acpi_update_all_gpes acpi_all_gpes_initialized -> acpi_gbl_all_gpes_initialized acpi_handler_info -> acpi_gpe_handler_info ... Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-07ACPI / PM: Use device wakeup flags for handling ACPI wakeup devicesRafael J. Wysocki
There are ACPI devices (buttons and the laptop lid) that can wake up the system from sleep states and have no "physical" companion devices. The ACPI subsystem uses two flags, wakeup.state.enabled and wakeup.flags.always_enabled, for handling those devices, but they are not accessible through the standard device wakeup infrastructure. User space can only control them via the /proc/acpi/wakeup interface that is not really convenient (e.g. the way in which devices are enabled to wake up the system is not portable between different systems, because it requires one to know the devices' "names" used in the system's ACPI tables). To address this problem, use standard device wakeup flags instead of the special ACPI flags for handling those devices. In particular, use device_set_wakeup_capable() to mark the ACPI wakeup devices during initialization and use device_set_wakeup_enable() to allow or disallow them to wake up the system from sleep states. Rework the /proc/acpi/wakeup interface to take these changes into account. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-12-17ACPI: Execute _PRW for devices reported as inactive or not presentRafael J. Wysocki
If a device is reported as inactive or not present by its _STA control method, acpi_bus_check_add() skips it without evaluating its _PRW method. This leads to a problem when the device's _PRW method points to a GPE, because in that case the GPE may be enabled by ACPICA during the subsequent acpi_update_gpes() call which, in turn, may cause a GPE storm to appear. To avoid this issue, make acpi_bus_check_add() evaluate _PRW for inactive or not present devices and register the wakeup GPE information returned by them, so that acpi_update_gpes() does not enable their GPEs unnecessarily. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-25Merge branch 'gpe-defer' into releaseLen Brown
2010-10-01ACPI/PNP: A HID value of an object never changes -> make it constThomas Renninger
Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-01ACPI: Do not export hid/modalias sysfs file for ACPI objects without a HIDThomas Renninger
Boot and compile tested. The fact that pnp.ids can now be empty needs testing on some further machines, though. This should handle a "modprobe is wrongly called by udev" issue: https://bugzilla.kernel.org/show_bug.cgi?id=19162 Modaliase files in /sys/devices/LNXSYSTM:00/ went down from 113 to 71 on my tested system. This is a sysfs change, but userspace must already be able to handle it. Also do not fill up pnp.ids list with a "struct hid" entry. This comment: * This generic ID isn't useful for driver binding, but it provides * the useful property that "every acpi_device has an ID." is still half way true: Best you never touch pnp.ids list directly or make sure it can be empty, instead use: char *acpi_device_hid() which always returns a value ("device" as a dummy if the object has no hid). Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Zhang Rui <rui.zhang@intel.com> CC: kay.sievers@vrfy.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-09-24ACPI / ACPICA: Defer enabling of runtime GPEs (v3)Rafael J. Wysocki
The current ACPI GPEs initialization code has a problem that it enables some GPEs pointed to by device _PRW methods, generally intended for signaling wakeup events (system or device wakeup). These GPEs are then almost immediately disabled by the ACPI namespace scanning code with the help of acpi_gpe_can_wake(), but it would be better not to enable them at all until really necessary. Modify the initialization of GPEs so that the ones that have associated _Lxx or _Exx methods and are not pointed to by any _PRW methods will be enabled after the namespace scan is complete. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-12ACPI / ACPICA: Do not execute _PRW methods during initializationRafael J. Wysocki
Currently, during initialization ACPICA walks the entire ACPI namespace in search of any device objects with assciated _PRW methods. All of the _PRW methods found are executed in the process to extract the GPE information returned by them, so that the GPEs in question can be marked as "able to wakeup" (more precisely, the ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this exercise is to avoid enabling the CAN_WAKE GPEs automatically, even if there are _Lxx/_Exx methods associated with them. However, it is both costly and unnecessary, because the host OS has to execute the _PRW methods anyway to check which devices can wake up the system from sleep states. Moreover, it then uses full information returned by _PRW, including the GPE information, so it can take care of disabling the GPEs if necessary. Remove the code that walks the namespace and executes _PRW from ACPICA and modify comments to reflect that change. Make acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices so that they don't cause spurious wakeup events to be signaled. This not only reduces the complexity of the ACPICA initialization code, but in some cases it should reduce the kernel boot time as well. Unfortunately, for this purpose we need a new ACPICA function, acpi_gpe_can_wake(), to be called by the host OS in order to disable the GPEs that can wake up the system and were previously enabled by acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE should be disabled only once, because the initialization code enables it only once, but it may be pointed to by _PRW for multiple devices and that's why the additional function is necessary). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-12ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()Rafael J. Wysocki
When we check if a GPE can be used for runtime signaling, we only search the FADT GPE blocks, which is incorrect, becuase the GPE may be located elsewhere. We really should be using the GPE device information previously returned by _PRW here, so make that happen. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-20ACPICA: Minimize the differences between linux GPE code and ACPICA code baseLin Ming
We have ported Rafael's major GPE changes (ACPI: Use GPE reference counting to support shared GPEs) into ACPICA code base. But the port and Rafael's original patch have some differences, so we made below patch to make linux GPE code consistent with ACPICA code base. Most changes are about comments and coding styles. Other noticeable changes are based on: Rafael: Reduce code duplication related to GPE lookup https://patchwork.kernel.org/patch/86237/ Rafael: Always use the same lock for GPE locking https://patchwork.kernel.org/patch/90471/ A new field gpe_count in struct acpi_gpe_block_info to record the number of individual GPEs in block. Rename acpi_ev_save_method_info to acpi_ev_match_gpe_method. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Robert Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-06Merge branches 'battery', 'bugzilla-14667', 'bugzilla-15096', ↵Len Brown
'bugzilla-15480', 'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 'pxm-fix' and 'video-random-key' into release
2010-04-03ACPI: use _HID when supplied by root-level devicesBjorn Helgaas
Previously, we assumed the only Device object immediately below the root was the \_SB Scope (which the ACPI CA treats as a Device), so we forced the HID of all such objects to ACPI_BUS_HID ("LNXSYBUS"). However, there are DSDTs that supply root-level Device objects with _HIDs. This patch makes us pay attention to those _HIDs and only add the synthetic ACPI_BUS_HID for root-level objects that do not supply their own _HID. For example, this DSDT: https://bugzilla.kernel.org/show_bug.cgi?id=15605 contains: Scope (_SB) { ... } Device (AMW0) { Name (_HID, EisaId ("PNP0C14")) ... } and we should use "PNP0C14" for the AMW0 device, not "LNXSYBUS". Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Yong Wang <yong.y.wang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
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>
2010-03-24acpi: Support IBM SMBus CMI devicesDarrick J. Wong
On some old IBM workstations and desktop computers, the BIOS presents in the DSDT an SMBus object that is missing the HID identifier that the i2c-scmi driver looks for. Modify the ACPI device scan code to insert the missing HID if it finds an IBM system with such an object. Affected machines: IntelliStation Z20/Z30. Note that the i2c-i801 driver no longer works on these machines because of ACPI resource conflicts. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-02-22PCI / ACPI / PM: Platform support for PCI PME wake-upRafael J. Wysocki
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>
2010-02-22ACPI / PM: Add more run-time wake-up fieldsRafael J. Wysocki
Use the run_wake flag to mark all devices for which run-time wake-up events may be generated by the platform. Introduce a new wake-up flag, always_enabled, for marking devices that should be permanently enabled to generate run-time events. Also, introduce a reference counter for run-wake devices and a function that will initialize all of the run-time wake-up fields for given device. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2010-01-31ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was foundThomas Renninger
Callers (acpi_memhotplug.c, dock.c and others) check for the return value of acpi_bus_add() and assume a valid device was returned in case zero was returned. Thus return -ENODEV if no device was found in acpi_bus_scan and propagate this through acpi_bus_add and acpi_bus_start. Also remove a confusing comment in acpiphp_glue.c, acpi_bus_scan will and cannot invoke if acpi_bus_add returns no valid device. Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-31ACPI: Add NULL pointer check in acpi_bus_startThomas Renninger
If acpi_bus_add does not return a device and it's passed to acpi_bus_start, bad things will happen: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8128402d>] acpi_bus_start+0x14/0x24 ... [<ffffffffa008977a>] acpiphp_bus_add+0xba/0x130 [acpiphp] [<ffffffffa008aa72>] enable_device+0x132/0x2ff [acpiphp] [<ffffffffa0089b68>] acpiphp_enable_slot+0xb8/0x130 [acpiphp] [<ffffffffa0089df7>] handle_hotplug_event_func+0x87/0x190 [acpiphp] Next patch would make this NULL pointer check obsolete, but better having one more than one missing... Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-24ACPICA: Add post-order callback to acpi_walk_namespaceLin Ming
The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779. Also update the external calls to acpi_walk_namespace. http://www.acpica.org/bugzilla/show_bug.cgi?id=779 Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-02ACPI: fix bus scanning memory leaksBjorn Helgaas
Free an acpi_get_object_info() buffer when we're finished. Skip the acpi_get_name() altogether -- it was only used for a printk that was really just for debug anyway. http://bugzilla.kernel.org/show_bug.cgi?id=14271 Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reported-and-tested-by: Zdenek Kabelac <zdenek.kabelac@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: simplify building device HID/CID listBjorn Helgaas
Minor code cleanup, no functional change. Instead of remembering what HIDs & CIDs to add later, just add them immediately. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove acpi_device_uid() and related stuffBjorn Helgaas
Nobody uses acpi_device_uid(), so this patch removes it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove acpi_device.flags.hardware_idBjorn Helgaas
Every acpi_device has at least one ID (if there's no _HID or _CID, we give it a synthetic or default ID). So there's no longer a need to check whether an ID exists; we can just use it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove acpi_device.flags.compatible_idsBjorn Helgaas
We now keep a single list of IDs that includes both the _HID and any _CIDs. We no longer need to keep track of whether the device has a _CID. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: maintain a single list of _HID and _CID IDsBjorn Helgaas
There's no need to treat _HID and _CID differently. Keeping them in a single list makes code that uses the IDs a little simpler because it can just traverse the list rather than checking "do we have a HID?", "do we have any CIDs?" 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>
2009-09-25ACPI: make sure every acpi_device has an IDBjorn Helgaas
This makes sure every acpi_device has at least one ID. If we build an acpi_device for a namespace node with no _HID or _CID, we sometimes synthesize an ID like "LNXCPU" or "LNXVIDEO". If we don't even have that, give it a default "device" ID. Note that this means things like: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:04/device:00 (a PCI slot SxFy device) will have "hid" and "modprobe" entries, where they didn't before. These aren't very useful (a HID of "device" doesn't tell you what *kind* of device it is, so it doesn't help find a driver), but I don't think they're harmful. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: use acpi_device_hid() when possibleBjorn Helgaas
Use acpi_device_hid() rather than accessing acpi_device.pnp.hardware_id directly. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: fix synthetic HID for \_SB_Bjorn Helgaas
This makes \_SB_ show up as /sys/devices/LNXSYSTM:00/LNXSYBUS:00 rather than "device:00". This has been broken for a loooong time (at least since 2.6.13) because device->parent is an acpi_device pointer, not a handle. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: handle re-enumeration, when acpi_devices might already existBjorn Helgaas
acpi_bus_scan() traverses the namespace to enumerate devices and uses acpi_add_single_object() to create acpi_devices. When the platform notifies us of a hot-plug event, we need to traverse part of the namespace again to figure out what appeared or disappeared. (We don't yet call acpi_bus_scan() during hot-plug, but I plan to do that in the future.) This patch makes acpi_add_single_object() notice when we already have an acpi_device, so we don't need to make a new one. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: factor out device type and status checkingBjorn Helgaas
This patch adds acpi_bus_type_and_status(), which determines the type of the object and whether we want to build an acpi_device for it. If it is acpi_device-worthy, it returns the type and the device's current status. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: use acpi_walk_namespace() to enumerate devicesBjorn Helgaas
acpi_bus_scan() currently walks the namespace manually. This patch changes it to use acpi_walk_namespace() instead. Besides removing some complicated code, this means we take advantage of the namespace locking done by acpi_walk_namespace(). The locking isn't so important at boot-time, but I hope to eventually use this same path to handle hot-addition of devices, when it will be important. Note that acpi_walk_namespace() does not actually visit the starting node first, so we need to do that by hand first. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: identify device tree root by null parent pointer, not ACPI_BUS_TYPEBjorn Helgaas
We can identify the root of the ACPI device tree by the fact that it has no parent. This is simpler than passing around ACPI_BUS_TYPE_SYSTEM and will help remove special treatment of the device tree root. Currently, we add the root by hand with ACPI_BUS_TYPE_SYSTEM. If we traverse the tree treating the root as just another device and use acpi_get_type(), the root shows up as ACPI_TYPE_DEVICE. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: enumerate namespace before adding functional fixed hardware devicesBjorn Helgaas
This patch changes the order so we enumerate in the "root, namespace, functional fixed" order instead of the "root, functional fixed, namespace" order. When I change acpi_bus_scan() to use acpi_walk_namespace(), it will use the former order, so this patch isolates the order change for bisectability. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: convert acpi_bus_scan() to operate on an acpi_handleBjorn Helgaas
This patch changes acpi_bus_scan() to take an acpi_handle rather than an acpi_device pointer. I plan to use acpi_bus_scan() in the hotplug path, and I'd rather not assume that notifications only go to nodes that already have acpi_devices. This will also help remove the special case for adding the root node. We currently add the root by hand before acpi_bus_scan(), but using a handle here means we can start the acpi_bus_scan() directly with the root even though it doesn't have an acpi_device yet. Note that acpi_bus_scan() currently adds and/or starts the *children* of its device argument. It doesn't do anything with the device itself. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: add acpi_bus_get_parent() and remove "parent" argumentsBjorn Helgaas
This patch adds acpi_bus_get_parent(), which ascends the namespace until it finds a parent with an acpi_device. Then we use acpi_bus_get_parent() in acpi_add_single_object(), so callers don't have to figure out or keep track of the parent acpi_device. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove unnecessary argument checkingBjorn Helgaas
acpi_add_single_object() is static, and all callers supply a valid "child" argument, so we don't need to check it. This patch also remove some unnecessary initializations. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove redundant "type" argumentsBjorn Helgaas
We now save the ACPI bus "device_type" in the acpi_device structure, so we don't need to pass it around explicitly anymore. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: remove acpi_device_set_context() "type" argumentBjorn Helgaas
We only pass the "type" to acpi_device_set_context() so we know whether the device has a handle to which we can attach the acpi_device pointer. But it's safer to just check for the handle directly, since it's in the acpi_device already. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: use device_type rather than comparing HIDBjorn Helgaas
Check the acpi_device device_type rather than the HID. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-25ACPI: save device_type in acpi_deviceBjorn Helgaas
Most uses of the ACPI bus device_type (ACPI_BUS_TYPE_DEVICE, ACPI_BUS_TYPE_POWER, etc) are during device initialization, but we do need it later for notify handler installation, since that is different for fixed hardware devices vs. namespace devices. This patch saves the device_type in the acpi_device structure, so we can check that rather than comparing against the _HID string. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>