Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.15.y 2014-07-01T03:13:58+00:00 2014-07-01T03:13:58+00:00 Lv Zheng lv.zheng@intel.com 2014-05-12T07:50:16+00:00 urn:sha1:582639a51a66dfa233b66cf08619f78fdc2bbf24 commit 73577d1df8e1f31f6b1a5eebcdbc334eb0330e47 upstream. This patch fixes the following issue: If DSDT is customized, no local DSDT copy is needed. References: https://bugzilla.kernel.org/show_bug.cgi?id=69711 Signed-off-by: Enrico Etxe Arte <goitizena.generoa@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [rjw: Subject] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2014-04-24T17:27:49+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-04-24T17:27:49+00:00 urn:sha1:f66abe92ce498672ac44d550f51a526597c731c4 Commit 1a699476e258 "ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()" changed the root notify handler, acpi_bus_notify(), to block unknown type norifications, but it overlooked the fact that they might be propagated to drivers via the ->notify() callback. Fix the problem by allowing drivers to receive unknown type notifications via ->notify() as before. Fixes: 1a699476e258 (ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()) Reported-and-tested-by: Mantas Mikulėnas <grawity@gmail.com> Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-03-17T12:48:18+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-03-17T12:48:18+00:00 urn:sha1:2eb060975df2aaca635801dcfb99eaa45ede98fe * acpi-ost: ACPI: Drop acpi_evaluate_hotplug_ost() and ACPI_HOTPLUG_OST ACPI: use device name LNXSYBUS.xx for ACPI \_SB and \_TZ objects ACPI / processor: use acpi_evaluate_ost() to replace open-coded version ACPI / PAD / xen: use acpi_evaluate_ost() to replace open-coded version ACPI / PAD: use acpi_evaluate_ost() to replace open-coded version ACPI: rename acpi_evaluate_hotplug_ost() to acpi_evaluate_ost() 2014-03-05T00:26:35+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-03-02T23:40:38+00:00 urn:sha1:1e3bcb596c6b1cf6db93f8f506e2de260e771bad Since the only function executed by acpi_hotplug_execute() is acpi_device_hotplug() and it only is called by the ACPI core, simplify its definition so that it only takes two arguments, the ACPI device object pointer and event code, rename it to acpi_hotplug_schedule() and move its header from acpi_bus.h to the ACPI core's internal header file internal.h. Modify the definition of acpi_device_hotplug() so that its first argument is an ACPI device object pointer and modify the definition of struct acpi_hp_work accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> 2014-02-21T23:50:49+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-02-21T00:07:17+00:00 urn:sha1:700b8422fb9e6041907bda45a15f4e2ab0438a04 Replace acpi_evaluate_hotplug_ost() with acpi_evaluate_ost() everywhere and drop the ACPI_HOTPLUG_OST symbol so that hotplug _OST is supported unconditionally. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> 2014-02-06T16:31:52+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-02-06T12:58:13+00:00 urn:sha1:1a699476e25814343766342672c655fb135224cc Since acpi_bus_notify() is executed on all notifications for all devices anyway, make it execute acpi_device_hotplug() for all hotplug events instead of installing notify handlers pointing to the same function for all hotplug devices. This change reduces both the size and complexity of ACPI-based device hotplug code. Moreover, since acpi_device_hotplug() only does significant things for devices that have either an ACPI scan handler, or a hotplug context with .eject() defined, and those devices had notify handlers pointing to acpi_hotplug_notify_cb() installed before anyway, this modification shouldn't change functionality. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-02-05T16:41:18+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-02-03T23:43:05+00:00 urn:sha1:78ea4639a7647f2fcc957c3a532bde49df9895c7 There is a slight possibility for the ACPI device object pointed to by adev in acpi_hotplug_notify_cb() to become invalid between the acpi_bus_get_device() that it comes from and the subsequent dereference of that pointer under get_device(). Namely, if acpi_scan_drop_device() runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn() queued up by it may delete the device object in question right after a successful execution of acpi_bus_get_device() in acpi_bus_notify(). An analogous problem is present in acpi_bus_notify() where the device pointer coming from acpi_bus_get_device() may become invalid before it subsequent dereference in the "if" block. To prevent that from happening, introduce a new function, acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device() except that it will grab a reference to the ACPI device object returned by it and it will do that under the ACPICA's namespace mutex. Then, make both acpi_hotplug_notify_cb() and acpi_bus_notify() use acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to ensure that the pointers used by them will not become stale at one point. In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper around put_device() to be used along with acpi_bus_get_acpi_device() and make the (new) users of the latter use acpi_bus_put_acpi_device() too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2014-01-29T10:47:18+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2014-01-29T10:47:18+00:00 urn:sha1:82e180598b54873553fb1d285fb0c90fc54f8f23 * acpi-processor: ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID" ACPI / processor: Return specific error value when mapping lapic id * acpi-hotplug: ACPI / scan: Clear match_driver flag in acpi_bus_trim() * acpi-init: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API * acpi-pm: ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices * acpica: ACPICA: Remove bool usage from ACPICA. 2014-01-28T21:37:22+00:00 Mark Brown broonie@linaro.org 2014-01-27T00:32:14+00:00 urn:sha1:49a12877d2777cadcb838981c3c4f5a424aef310 There is currently no facility in ACPI to express the hookup of voltage regulators, the expectation is that the regulators that exist in the system will be handled transparently by firmware if they need software control at all. This means that if for some reason the regulator API is enabled on such a system it should assume that any supplies that devices need are provided by the system at all relevant times without any software intervention. Tell the regulator core to make this assumption by calling regulator_has_full_constraints(). Do this as soon as we know we are using ACPI so that the information is available to the regulator core as early as possible. This will cause the regulator core to pretend that there is an always on regulator supplying any supply that is requested but that has not otherwise been mapped which is the behaviour expected on a system with ACPI. Should the ability to specify regulators be added in future revisions of ACPI then once we have support for ACPI mappings in the kernel the same assumptions will apply. It is also likely that systems will default to a mode of operation which does not require any interpretation of these mappings in order to be compatible with existing operating system releases so it should remain safe to make these assumptions even if the mappings exist but are not supported by the kernel. Signed-off-by: Mark Brown <broonie@linaro.org> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2013-12-31T12:41:08+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2013-12-31T12:41:08+00:00 urn:sha1:d1badf8d4323cfc9325b06651bdfcf7df09f1f0e Conflicts: include/acpi/acpi_bus.h