- 15 9月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Make device_get_next_child_node() work with ACPI data-only subnodes introduced previously. Namely, replace acpi_get_next_child() with acpi_get_next_subnode() that can handle (and return) child device objects as well as child data-only subnodes of the given device and modify the ACPI part of the GPIO subsystem to handle data-only subnodes returned by it. To that end, introduce acpi_node_get_gpiod() taking a struct fwnode_handle pointer as the first argument. That argument may point to an ACPI device object as well as to a data-only subnode and the function should do the right thing (ie. look for the matching GPIO descriptor correctly) in either case. Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod() instead of acpi_get_gpiod_by_index() which automatically causes devm_get_gpiod_from_child() to work with ACPI data-only subnodes that may be returned by device_get_next_child_node() which in turn is required by the users of that function (the gpio_keys_polled and gpio-leds drivers). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 28 7月, 2015 1 次提交
-
-
由 Mika Westerberg 提交于
Some devices, like MFD subdevices, share a single ACPI companion device so that they are able to access their resources and children. However, currently all these subdevices are attached to the ACPI power domain and this might cause that the power methods for the companion device get called more than once. In order to solve this we attach the ACPI power domain only to the first physical device that is bound to the ACPI companion device. In case of MFD devices, this is the parent MFD device itself. Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
- 18 7月, 2015 4 次提交
-
-
由 Rafael J. Wysocki 提交于
Move the registration of the ACPI bus type to acpi_bus_init() and avoid using ACPI going forward if it fails (too many things depend on the presence of the ACPI bus type). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
To reduce the size of scan.c and improve the readability of it, move code related to device notification, the definitions of the ACPI bus operations and the driver management code to drivers/acpi/bus.c. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
To reduce the size of scan.c and improve the readability of it, move code related device matching into drivers/acpi/bus.c. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
To reduce the size of scan.c and improve the readability of it, move all code related to device sysfs, modalias creation etc. to a new file called device_sysfs.c. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 7月, 2015 1 次提交
-
-
由 Suthikulpanit, Suravee 提交于
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver acpi_match_table to match devices. However, for generic drivers, we do not want to list _HID for all supported devices. Also, certain classes of devices do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS, which specifies PCI-defined class code (i.e. base-class, subclass and programming interface). This patch adds support for matching ACPI devices using the _CLS method. To support loadable module, current design uses _HID or _CID to match device's modalias. With the new way of matching with _CLS this would requires modification to the current ACPI modalias key to include _CLS. This patch appends PCI-defined class-code to the existing ACPI modalias as following. acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>: E.g: # cat /sys/devices/platform/AMDI0600:00/modalias acpi:AMDI0600:010601: where bb is th base-class code, ss is te sub-class code, and pp is the programming interface code Since there would not be _HID/_CID in the ACPI matching table of the driver, this patch adds a field to acpi_device_id to specify the matching _CLS. static const struct acpi_device_id ahci_acpi_match[] = { { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) }, {}, }; In this case, the corresponded entry in modules.alias file would be: alias acpi*:010601:* ahci_platform Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 6月, 2015 1 次提交
-
-
由 Hans de Goede 提交于
This allows video_detect.c to be build as a module, this is a preparation patch for the backlight interface selection logic cleanup. Note this commit also causes acpi_is_video_device() to always be build indepedent of CONFIG_ACPI_VIDEO, as there is no reason to make its building depend on CONFIG_ACPI_VIDEO. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 6月, 2015 2 次提交
-
-
由 Suthikulpanit, Suravee 提交于
This patch implements support for ACPI _CCA object, which is introduced in ACPIv5.1, can be used for specifying device DMA coherency attribute. The parsing logic traverses device namespace to parse coherency information, and stores it in acpi_device_flags. Then uses it to call arch_setup_dma_ops() when creating each device enumerated in DSDT during ACPI scan. This patch also introduces acpi_dma_is_coherent(), which provides an interface for device drivers to check the coherency information similarly to the of_dma_is_coherent(). Signed-off-by: NMark Salter <msalter@redhat.com> Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mathias Krause 提交于
Make the button ACPI device ID array static const. Safes us a little bit of code. Signed-off-by: NMathias Krause <minipli@googlemail.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 23 5月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001 string. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
-
- 16 5月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The ACPI 6 specification has made some changes in the device power management area. In particular: * The D3hot power state is now supposed to be always available (instead of D3cold) and D3cold is only regarded as valid if the _PR3 object is present for the given device. * The required ordering of transitions into power states deeper than D0 is now such that for a transition into state Dx the _PSx method is supposed to be executed first, if present, and the states of the power resources the device depends on are supposed to be changed after that. * It is now explicitly forbidden to transition devices from lower-power (deeper) into higher-power (shallower) power states other than D0. Those changes have been made so the specification reflects the Windows' device power management code that the vast majority of systems using ACPI is validated against. To avoid artificial differences in ACPI device power management between Windows and Linux, modify the ACPI device power management code to follow the new specification. Add comments explaining the code flow in some unclear places. This only may affect some real corner cases in which the OS behavior expected by the firmware is different from the Windows one, but that's quite unlikely. The transition ordering change affects transitions to D1 and D2 which are rarely used (if at all) and into D3hot and D3cold for devices actually having _PR3, but those are likely to be validated against Windows anyway. The other changes may affect code calling acpi_device_get_power() or acpi_device_update_power() where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD (that's why the ACPI fan driver needs to be updated too) and since transitions into ACPI_STATE_D3_HOT may remove power now, it is better to avoid this one in acpi_pm_device_sleep_state() if the "no power off" PM QoS flag is set. The only existing user of acpi_device_can_poweroff() really cares about the case when _PR3 is present, so the change in that function should not cause any problems to happen too. A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT now and the compatibility with older systems should be covered automatically. In any case, if any real problems result from this, it still will be better to follow the Windows' behavior (which now is reflected by the specification too) in general and handle the cases when it doesn't work via quirks. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 4月, 2015 2 次提交
-
-
由 Rafael J. Wysocki 提交于
If the special PRP0001 device ID is present in the given device's list of ACPI/PNP IDs and the device has a valid "compatible" property in the _DSD, it should be enumerated using the default mechanism, unless some scan handlers match the IDs preceding PRP0001 in the device's list of ACPI/PNP IDs. In addition to that, no scan handlers matching the IDs following PRP0001 in that list should be attached to the device. To make that happen, define a scan handler that will match PRP0001 and trigger the default enumeration for the matching devices if the "compatible" property is present for them. Since that requires the check for platform_id and device->handler to be removed from acpi_default_enumeration(), move the fallback invocation of acpi_default_enumeration() to acpi_bus_attach() (after it's checked if there's a matching ACPI driver for the device), which is a better place to call it, and do the platform_id check in there too (device->handler is guaranteed to be unset at the point where the function is looking for a matching ACPI driver). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
acpi_scan_is_offline() may be called under the physical_node_lock lock of the given device object's parent, so prevent lockdep from complaining about that by annotating that instance with SINGLE_DEPTH_NESTING. Fixes: caa73ea1 (ACPI / hotplug / driver core: Handle containers in a special way) Reported-and-tested-by: NXie XiuQi <xiexiuqi@huawei.com> Reviewed-by: NToshi Kani <toshi.kani@hp.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 4月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit e1acdeb0 "ACPI / scan: Simplify acpi_match_device()" introduced code that may lead to a NULL pointer dereference when trying to unlock a mutex. Fix that. Fixes: e1acdeb0 "ACPI / scan: Simplify acpi_match_device()" Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 13 4月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, the ACPI modalias creation covers two mutually exclusive cases: If the PRP0001 device ID is present in the device's list of ACPI/PNP IDs and the "compatible" property is present in _DSD, the created modalias will follow the OF rules of modalias creation. Otherwise, ACPI rules are used. However, that is not really desirable, because the presence of PRP0001 in the list of device IDs generally does not preclude using other ACPI/PNP IDs with that device and those other IDs may be of higher priority. In those cases, the other IDs should take preference over PRP0001 and therefore they also should be present in the modalias. For this reason, rework the modalias creation for ACPI so that it shows both the ACPI-style and OF-style modalias strings if the device has a non-empty list of ACPI/PNP IDs (other than PRP0001) and a valid "compatible" property at the same time. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
- 10 4月, 2015 3 次提交
-
-
由 Rafael J. Wysocki 提交于
If the special PRP0001 device ID is present in a device's _CID list, it should not prevent any ACPI/PNP IDs preceding it in the device's list of identifiers from being matched first. That is, only if none of the IDs preceding PRP0001 in the device's PNP/ACPI IDs list matches the IDs recognized by the driver, the driver's list of "compatible" IDs should be matched against the device's "compatible" property, if present. In addition to that, drivers can provide both acpi_match_table and of_match_table at the same time and the of_compatible matching should be used in that case too if PRP0001 is present in the device's list of identifiers. To make that happen, rework acpi_driver_match_device() to do the "compatible" property check in addition to matching the driver's list of ACPI IDs against the device's one. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Redefine acpi_companion_match() to return an ACPI device object pointer instead of a bool and use it to remove some redundant code from acpi_match_device(). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Redefine the function used for matching the device's "compatible" property against a given list of "compatible" strings to take a pointer to that list instead of a driver object pointer to make it more general. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
- 18 3月, 2015 1 次提交
-
-
由 Aaron Lu 提交于
The fixed event handler should return a value that is either 0 or 1 meanning if the event is handled or not, instead of an acpi_status to mean if the handler runs well or not. Suggested-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NAaron Lu <aaron.lu@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 2月, 2015 1 次提交
-
-
由 Ken Xue 提交于
This new feature is to interpret AMD specific ACPI device to platform device such as I2C, UART, GPIO found on AMD CZ and later chipsets. It based on example intel LPSS. Now, it can support AMD I2C, UART and GPIO. Signed-off-by: NKen Xue <Ken.Xue@amd.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 1月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
-
- 13 12月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Two _DEP-related failure messages are printed as dev_err() which is unnecessary and annoying. Use dev_dbg() to print them. While at it, one of the messages should actually say it is related to _DEP, so modify it to that effect. Fixes: 40e7fcb1 (ACPI: Add _DEP support to fix battery issue on Asus T100TA) Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 11月, 2014 1 次提交
-
-
由 Lan Tianyu 提交于
ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate device objects that OSPM should assign a higher priority in start ordering due to future operation region accesses. On Asus T100TA, ACPI battery info are read from a I2C slave device via I2C operation region. Before I2C operation region handler is installed, battery _STA always returns 0. There is a _DEP method of designating start order under battery device node. This patch is to implement _DEP feature to fix battery issue on the Asus T100TA. Introducing acpi_dep_list and adding dep_unmet count in struct acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a valid pair of master (device pointed to by _DEP)/ slave(device with _DEP), record master's and slave's ACPI handle in it and put it into acpi_dep_list. The dep_unmet count will increase by one if there is a device under its _DEP. Driver's probe() should return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C operation region handler is installed, remove all struct acpi_dep_data on the acpi_dep_list whose master is pointed to I2C host controller and decrease slave's dep_unmet. When dep_unmet decreases to 0, all _DEP conditions are met and then do acpi_bus_attach() for the device in order to resolve battery _STA issue on the Asus T100TA. Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011Tested-by: NJan-Michael Brummer <jan.brummer@tabos.org> Tested-by: NAdam Williamson <adamw@happyassassin.net> Tested-by: NMichael Shigorin <shigorin@gmail.com> Acked-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 11月, 2014 3 次提交
-
-
由 Rafael J. Wysocki 提交于
Add new generic routines are provided for retrieving properties from device description objects in the platform firmware in case there are no struct device objects for them (either those objects have not been created yet or they do not exist at all). The following functions are provided: fwnode_property_present() fwnode_property_read_u8() fwnode_property_read_u16() fwnode_property_read_u32() fwnode_property_read_u64() fwnode_property_read_string() fwnode_property_read_u8_array() fwnode_property_read_u16_array() fwnode_property_read_u32_array() fwnode_property_read_u64_array() fwnode_property_read_string_array() in analogy with the corresponding functions for struct device added previously. For all of them, the first argument is a pointer to struct fwnode_handle (new type) that allows a device description object (depending on what platform firmware interface is in use) to be obtained. Add a new macro device_for_each_child_node() for iterating over the children of the device description object associated with a given device and a new function device_get_child_node_count() returning the number of a given device's child nodes. The interface covers both ACPI and Device Trees. Suggested-by: NGrant Likely <grant.likely@linaro.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NGrant Likely <grant.likely@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
We have lots of existing Device Tree enabled drivers and allocating separate _HID for each is not feasible. Instead we allocate special _HID "PRP0001" that means that the match should be done using Device Tree compatible property using driver's .of_match_table instead if the driver is missing .acpi_match_table. If there is a need to distinguish from where the device is enumerated (DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev). Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGrant Likely <grant.likely@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Device Tree is used in many embedded systems to describe the system configuration to the OS. It supports attaching properties or name-value pairs to the devices it describe. With these properties one can pass additional information to the drivers that would not be available otherwise. ACPI is another configuration mechanism (among other things) typically seen, but not limited to, x86 machines. ACPI allows passing arbitrary data from methods but there has not been mechanism equivalent to Device Tree until the introduction of _DSD in the recent publication of the ACPI 5.1 specification. In order to facilitate ACPI usage in systems where Device Tree is typically used, it would be beneficial to standardize a way to retrieve Device Tree style properties from ACPI devices, which is what we do in this patch. If a given device described in ACPI namespace wants to export properties it must implement _DSD method (Device Specific Data, introduced with ACPI 5.1) that returns the properties in a package of packages. For example: Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"name1", <VALUE1>}, Package () {"name2", <VALUE2>}, ... } }) The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301 and is documented in the ACPI 5.1 companion document called "_DSD Implementation Guide" [1], [2]. We add several helper functions that can be used to extract these properties and convert them to different Linux data types. The ultimate goal is that we only have one device property API that retrieves the requested properties from Device Tree or from ACPI transparent to the caller. [1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm [2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdfReviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Reviewed-by: NJosh Triplett <josh@joshtriplett.org> Reviewed-by: NGrant Likely <grant.likely@linaro.org> Signed-off-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 10月, 2014 1 次提交
-
-
由 Mika Westerberg 提交于
Commit 6ab34301 ("mfd: Add ACPI support") made the MFD subdevices share the parent MFD ACPI companion if no _HID/_CID is specified for the subdevice in mfd_cell description. However, since all the subdevices share the ACPI companion, the match and modalias generation logic started to use the ACPI companion as well resulting this: # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias acpi:INT33D1:PNP0C50: instead of the expected one # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias platform:HID-SENSOR-200041 In other words the subdevice modalias is overwritten by the one taken from ACPI companion. This causes udev not to load the driver anymore. It is useful to be able to share the ACPI companion so that MFD subdevices (and possibly other devices as well) can access the ACPI resources even if they do not have ACPI representation in the namespace themselves. An example where this is used is Minnowboard LPC driver that creates GPIO as a subdevice among other things. Without the ACPI companion gpiolib is not able to lookup the corresponding GPIO controller from ACPI GpioIo resource. To fix this, restrict the match and modalias logic to be limited to the first (primary) physical device associated with the given ACPI comapnion. The secondary devices will still be able to access the ACPI companion, but they will be matched in a different way. Fixes: 6ab34301 (mfd: Add ACPI support) Reported-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 10月, 2014 1 次提交
-
-
由 Lv Zheng 提交于
This patch is partial linuxized result of the following ACPICA commit: ACPICA commit: a73b66c6aa1846d055bb6390d9c9b9902f7d804d Subject: Add "has handler" flag to event/gpe status interfaces. This change adds a new flag, ACPI_EVENT_FLAGS_HAS_HANDLER to the acpi_get_event_status and acpi_get_gpe_status external interfaces. It is set if the event/gpe currently has a handler associated with it. This patch contains the code to rename ACPI_EVENT_FLAG_HANDLE to ACPI_EVENT_FLAG_HAS_HANDLER, and the corresponding updates of its usages. Link: https://github.com/acpica/acpica/commit/a73b66c6Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 9月, 2014 1 次提交
-
-
由 Mika Westerberg 提交于
There is a typo, it should be negative -errno instead. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 9月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 46394fd0 (ACPI / hotplug: Move container-specific code out of the core) removed the generation of "online" uevents for containers, because "add" uevents are now generated for them automatically when container system devices are registered. However, there are user space tools that need to be notified when the container and all of its children have been enumerated, which doesn't happen any more. For this reason, add a mechanism allowing "online" uevents to be generated for ACPI containers after enumerating the container along with all of its children. Fixes: 46394fd0 (ACPI / hotplug: Move container-specific code out of the core) Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 11 9月, 2014 1 次提交
-
-
由 Zhang Rui 提交于
Newer laptops and tablets that use ACPI may have thermal sensors and other devices with thermal control capabilities outside the core CPU/SOC, for thermal safety reasons. They are exposed for the OS to use via 1) INT3400 ACPI device object as the master. 2) INT3401 ~ INT340B ACPI device objects as the slaves. This patch introduces a scan handler to enumerate the INT3400 ACPI device object to platform bus, and prevent its slaves from being enumerated before the controller driver being probed. Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 04 9月, 2014 1 次提交
-
-
由 Yasuaki Ishimatsu 提交于
The _SUN device indentification object is not guaranteed to return the same value every time it is executed, so we should not cache its return value, but rather execute it every time as needed. If it is cached, an incorrect stale value may be used in some situations. This issue was exposed by commit 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fix it by avoiding to cache the return value of _SUN. Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 8月, 2014 2 次提交
-
-
由 Lan Tianyu 提交于
Currently, notify callbacks for fixed button events are run from interrupt context. That is not necessary and after commit 0bf6368e (ACPI / button: Add ACPI Button event via netlink routine) it causes netlink routines to be called from interrupt context which is not correct. Also, that is different from non-fixed device events (including non-fixed button events) whose notify callbacks are all executed from process context. For the above reasons, make fixed button device notify callbacks run in process context which will avoid the deadlock when using netlink to report button events to user space. Fixes: 0bf6368e (ACPI / button: Add ACPI Button event via netlink routine) Link: https://lkml.org/lkml/2014/8/21/606Reported-by: NBenjamin Block <bebl@mageta.org> Reported-by: NKnut Petersen <Knut_Petersen@t-online.de> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> [rjw: Function names, subject and changelog.] Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
We generally don't allow ACPI drivers to bind to ACPI device objects that companion "physical" device objects are created for to avoid situations in which two different drivers may attempt to handle one device at the same time. Recent ACPI device enumeration rework extended that approach to ACPI PNP devices by starting to use a scan handler for enumerating them. However, we previously allowed ACPI drivers to bind to ACPI device objects with existing PNP device companions and changing that led to functional regressions on some systems. For this reason, add a special check for PNP devices in acpi_device_probe() so that ACPI drivers can bind to ACPI device objects having existing PNP device companions as before. Fixes: eec15edb (ACPI / PNP: use device ID list for PNPACPI device enumeration) Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511 Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971Reported-by: NGabriele Mazzotta <gabriele.mzt@gmail.com> Reported-by: NDirk Griesbach <spamthis@freenet.de> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 8月, 2014 1 次提交
-
-
由 Tang Chen 提交于
When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach is not set. In acpi_scan_attach_handler(), the acpi_device->handler will not be initialized. In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL. If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel will panic. BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4 PGD 0 Oops: 0000 [#1] SMP Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E) CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G E 3.16.0-rc7--3.16-rc7-tangchen+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Workqueue: kacpi_hotplug acpi_hotplug_work_fn task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000 RIP: 0010:[<ffffffff813e318f>] [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4 RSP: 0000:ffff880018257da8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246 RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0 R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003 R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Stack: 00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58 ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00 0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480 Call Trace: [<ffffffff813dc31d>] acpi_hotplug_work_fn+0x1e/0x29 [<ffffffff8108eefb>] process_one_work+0x17b/0x460 [<ffffffff8108f69d>] worker_thread+0x11d/0x5b0 [<ffffffff8108f580>] ? rescuer_thread+0x3a0/0x3a0 [<ffffffff81096811>] kthread+0xe1/0x100 [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0 [<ffffffff816cc6bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0 This patch fixes this problem by checking if acpi_device->handler is NULL in acpi_scan_hot_remove(). Fixes: d22ddcbc (ACPI / hotplug: Add demand_offline hotplug profile flag) Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [rjw: Subject] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 7月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The ACPI device enumeration code in Linux assumes that buttons always are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them which leads to undesirable side effects. Namely, that function sets up implicit device wake notification mechanism for a given GPE if there is no handler method in the ACPI namespace, which from the ACPICA's perspective means that there always is a way to handle that GPE if enabled. However, we don't handle wake notify events for buttons, so if there are no handler methods for their GPEs in the namespace, enabling a button GPE at run time leads to a GPE storm in some cases (the GPE triggers, ACPICA carries out the implicit wake notification for it which isn't handled, so the GPE triggers again and so on). To prevent that from happening use acpi_mark_gpe_for_wake() instead of acpi_setup_gpe_for_wake() for buttons which will cause ACPICA to only enable button GPEs if there are handler methods for the in the namespace. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 16 7月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Since all of the acpi_set_hp_context() callers pass at least one NULL function pointer and one caller passes NULL function pointers only to it, drop function pointer arguments from acpi_set_hp_context() and make the callers initialize the function pointers in struct acpi_hotplug_context by themselves before passing it to acpi_set_hp_context(). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 30 5月, 2014 2 次提交
-
-
由 Zhang Rui 提交于
Because of the growing demand for enumerating ACPI devices to platform bus, change the code to enumerate ACPI device objects to platform bus by default. Namely, create platform devices for the ACPI device objects that 1. Have pnp.type.platform_id set (device objects with _HID currently). 2. Do not have a scan handler attached. 3. Are not SPI/I2C slave devices (that should be enumerated to the appropriate buses bus by their parent). Signed-off-by: NZhang Rui <rui.zhang@intel.com> [rjw: Subject and changelog, rebase and code cleanup] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Rafael J. Wysocki 提交于
Currently, some scan handlers can be compiled out entirely, which leaves the device objects they normally attach to without a scan handler. This isn't a problem as long as we don't have any default enumeration mechanism that applies to all devices without a scan handler. However, if such a default enumeration is added, it still should not be applied to devices that are normally attached to by scan handlers, because that may result in creating "physical" device objects of a wrong type for them. Since we are going to create platform device objects for all ACPI device objects with pnp.type.platform_id set by default, clear pnp.type.platform_id where there is a matching scan handler without an .attach() callback and otherwise simply treat that scan handler as though the .attach() callback was present but always returned 0. This will allow us to compile out scan handler callbacks and leave the device ID lists used by them so as to prevent creating platform device objects for the matching ACPI devices. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-