aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi
Commit message (Collapse)AuthorAge
* Merge branch 'bugzilla-13449' into releaseLen Brown2009-11-06
|\
| * ACPI: sleep: another HP/Compaq DMI entries for init_set_sci_en_on_resumeVaibhav Verma2009-11-05
| | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: add DMI entry for SCI_EN resume quirk on HP dv4Gustavo Maciel Dias Vieira2009-11-05
| | | | | | | | | | | | | | | | | | | | | | Fixes the missing battery on sleep problem for yet another HP laptop ("HP Pavilion dv4"). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13449 Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Len Brown <len.brown@intel.com>
| |
| \
*-. \ Merge branches 'misc', 'eeepc-laptop' and 'bugzilla-14445' into releaseLen Brown2009-11-05
|\ \ \ | |_|/ |/| |
| | * ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."Bob Moore2009-11-05
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that memory mappings created for operation regions do not cross page boundaries. Crossing a page boundary while mapping regions can cause warnings if the pages have different attributes. Such regions are probably BIOS bugs, and this is the workaround. http://bugzilla.kernel.org/show_bug.cgi?id=14445 [Kernel summit hacking hour] Signed-off-by: Bob Moore <robert.moore@intel.com> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Move dereference after NULL testJulia Lawall2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the NULL test on pr is needed, then the dereference should be after the NULL test. A simplified version of the semantic match that detects this problem is as follows (http://coccinelle.lip6.fr/): // <smpl> @match exists@ expression x, E; identifier fld; @@ * x->fld ... when != \(x = E\|&x\) * x == NULL // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: add __cpuinit to acpi_processor_add()Rakib Mullick2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annote acpi_processor_add with cpuinit since it calls a cpuinit function acpi_processor_power_init and fixes a section mismatch warning. We were warned by the following warning: LD drivers/acpi/processor.o WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in reference from the function acpi_processor_add() to the function .cpuinit.text:acpi_processor_power_init() The function acpi_processor_add() references the function __cpuinit acpi_processor_power_init(). This is often because acpi_processor_add lacks a __cpuinit annotation or the annotation of acpi_processor_power_init is wrong. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * acpi-power-meter: Don't leak ACPI error codes to userspaceDarrick J. Wong2009-11-05
| | | | | | | | | | | | | | | | | | | | | | If the ACPI methods return an error code, we must return -EINVAL to userspace to flag the error. Right now we pass the (positive) number right through, which causes echo to keep writing bogus values. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: clean up video.c boundary checks and typesArjan van de Ven2009-10-28
|/ | | | | | | | | | | | | | | | | | | | | | | proc.c and video.c are a bit sloppy around types and style, confusing gcc for a new feature that'll be in 2.6.33 and will cause a warning on the current code. This patch changes if (foo + 1 > sizeof bar) into if (foo >= sizeof(bar)) which is more kernel-style. it also changes a variable in proc.c to unsigned; it gets assigned a value from an unsigned type, and is then only compared for > not for negative, so using unsigned is just outright the right type Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'misc' into releaseLen Brown2009-10-15
|\
| * ACPI button: don't try to use a non-existent lid deviceJesse Barnes2009-10-13
| | | | | | | | | | | | | | | | If a call comes in to check the lid state but there's no lid device present, we should return -ENODEV. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Kconfig, fix proc aggregator textJiri Slaby2009-10-09
| | | | | | | | | | | | | | Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: add AC/DC notifierMark Langsdorf2009-10-06
| | | | | | | | | | | | | | Add an ACPI event notifier for AC/DC connect/disconnect events. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'launchpad-333386' into releaseLen Brown2009-10-15
|\ \
| * | ACPI: video: Loosen strictness of video bus detection codeStefan Bader2009-10-13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/333386 Currently a video bus device must (beside other criteria) define _DOD and _DOS methods to be considered a video device. Some broken BIOSes prevented working backlight control by only defining both for one (non-existing bus) and only _DOD for the rest. With this patch in place the other bus definitions were considered too and backlight control started to work again. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* / ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)Rafael J. Wysocki2009-10-13
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'acpi-pad' of ↵Linus Torvalds2009-10-04
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'acpi-pad' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: acpi_pad: build only on X86 ACPI: create Processor Aggregator Device driver Fixup trivial conflicts in MAINTAINERS file.
| * acpi_pad: build only on X86Len Brown2009-09-27
| | | | | | | | | | | | X86_FEATURE_MWAIT doesn't exist on ia64... Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: create Processor Aggregator Device driverShaohua Li2009-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'misc' into releaseLen Brown2009-10-03
|\ \
| * | ACPI: dock: fix "sibiling" typoAlex Chiang2009-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Crossword clues as haikus: Snakes from the same brood fighting Jackson on a plane? sibilant siblings I guess Will Shortz's job is still secure. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: kill overly verbose "throttling states" log messagesRoland Dreier2009-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was recently lucky enough to get a 64-CPU system. The processors actually have T-states, so my kernel log ends up with 64 lines like: ACPI: Processor [CPU0] (supports xx throttling states) This is pretty useless clutter because - this info is already available after boot from /proc/acpi/processor/CPUnn/throttling - there's also an ACPI_DEBUG_PRINT() in processor_throttling.c that gives the same info on boot for anyone who *really* cares. So just delete the code that prints the throttling states in processor_core.c. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Fix bound checks for copy_from_user in the acpi /proc codeArjan van de Ven2009-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI /proc write() code takes an unsigned length argument like any write() function, but then assigned it to a *signed* integer called "len". Only after this is a sanity check for len done to make it not larger than 4. Due to the type change a len < 0 is in principle also possible; this patch adds a check for this. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'bugzilla-14081' into releaseLen Brown2009-10-03
|\ \ \
| * | | ACPI: EC: Don't parse DSDT for EC early init on CompalAlexey Starikovskiy2009-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compal DSDT breaks if scanned early, while we need early scan for almost all ASUS machines. Safest workaround seems to be to continue do an early scan for all machines, but this Compal model. http://bugzilla.kernel.org/show_bug.cgi?id=14086 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | ACPI: EC: Rewrite DMI checksAlexey Starikovskiy2009-10-03
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Use dmi_check_system() for DMI matching. Don't use string "Notebook" for matching MSI hardware. http://bugzilla.kernel.org/show_bug.cgi?id=14081 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| | |
| \ \
*-. \ \ Merge branches 'sony-laptop', 'bugzilla-14247' and 'bugzilla-14271' into releaseLen Brown2009-10-02
|\ \ \ \
| | * | | ACPI: fix bus scanning memory leaksBjorn Helgaas2009-10-02
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * / / ACPI: EC: Restart command even if no interrupts from ECAlexey Starikovskiy2009-10-02
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | EC may forget a command without sending any "reset" interrupt, thus we need to lessen the requirement for transaction restart. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14247 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| * / const: constify remaining file_operationsAlexey Dobriyan2009-10-01
|/ / | | | | | | | | | | | | | | [akpm@linux-foundation.org: fix KVM] Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | ACPI: kill "unused variable ‘i’" warningLinus Torvalds2009-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3d5b6fb47a8e68fa311ca2c3447e7f8a7c3a9cf3 ("ACPI: Kill overly verbose "power state" log messages") removed the actual use of this variable, but didn't remove the variable itself, resulting in build warnings like drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’: drivers/acpi/processor_idle.c:1169: warning: unused variable ‘i’ Just get rid of the now unused variable. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | ACPI: Kill overly verbose "power state" log messagesRoland Dreier2009-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was recently lucky enough to get a 64-CPU system, so my kernel log ends up with 64 lines like: ACPI: CPU0 (power states: C1[C1] C2[C3]) This is pretty useless clutter because this info is already available after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as well as /proc/acpi/processor/CPU*/power. So just delete the code that prints the C-states in processor_idle.c. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Clarify resource conflict messageJean Delvare2009-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The message "ACPI: Device needs an ACPI driver" is misleading. The device _may_ need an ACPI driver, if the BIOS implemented a custom API for the device in question (which, AFAIK, can't be checked.) If not, then either a generic ACPI driver may be used (for example "thermal"), or nothing can be done (other than a white list). I propose to reword the message to: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver which I think is more correct. Comments and suggestions welcome. I also added a message warning about possible problems and system instability when users pass acpi_enforce_resources=lax, as suggested by Len. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Thomas Renninger <trenn@suse.de> Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlightLinus Torvalds2009-09-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight: backlight: new driver for ADP5520/ADP5501 MFD PMICs backlight: extend event support to also support poll() backlight/eeepc-laptop: Update the backlight state when we change brightness backlight/acpi: Update the backlight state when we change brightness backlight: Allow drivers to update the core, and generate events on changes backlight: switch to da903x driver to dev_pm_ops backlight: Add support for the Avionic Design Xanthos backlight device. backlight: spi driver for LMS283GF05 LCD backlight: move hp680-bl's probe function to .devinit.text backlight: Add support for new Apple machines. backlight: mbp_nvidia_bl: add support for MacBookAir 1,1 backlight: Add WM831x backlight driver Trivial conflicts due to '#ifdef CONFIG_PM' differences in drivers/video/backlight/da903x_bl.c
| * | backlight/acpi: Update the backlight state when we change brightnessMatthew Garrett2009-09-21
| | | | | | | | | | | | | | | | | | | | | | | | Trigger a status update when we change the brightness in the driver, thus allowing userspace to present appropriate UI. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* | | ACPI: simplify building device HID/CID listBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: remove acpi_device_uid() and related stuffBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: remove acpi_device.flags.hardware_idBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: remove acpi_device.flags.compatible_idsBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: maintain a single list of _HID and _CID IDsBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: make sure every acpi_device has an IDBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: use acpi_device_hid() when possibleBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: fix synthetic HID for \_SB_Bjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: handle re-enumeration, when acpi_devices might already existBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: factor out device type and status checkingBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: add acpi_bus_get_status_handle()Bjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add acpi_bus_get_status_handle() so we can get the status of a namespace object before building a struct acpi_device. This removes a use of "device->flags.dynamic_status", a cached indicator of whether _STA exists. It seems simpler and more reliable to just evaluate _STA and catch AE_NOT_FOUND errors. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | ACPI: use acpi_walk_namespace() to enumerate devicesBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: identify device tree root by null parent pointer, not ACPI_BUS_TYPEBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: enumerate namespace before adding functional fixed hardware devicesBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI: convert acpi_bus_scan() to operate on an acpi_handleBjorn Helgaas2009-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-20 04:08:38 -0500