- 26 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NJiang Liu <jiang.liu@huawei.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 22 1月, 2013 1 次提交
-
-
由 Stefan Bader 提交于
To fix incorrect P-state frequencies which can happen on some AMD systems f594065f "ACPI: Add fixups for AMD P-state figures" introduced a quirk to obtain the correct values by reading from AMD specific MSRs. This did cause a regression when running a kernel using that quirk under Xen which does (currently) not pass through MSR reads to the HW. Instead the guest gets a 0 in return. And this seems to cause a failure to initialize the ondemand governour (hard to say for sure as all P-states appear to run at the same frequency). While this should also be fixed in the hypervisor (to allow a guest to read that MSR), this patch is intended to work around the issue in the meantime. In discussion it turned out that indeed real HW/BIOSes may choose to not set the valid bit and thus mark the P-state as invalid. So this could be considered a fix for broken BIOSes that also works around the issue on Xen. Signed-off-by: NStefan Bader <stefan.bader@canonical.com> Cc: 3.7+ <stable@vger.kernel.org> Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 1月, 2013 3 次提交
-
-
由 Lans Zhang 提交于
The bit width check was introduced by 15afae60 (ACPI, APEI: Fix incorrect APEI register bit width check and usage), and a fixup for incorrect 32-bit width memory address was given by f712c71f (ACPI, APEI: Fixup common access width firmware bug). Now there is a similar symptom: [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0x12345000/64/0/3/0] Another bogus BIOS reports an incorrect 64-bit width in trigger table. Thus, apply to a similar workaround for 64-bit width memory address. Signed-off-by: NLans Zhang <jia.zhang@windriver.com> Acked-by: NGary Hade <garyhade@us.ibm.com> Acked-by: NMyron Stowe <myron.stowe@redhat.com> Acked-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fact is unnecessary, because acpi_update_all_gpes() has already been called by acpi_scan_init() and the way it is implemented guarantees the next invocations of it to do nothing. For this reason, drop acpi_bus_add() and make all its callers use acpi_bus_scan() directly instead of it. Additionally, rearrange the code in acpi_scan_init() slightly to improve the visibility of the acpi_update_all_gpes() call in there. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Thomas Schlichter 提交于
acpi_processor_get_power_info() has to be called before acpi_processor_setup_cpuidle_states() to have the latest information available. This fixes the missing C-state information after AC-->DC transition. Signed-off-by: NThomas Schlichter <thomas.schlichter@web.de> Cc: <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 1月, 2013 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
If cpuidle is disabled, that means that: per_cpu(acpi_cpuidle_device, pr->id) is set to NULL as the acpi_processor_power_init ends up failing at retval = cpuidle_register_driver(&acpi_idle_driver) (in acpi_processor_power_init) and never sets the per_cpu idle device. So when acpi_processor_hotplug on CPU online notification tries to reference said device it crashes: cpu 3 spinlock event irq 62 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105 PGD a259b067 PUD ab38b067 PMD 0 Oops: 0002 [#1] SMP odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf CPU 1 Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680) RIP: e030:[<ffffffff81381013>] [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105 RSP: e02b:ffff88001742dca8 EFLAGS: 00010202 RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000 RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800 RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200 R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800 R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0 FS: 00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000) Stack: 0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800 0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0 ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336 Call Trace: [<ffffffff813815b1>] acpi_processor_hotplug+0x7c/0x9f [<ffffffff810ae336>] ? schedule_delayed_work_on+0x16/0x20 [<ffffffff8137ee8f>] acpi_cpu_soft_notify+0x90/0xca [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70 [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10 [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30 [<ffffffff81652cf7>] _cpu_up+0x103/0x14b [<ffffffff81652e18>] cpu_up+0xd9/0xec [<ffffffff8164a254>] store_online+0x94/0xd0 [<ffffffff814122fb>] dev_attr_store+0x1b/0x20 [<ffffffff81216404>] sysfs_write_file+0xf4/0x170 This patch fixes it. Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 1月, 2013 5 次提交
-
-
由 Yinghai Lu 提交于
Should use acpi_device pointer directly instead of use handle and get the device pointer again later. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Make acpi_bus_trim() work in analogy with acpi_bus_scan() and carry out two passes such that ACPI drivers will be detached from device nodes being removed in the first pass and the device nodes themselves will be removed in the second pass. For this purpose split the driver unregistration out of acpi_bus_remove() into a new routine, acpi_bus_device_detach(), that will be executed by acpi_bus_trim() in the additional first pass as a post-order callback. This is necessary, because some ACPI drivers' .remove() routines unregister struct device objects associated with the ACPI device nodes being removed and that needs to happen while the ACPI device nodes are still around (for example, in case they need to be used for power management or similar things at that time). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
由 Rafael J. Wysocki 提交于
The current acpi_bus_trim() implementation is not really straightforward and may be simplified significantly by using acpi_walk_namespace() with acpi_bus_remove() as a post-order callback. Observe that acpi_bus_remove(), as called by acpi_bus_trim(), cannot actually fail, because its first argument is guaranteed not to be NULL thanks to the acpi_bus_get_device() check in acpi_bus_trim(), so simply move the acpi_bus_get_device() check to acpi_bus_remove() and use acpi_walk_namespace() to execute it for every device under start->handle as a post-order callback. The, run it directly for start->handle itself. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
由 Rafael J. Wysocki 提交于
All callers of acpi_bus_trim() pass 1 (true) as the second argument of it, so remove that argument entirely and change acpi_bus_trim() to always behave as though it were 1. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
由 Rafael J. Wysocki 提交于
Drop the second argument of acpi_device_unregister(), type, which is not used by that function. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
- 12 1月, 2013 2 次提交
-
-
由 Yinghai Lu 提交于
If ACPI_GLUE_DEBUG is different from 0 (setting this requires a manual change of glue.c), build breaks because of a leftover reference to dev->acpi_handle in acpi_platform_notify(). Fix this by using ACPI_HANDLE(dev) instead as appropriate. [rjw: Subject and changelog] Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Since device_attach() returns 1 on success (a driver has been bound to the device), the check against its return value in acpi_bus_device_attach() should modified to take that into accout. Make it so. [rjw: Subject and changelog.] Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 805d410f (ACPI: Separate adding ACPI device objects from probing ACPI drivers) introduced an ACPI power resources management regression, because it didn't ensure that the power resources driver bind to the struct acpi_device objects corresponding to power resources as soon as they were created. As a result, ACPI power management routines may attempt to access power resource objects before they are ready to use. To fix this problem, tell the acpi_add_single_object() in acpi_bus_check_add() to probe the driver for objects of type ACPI_BUS_TYPE_POWER. This fix has been verified to work on HP nx6325 where the problem was first observed. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
- 05 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
At one point acpi_device_set_id() checks if acpi_device_hid(device) returns NULL, but that never happens, so system bus devices with an empty list of PNP IDs are given the dummy HID ("device") instead of the "system bus HID" ("LNXSYBUS"). Fix the code to use the right check. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: <stable@vger.kernel.org>
-
- 03 1月, 2013 22 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit 71fbad6c (PCI/ACPI: Notify PCI devices when their power resource is turned on) made acpi_pci_bind() call acpi_power_resource_register_device(), the debug message at the end of the latter appears in the kernel log for every PCI device that doesn't happen to have power resources assigned (which is the vast majority of them). However, this message is totally useless, because it doesn't even say which device it is about. Moreover, it is misleading, because it only means that the given device has no power resources, which isn't exceptional at all. Remove that useless message altogether and simplify acpi_power_resource_register_device() slightly. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Joe Perches 提交于
Currently these DBG statements are emitted at KERN_DEFAULT. Change the macro to emit at KERN_DEBUG. This can help avoid unexpected message interleaving. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Since the return value of acpi_bus_get_device() is not of type acpi_status, ACPI_SUCCESS() should not be used for checking its return value. Fix that. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Liu Jinsong 提交于
When memory hotadd, acpi_memory_enable_device has already been done at drv->ops.add (acpi_memory_device_add), no need to do it again at notify callback. At acpi_memory_enable_device, acpi_memory_get_device_resources is also a redundant action, since it has been done at drv->ops.add. Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Adrian Huang 提交于
If the persistent store is empty initially, the function 'erst_dbg_read' returns a nonzero value. The better way is to return a zero indicating the read operation reaches EOF. Tested on two different servers. Signed-off-by: NAdrian Huang <adrian.huang@hp.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Drop the .bind() and .unbind() that have no more users from struct acpi_device_ops and remove all of the code referring to them from drivers/acpi/scan.c. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Move the code related to _PRT setup and removal and to power resources from acpi_pci_bind() and acpi_pci_unbind() to the .setup() and .cleanup() callbacks in acpi_pci_bus and remove acpi_pci_bind() and acpi_pci_unbind() that have no purpose any more. Accordingly, remove the code related to device .bind() and .unbind() operations from the ACPI PCI root bridge driver. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type and modify acpi_platform_notify() to call .setup() after executing acpi_bind_one() successfully and acpi_platform_notify_remove() to call .cleanup() before running acpi_unbind_one(). This will allow the users of struct acpi_bus_type, PCI in particular, to specify operations to be executed right after the given device has been associated with a companion struct acpi_device and right before it's going to be detached from that companion, respectively. The main motivation is to be able to get rid of acpi_pci_bind() and acpi_pci_unbind(), which are horrible horrible stuff. [In short, there are three problems with them: The way they populate the .bind() and .unbind() callbacks of ACPI devices is rather less than straightforward, they require special hotplug-specific paths to be present in the ACPI namespace scanning code and by the time acpi_pci_unbind() is called the PCI device object in question may not exist any more.] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
The callers of acpi_bus_add() usually assume that if it has succeeded, then a struct acpi_device object has been attached to the handle passed as the first argument. Unfortunately, however, this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add() too as a result, may return a pointer to a different struct acpi_device object on success (it may be an object corresponding to one of the descendant ACPI nodes in the namespace scope below that handle). For this reason, the callers of acpi_bus_add() who care about whether or not a struct acpi_device object has been created for its first argument need to check that using acpi_bus_get_device() anyway, so the second argument of acpi_bus_add() is not really useful for them. The same observation applies to acpi_bus_scan() executed directly from acpi_scan_init(). Therefore modify the relevant callers of acpi_bus_add() to check the existence of the struct acpi_device in question with the help of acpi_bus_get_device() and drop the no longer necessary second argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to use acpi_bus_get_device() to get acpi_root and drop the no longer needed second argument of acpi_bus_scan(). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
After the removal of the second argument of acpi_bus_scan() there is no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START add types, so the add_type field in struct acpi_device may be replaced with a single flag. Do that calling the flag match_driver. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
After the removal of acpi_start_single_object() and acpi_bus_start() the second argument of acpi_bus_scan() is not necessary any more, so drop it and update acpi_bus_check_add() accordingly. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Notice that acpi_bus_add() uses only 2 of its 4 arguments and redefine its header to match the body. Update all of its callers as necessary and observe that this leads to quite a number of removed lines of code (Linus will like that). Add a kerneldoc comment documenting acpi_bus_add() and wonder how its callers make wrong assumptions about the second argument (make note to self to take care of that later). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
The ACPI PCI root bridge driver was the only ACPI driver implementing the .start() callback, which isn't used by any ACPI drivers any more now. For this reason, acpi_start_single_object() has no purpose any more, so remove it and all references to it. Also remove acpi_bus_start_device(), whose only purpose was to call acpi_start_single_object(). Moreover, since after the removal of acpi_bus_start_device() the only purpose of acpi_bus_start() remains to call acpi_update_all_gpes(), move that into acpi_bus_add() and drop acpi_bus_start() too, remove its header from acpi_bus.h and update all of its former users accordingly. This change was previously proposed in a different from by Yinghai Lu. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Move the code from the ACPI PCI root bridge's .start() callback routine, acpi_pci_root_start(), directly into acpi_pci_root_add() and drop acpi_pci_root_start(). It is safe to do that, because it is now always guaranteed that when struct pci_dev objects are created, their companion struct acpi_device objects are already present, so it is not necessary to wait for them to be created before calling pci_bus_add_devices(). This change was previously proposed in a different form by Yinghai Lu. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
If acpi_bus_check_add() is called for a handle already having an existing struct acpi_device object attached, it is not necessary to check the type and status of the device correspondig to it, so change the ordering of acpi_bus_check_add() to avoid that. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Notice that one member of struct acpi_bus_ops, acpi_op_add, is not used anywhere any more and the relationship between its remaining members, acpi_op_match and acpi_op_start, is such that it doesn't make sense to set the latter without setting the former at the same time. Therefore, replace struct acpi_bus_ops with new a enum type, enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC, ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to both acpi_op_match and acpi_op_start unset, acpi_op_match set and acpi_op_start unset, and both acpi_op_match and acpi_op_start set, respectively. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Objects of type struct acpi_bus_ops are currently used to pass information between different parts of the ACPI namespace scanning code, sometimes in quite convoluted ways. It turns out that that is not necessary in some cases, so simplify the code by reducing the utilization of struct acpi_bus_ops objects where clearly possible. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
The current ACPI namespace scanning code suggests that acpi_bus_add() and acpi_bus_start() share some code. In fact, however, they are completely different code paths (except for the initial checks), so refactor the code to make that distinction visibly clear. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Instead of running acpi_pci_root_init() from a separate subsys initcall, call it directly from acpi_scan_init() before scanning the ACPI namespace for the first time, so that the PCI root bridge driver's .add() routine, acpi_pci_root_start(), is always run before binding ACPI drivers or attaching "companion" device objects to struct acpi_device objects below the root bridge's device node in the ACPI namespace. The first, simpler reason for doing this is that it makes the situation during boot more similar to the situation during hotplug, in which the ACPI PCI root bridge driver is always present. The second reason is that acpi_pci_root_init() causes struct pci_dev objects to be created for all PCI devices below the bridge and these objects may be necessary for whatever is done with the other ACPI device nodes in that namespace scope. For example, devices created by acpi_create_platform_device() sometimes may need to be added to the device hierarchy as children of PCI bridges. For this purpose, however, the struct pci_dev objects representing those bridges need to exist before the platform devices in question are registered. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
Split the ACPI namespace scanning for devices into two passes, such that struct acpi_device objects are registerd in the first pass without probing ACPI drivers and the drivers are probed against them directly in the second pass. There are two main reasons for doing that. First, the ACPI PCI root bridge driver's .add() routine, acpi_pci_root_add(), causes struct pci_dev objects to be created for all PCI devices under the given root bridge. Usually, there are corresponding ACPI device nodes in the ACPI namespace for some of those devices and therefore there should be "companion" struct acpi_device objects to attach those struct pci_dev objects to. These struct acpi_device objects should exist when the corresponding struct pci_dev objects are created, but that is only guaranteed during boot and not during hotplug. This leads to a number of functional differences between the boot and the hotplug cases which are not strictly necessary and make the code more complicated. For example, this forces the ACPI PCI root bridge driver to defer the registration of the just created struct pci_dev objects and to use a special .start() callback routine, acpi_pci_root_start(), to make sure that all of the "companion" struct acpi_device objects will be present at PCI devices registration time during hotplug. If those differences can be eliminated, we will be able to consolidate the boot and hotplug code paths for the enumeration and registration of PCI devices and to reduce the complexity of that code quite a bit. The second reason is that, in general, it should be possible to resolve conflicts of resources assigned by the BIOS to different devices represented by ACPI namespace nodes before any drivers bind to them and before they are attached to "companion" objects representing physical devices (such as struct pci_dev). However, for this purpose we first need to enumerate all ACPI device nodes in the given namespace scope. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Lv Zheng 提交于
The mini-C library implementation is used by the embedded ACPICA users other than Linux. It was added to the kernel source to make it easier to incorporate future ACPICA changes, but as it turns our we can avoid carrying it thanks to some ACPICA release process tweaks, so remove drivers/acpi/acpica/utclib.c from the kernel source tree. [rjw: Modified the changelog slightly.] Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 12月, 2012 2 次提交
-
-
由 Mika Westerberg 提交于
All devices behind Haswell LPSS (Low Power Subsystem) should be represented as platform devices so add them to the acpi_platform_device_ids list. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Chen Gong 提交于
To handle error trigger table correctly, memory region must be removed from request region. We had a series of patches to do this culminating in: commit b4e008dc ACPI, APEI, EINJ, Refine the fix of resource conflict but when ACPI5 support was added, we missed updating this area. So when using EINJ table on an ACPI5 enabled machine, we get following error: APEI: Can not request [mem 0x526b80000-0x526b80007] for APEI EINJ Trigger registers Fix this by checking for the acpi5 case and using the same code that was added earlier. Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 05 12月, 2012 1 次提交
-
-
由 Zhang Rui 提交于
Or else the laptop will boot with a dimmed screen. References: https://bugzilla.kernel.org/show_bug.cgi?id=51141Tested-by: NStefan Nagy <public@stefan-nagy.at> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-