- 21 11月, 2017 1 次提交
-
-
由 Lv Zheng 提交于
On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an ACPI device. Thus the following commit actually removed post-resume acpi_ec_enable_event() invocation for such platforms, and triggered a regression on them that after being resumed, EC (actually should be ECDT) driver stops handling EC events: Commit: c2b46d67 Subject: ACPI / EC: Add PM operations to improve event handling for resume process Notice that the root cause actually is "ECDT is not an ACPI device" rather than "the timing of acpi_ec_enable_event() invocation", this patch fixes this issue by enumerating ECDT EC as an ACPI device. Due to the existence of the noirq stage, the ability of tuning the timing of acpi_ec_enable_event() invocation is still meaningful. This patch is a little bit different from the posted fix by moving acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make sure that EC event handling won't be stopped as long as the ACPI EC driver is bound. Thus the following sequence shouldn't disable EC event handling: unbind,suspend,resume,bind. Fixes: c2b46d67 (ACPI / EC: Add PM operations to improve event handling for resume process) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847Reported-by: NLuya Tshimbalanga <luya@fedoraproject.org> Tested-by: NLuya Tshimbalanga <luya@fedoraproject.org> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 10月, 2017 1 次提交
-
-
由 Frédéric Danis 提交于
UART devices is expected to be enumerated by SerDev subsystem. During ACPI scan, serial devices behind SPI, I2C or UART buses are not enumerated, allowing them to be enumerated by their respective parents. Rename *spi_i2c_slave* to *serial_bus_slave* as this will be used for serial devices on serial buses (SPI, I2C or UART). On Macs an empty ResourceTemplate is returned for uart slaves. Instead the device properties "baud", "parity", "dataBits", "stopBits" are provided. Add a check for "baud" in acpi_is_serial_bus_slave(). Signed-off-by: NFrédéric Danis <frederic.danis.oss@gmail.com> Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk> Tested-by: NRonald Tschalär <ronald@innovation.ch> Tested-by: NPeter Y. Chuang <peteryuchuang@gmail.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 10月, 2017 1 次提交
-
-
由 Srinivas Pandruvada 提交于
Add functionality to read LPIT table, which provides: - Sysfs interface to read residency counters via /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us Here the count "low_power_idle_cpu_residency_us" shows the time spent by CPU package in low power state. This is read via MSR interface, which points to MSR for PKG C10. Here the count "low_power_idle_system_residency_us" show the count the system was in low power state. This is read via MMIO interface. This is mapped to SLP_S0 residency on modern Intel systems. This residency is achieved only when CPU is in PKG C10 and all functional blocks are in low power state. It is possible that none of the above counters present or anyone of the counter present or all counters present. For example: On my Kabylake system both of the above counters present. After suspend to idle these counts updated and prints: 6916179 6998564 This counter can be read by tools like turbostat to display. Or it can be used to debug, if modern systems are reaching desired low power state. - Provides an interface to read residency counter memory address This address can be used to get the base address of PMC memory mapped IO. This is utilized by intel_pmc_core driver to print more debug information. In addition, to avoid code duplication to read iomem, removed the read of iomem from acpi_os_read_memory() in osl.c and made a common function acpi_os_read_iomem(). This new function is used for reading iomem in in both osl.c and acpi_lpit.c. Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdfSigned-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 18 8月, 2017 2 次提交
-
-
由 Rafael J. Wysocki 提交于
On some systems the platform firmware expects GPEs to be enabled before the enumeration of devices and if that expectation is not met, the systems in question may not boot in some situations. For this reason, change the initialization ordering of the ACPI subsystem to make it enable GPEs before scanning the namespace for the first time in order to enumerate devices. Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com> Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NLv Zheng <lv.zheng@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Lv Zheng 提交于
Commit 2a570840 (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) introduced acpi_ec_ecdt_start(), but that function is invoked before acpi_ec_query_init(), which is too early. This causes the kernel to crash if an EC event occurs after boot, when ec_query_wq is not valid: BUG: unable to handle kernel NULL pointer dereference at 0000000000000102 ... Workqueue: events acpi_ec_event_handler task: ffff9f539790dac0 task.stack: ffffb437c0e10000 RIP: 0010:__queue_work+0x32/0x430 Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start() is actually a no-op in the majority of cases. However, commit c712bb58 (ACPI / EC: Add support to skip boot stage DSDT probe) caused the probing of the DSDT EC as the "boot EC" to be skipped when the ECDT EC is valid and uncovered the bug. Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init() in acpi_ec_init(). Link: https://jira01.devtools.intel.com/browse/LCK-4348 Fixes: 2a570840 (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) Fixes: c712bb58 (ACPI / EC: Add support to skip boot stage DSDT probe) Reported-by: NWang Wendy <wendy.wang@intel.com> Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 8月, 2017 2 次提交
-
-
由 Lorenzo Pieralisi 提交于
Current ACPI DMA configuration set-up device DMA capabilities through kernel defaults that do not take into account platform specific DMA configurations reported by firmware. By leveraging the ACPI acpi_dev_get_dma_resources() API, add code in acpi_dma_configure() to retrieve the DMA regions to correctly set-up PCI devices DMA parameters. Rework the ACPI IORT kernel API to make sure they can accommodate the DMA set-up required by firmware. By making PCI devices DMA set-up ACPI IORT specific, the kernel is shielded from unwanted regressions that could be triggered by parsing DMA resources on arches that were previously ignoring them (ie x86/ia64), leaving kernel behaviour unchanged on those arches. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Tested-by: NNate Watterson <nwatters@codeaurora.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lorenzo Pieralisi 提交于
Some devices have limited addressing capabilities and cannot reference the whole memory address space while carrying out DMA operations (eg some devices with bus address bits range smaller than system bus - which prevents them from using bus addresses that are otherwise valid for the system). The ACPI _DMA object allows bus devices to define the DMA window that is actually addressable by devices that sit upstream the bus, therefore providing a means to parse and initialize the devices DMA masks and addressable DMA range size. By relying on the generic ACPI kernel layer to retrieve and parse resources, introduce ACPI core code to parse the _DMA object. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: NNate Watterson <nwatters@codeaurora.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 8月, 2017 1 次提交
-
-
由 Lukas Wunner 提交于
SPI and I2C slaves are enumerated by their respective parents rather than the ACPI core. They are recognized by presence of _CRS resources, which however are missing on Macs. Check for presence of device properties instead. Reported-and-tested-by: NRonald Tschalär <ronald@innovation.ch> Signed-off-by: NLukas Wunner <lukas@wunner.de> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 7月, 2017 1 次提交
-
-
由 Sakari Ailus 提交于
Instead of relying on the struct fwnode_handle type field, define fwnode_operations structs for all separate types of fwnodes. To find out the type, compare to the ops field to relevant ops structs. This change has two benefits: 1. it avoids adding the type field to each and every instance of struct fwnode_handle, thus saving memory and 2. makes the ops field the single factor that defines both the types of the fwnode as well as defines the implementation of its operations, decreasing the possibility of bugs when developing code dealing with fwnode internals. Suggested-by: NRob Herring <robh@kernel.org> Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 7月, 2017 1 次提交
-
-
由 Lee, Chun-Yi 提交于
In hotplug logic, it always indicates non-specific failure to platform through _OST when handing ACPI hot-remove event failed. Then platform terminates the hot-remove process but it can not identify the reason. Base on current hot-remove code, there have two situations that it returns busy: - OSPM try to offline an individual device, but the device offline function returns "busy". - When the ejection event is applied to an "not offlined yet" container. OSPM sends a kobject change event to userspace and returns "busy". Both of them will returns -EBUSY to ACPI device hotplug function. Then, the hotplug function indicates non-specific failure to platform just like for any other error, e.g. -ENODEV or -EIO. The benefit to the platform for identifying the OS "busy" state is that it can use a different approach to handle the "busy" instead of simply terminating the hot-remove operation for an unknown reason. For example, the platform can wait for a while and then re-trigger hot-remove. Signed-off-by: N"Lee, Chun-Yi" <jlee@suse.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> [ rjw: Changelog massage ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 6月, 2017 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The run_wake flag in struct acpi_device_wakeup_flags stores the information on whether or not the device can generate wakeup signals at run time, but in ACPI that really is equivalent to being able to generate wakeup signals at all. In fact, run_wake will always be set after successful executeion of acpi_setup_gpe_for_wake(), but if that fails, the device will not be able to use a wakeup GPE at all, so it won't be able to wake up the systems from sleep states too. Hence, run_wake actually means that the device is capable of triggering wakeup and so it is equivalent to the valid flag. For this reason, drop run_wake from struct acpi_device_wakeup_flags and make sure that the valid flag is only set if acpi_setup_gpe_for_wake() has been successful. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 6月, 2017 3 次提交
-
-
由 Sakari Ailus 提交于
The device and fwnode property API supports Devicetree, ACPI and pset properties. The implementation of this functionality for each firmware type was embedded in the fwnode property core. Move it out to firmware type specific locations, making it easier to maintain. Depends-on: ("of: Move OF property and graph API from base.c to property.c") Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sakari Ailus 提交于
This will be needed in constifying the fwnode API. The side effects the function had have been moved to the callers. Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Jarkko Nikula 提交于
Commit f406270b ("ACPI / scan: Set the visited flag for all enumerated devices") caused that two group of special SPI or I2C devices do not enumerate. SPI and I2C devices are expected to be enumerated by the SPI and I2C subsystems but change caused that acpi_bus_attach() marks those devices with acpi_device_set_enumerated(). First group of devices are matched using Device Tree compatible property with special _HID "PRP0001". Those devices have matched scan handler, acpi_scan_attach_handler() retuns 1 and acpi_bus_attach() marks them with acpi_device_set_enumerated(). Second group of devices without valid _HID such as "LNXVIDEO" have device->pnp.type.platform_id set to zero and change again marks them with acpi_device_set_enumerated(). Fix this by flagging the SPI and I2C devices during struct acpi_device object initialization time and let the code in acpi_bus_attach() to go through the device_attach() and acpi_default_enumeration() path for all SPI and I2C devices. Fixes: f406270b (ACPI / scan: Set the visited flag for all enumerated devices) Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 5月, 2017 1 次提交
-
-
由 Sricharan R 提交于
While deferring the probe of IOMMU masters, xlate and add_device callbacks called from iort_iommu_configure can pass back error values like -ENODEV, which means the IOMMU cannot be connected with that master for real reasons. Before the IOMMU probe deferral, all such errors were ignored. Now all those errors are propagated back, killing the master's probe for such errors. Instead ignore all the errors except EPROBE_DEFER, which is the only one of concern and let the master work without IOMMU, thus restoring the old behavior. Also make explicit that acpi_dma_configure handles only -EPROBE_DEFER from iort_iommu_configure. Fixes: 5a1bb638 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: NSricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 20 4月, 2017 3 次提交
-
-
由 Sricharan R 提交于
This is an equivalent to the DT's handling of the iommu master's probe with deferred probing when the corrsponding iommu is not probed yet. The lack of a registered IOMMU can be caused by the lack of a driver for the IOMMU, the IOMMU device probe not having been performed yet, having been deferred, or having failed. The first case occurs when the firmware describes the bus master and IOMMU topology correctly but no device driver exists for the IOMMU yet or the device driver has not been compiled in. Return NULL, the caller will configure the device without an IOMMU. The second and third cases are handled by deferring the probe of the bus master device which will eventually get reprobed after the IOMMU. The last case is currently handled by deferring the probe of the bus master device as well. A mechanism to either configure the bus master device without an IOMMU or to fail the bus master device probe depending on whether the IOMMU is optional or mandatory would be a good enhancement. Tested-by: NHanjun Guo <hanjun.guo@linaro.org> Reviewed-by: NRobin Murphy <robin.murphy@arm.com> [Lorenzo: Added fixes for dma_coherent_mask overflow, acpi_dma_configure called multiple times for same device] Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NSricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Rafael J. Wysocki 提交于
acpi_bus_attach() does not check the visited flag for devices that have been enumerated already and some of them may be enumerated for multiple times as a result, because some callers of acpi_bus_scan() don't check the visited flag either. For this reason, modify acpi_bus_attach() to check the visited flag and avoid enumerating devices that have already been enumerated. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NJoey Lee <jlee@suse.com>
-
由 Rafael J. Wysocki 提交于
The current code in acpi_bus_attach() is inconsistent with respect to device objects with ACPI drivers bound to them, as it allows ACPI drivers to bind to device objects with existing "physical" device companions, but it doesn't allow "physical" device objects to be created for ACPI device objects with ACPI drivers bound to them. Thus, in some cases, the outcome depends on the ordering of events which is confusing at best. For this reason, modify acpi_bus_attach() to call acpi_default_enumeration() for device objects with the pnp.type.platform_id flag set regardless of whether or not any ACPI drivers are bound to them. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NJoey Lee <jlee@suse.com>
-
- 13 4月, 2017 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 10c7e20b (ACPI / scan: fix enumeration (visited) flags for bus rescans) attempted to fix a problem with ACPI-based enumerateion of I2C/SPI devices, but it forgot to ensure that the visited flag will be set for all of the other enumerated devices, so fix that. Fixes: 10c7e20b (ACPI / scan: fix enumeration (visited) flags for bus rescans) Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885Reported-and-tested-by: NKevin Locke <kevin@kevinlocke.name> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
-
由 Michal Hocko 提交于
/sys/firmware/acpi/hotplug/force_remove was presumably added to support auto offlining in the past. This is, however, inherently dangerous for some hotplugable resources like memory. The memory offlining fails when the memory is still in use and cannot be dropped or migrated. If we ignore the failure we are basically allowing for subtle memory corruption or a crash. We have actually noticed the later while hitting BUG() during the memory hotremove (remove_memory): ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL, check_memblock_offlined_cb); if (ret) BUG(); it took us quite non-trivial time realize that the customer had force_remove enabled. Even if the BUG was removed here and we could propagate the error up the call chain it wouldn't help at all because then we would hit a crash or a memory corruption later and harder to debug. So force_remove is unfixable for the memory hotremove. We haven't checked other hotplugable resources to be prone to a similar problems. Remove the force_remove functionality because it is not fixable currently. Keep the sysfs file and report an error if somebody tries to enable it. Encourage users to report about the missing functionality and work with them with an alternative solution. Reviewed-by: NLee, Chun-Yi <jlee@suse.com> Signed-off-by: NMichal Hocko <mhocko@suse.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 27 12月, 2016 1 次提交
-
-
由 Lv Zheng 提交于
Sometimes, the users may require a quirk to be provided from ACPI subsystem core to prevent a GPE from flooding. Normally, if a GPE cannot be dispatched, ACPICA core automatically prevents the GPE from firing. But there are cases the GPE is dispatched by _Lxx/_Exx provided via AML table, and OSPM is lacking of the knowledge to get _Lxx/_Exx correctly executed to handle the GPE, thus the GPE flooding may still occur. The existing quirk mechanism can be enabled/disabled using the following commands to prevent such kind of GPE flooding during runtime: # echo mask > /sys/firmware/acpi/interrupts/gpe00 # echo unmask > /sys/firmware/acpi/interrupts/gpe00 To avoid GPE flooding during boot, we need a boot stage mechanism. This patch provides such a boot stage quirk mechanism to stop this kind of GPE flooding. This patch doesn't fix any feature gap but since the new feature gaps could be found in the future endlessly, and can disappear if the feature gaps are filled, providing a boot parameter rather than a DMI table should suffice. Link: https://bugzilla.kernel.org/show_bug.cgi?id=53071 Link: https://bugzilla.kernel.org/show_bug.cgi?id=117481 Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 12月, 2016 1 次提交
-
-
由 Lorenzo Pieralisi 提交于
The introduction of acpi_dma_configure() allows to configure DMA and related IOMMU for any device that is DMA capable. To achieve that goal it ensures DMA masks are set-up to sane default values before proceeding with IOMMU and DMA ops configuration. On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is called for every device that has an ACPI companion, in that every device is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API), which has the side effect of initializing dma masks also for pseudo-devices (eg CPUs and memory nodes) and potentially for devices whose dma masks were not set-up before the acpi_dma_configure() API was introduced, which may have noxious side effects. Therefore, in preparation for IORT firmware specific DMA masks set-up, wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the default expected behaviour on x86/ia64 systems and keeping DMA default masks set-up on IORT based (ie ARM) arch configurations. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Tested-by: NHanjun Guo <hanjun.guo@linaro.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Sricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 30 11月, 2016 1 次提交
-
-
由 Zhang Rui 提交于
Starting from ACPI spec 3.0, it's only clarified that _BCM control method is required if _BCL is implemented. There is no word saying _BQC is required. And in ACPI spec 6.1 B.5.4, for _BQC, it is explicitly stated that "This optional method returns the current brightness level of a built-in display output device. If present, it must be set by the platform for initial brightness." Thus remove the obsolete warning message. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 29 11月, 2016 2 次提交
-
-
由 Lorenzo Pieralisi 提交于
DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the corresponding IOMMU operations necessary for DMA operations set-up. By relying on the iommu_fwspec generic kernel infrastructure, implement the IORT based IOMMU configuration for ARM ACPI systems and hook it up in the ACPI kernel layer that implements DMA configuration for a device. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ACPI core] Reviewed-by: NTomasz Nowicki <tn@semihalf.com> Tested-by: NHanjun Guo <hanjun.guo@linaro.org> Tested-by: NTomasz Nowicki <tn@semihalf.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
由 Lorenzo Pieralisi 提交于
On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This patch fills the gap by introducing acpi_dma_configure/deconfigure() calls that for now are just wrappers around arch_setup_dma_ops() and arch_teardown_dma_ops() and also updates ACPI and PCI core code to use the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions. Since acpi_dma_configure() is used to configure DMA operations, the function initializes the dma/coherent_dma masks to sane default values if the current masks are uninitialized (also to keep the default values consistent with DT systems) to make sure the device has a complete default DMA set-up. The DMA range size passed to arch_setup_dma_ops() is sized according to the device coherent_dma_mask (starting at address 0x0), mirroring the DT probing path behaviour when a dma-ranges property is not provided for the device being probed; this changes the current arch_setup_dma_ops() call parameters in the ACPI probing case, but since arch_setup_dma_ops() is a NOP on all architectures but ARM/ARM64 this patch does not change the current kernel behaviour on them. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci] Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NTomasz Nowicki <tn@semihalf.com> Tested-by: NHanjun Guo <hanjun.guo@linaro.org> Tested-by: NTomasz Nowicki <tn@semihalf.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: NWill Deacon <will.deacon@arm.com>
-
- 10 11月, 2016 1 次提交
-
-
由 Heikki Krogerus 提交于
We have a couple of drivers, acpi_apd.c and acpi_lpss.c, that need to pass extra build-in properties to the devices they create. Previously the drivers added those properties to the struct device which is member of the struct acpi_device, but that does not work. Those properties need to be assigned to the struct device of the platform device instead in order for them to become available to the drivers. To fix this, this patch changes acpi_create_platform_device function to take struct property_entry pointer as parameter. Fixes: 20a875e2 (serial: 8250_dw: Add quirk for APM X-Gene SoC) Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: NYazen Ghannam <yazen.ghannam@amd.com> Tested-by: NJérôme de Bretagne <jerome.debretagne@gmail.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 9月, 2016 1 次提交
-
-
由 Mika Westerberg 提交于
Starting from Intel Skylake the iTCO watchdog timer registers were moved to reside in the same register space with SMBus host controller. Not all needed registers are available though and we need to unhide P2SB (Primary to Sideband) device briefly to be able to read status of required NO_REBOOT bit. The i2c-i801.c SMBus driver used to handle this and creation of the iTCO watchdog platform device. Windows, on the other hand, does not use the iTCO watchdog hardware directly even if it is available. Instead it relies on ACPI Watchdog Action Table (WDAT) table to describe the watchdog hardware to the OS. This table contains necessary information about the the hardware and also set of actions which are executed by a driver as needed. This patch implements a new watchdog driver that takes advantage of the ACPI WDAT table. We split the functionality into two parts: first part enumerates the WDAT table and if found, populates resources and creates platform device for the actual driver. The second part is the driver itself. The reason for the split is that this way we can make the driver itself to be a module and loaded automatically if the WDAT table is found. Otherwise the module is not loaded. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 10 9月, 2016 1 次提交
-
-
由 Lv Zheng 提交于
It is possible to register _Qxx from namespace and use the ECDT EC to perform event handling. The reported bug reveals that Windows is using ECDT in this way in case the namespace EC is not present. This patch facilitates Linux to support ECDT in this way. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021Reported-and-tested-by: NLuya Tshimbalanga <luya@fedoraproject.org> Tested-by: NJonh Henderson <jw.hendy@gmail.com> Reviewed-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 9月, 2016 1 次提交
-
-
由 Lorenzo Pieralisi 提交于
Commit e647b532 ("ACPI: Add early device probing infrastructure") introduced code that allows inserting driver specific struct acpi_probe_entry probe entries into ACPI linker sections (one per-subsystem, eg irqchip, clocksource) that are then walked to retrieve the data and function hooks required to probe the respective kernel components. Probing for all entries in a section is triggered through the __acpi_probe_device_table() function, that in turn, according to the table ID a given probe entry reports parses the table with the function retrieved from the respective section structures (ie struct acpi_probe_entry). Owing to the current ACPI table parsing implementation, the __acpi_probe_device_table() function has to share global variables with the acpi_match_madt() function, so in order to guarantee mutual exclusion locking is required between the two functions. Current kernel code implements the locking through the acpi_probe_lock spinlock; this has the side effect of requiring all code called within the lock (ie struct acpi_probe_entry.probe_{table/subtbl} hooks) not to sleep. However, kernel subsystems that make use of the early probing infrastructure are relying on kernel APIs that may sleep (eg irq_domain_alloc_fwnode(), among others) in the function calls pointed at by struct acpi_probe_entry.{probe_table/subtbl} entries (eg gic_v2_acpi_init()), which is a bug. Since __acpi_probe_device_table() is called from context that is allowed to sleep the acpi_probe_lock spinlock can be replaced with a mutex; this fixes the issue whilst still guaranteeing mutual exclusion. Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Fixes: e647b532 (ACPI: Add early device probing infrastructure) Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 09 7月, 2016 2 次提交
-
-
由 Octavian Purdila 提交于
Add support for ACPI reconfiguration notifiers to allow subsystems to react to changes in the ACPI tables that happen after the initial enumeration. This is similar with the way dynamic device tree notifications work. The reconfigure notifications supported for now are device add and device remove. Since ACPICA allows only one table notification handler, this patch makes the table notifier function generic and moves it out of the sysfs specific code. Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Octavian Purdila 提交于
If the ACPI tables change as a result of a dinamically loaded table and a bus rescan is required the enumeration/visited flag are not consistent. I2C/SPI are not directly enumerated in acpi_bus_attach(), however the visited flag is set. This makes it impossible to check if an ACPI device has already been enumerated by the I2C and SPI subsystems. To fix this issue we only set the visited flags if the device is not I2C or SPI. With this change we also need to remove setting visited to false from acpi_bus_attach(), otherwise if we rescan already enumerated I2C/SPI devices we try to re-enumerate them. Note that I2C/SPI devices can be enumerated either via a scan handler (when using PRP0001) or via regular device_attach(). In either case the flow goes through acpi_default_enumeration() which makes it the ideal place to mark the ACPI device as enumerated. Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 7月, 2016 1 次提交
-
-
由 Shannon Zhao 提交于
ACPI 6.0 introduces a new table STAO to list the devices which are used by Xen and can't be used by Dom0. On Xen virtual platforms, the physical UART is used by Xen. So here it hides UART from Dom0. CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI) CC: Len Brown <lenb@kernel.org> (supporter:ACPI) CC: linux-acpi@vger.kernel.org (open list:ACPI) Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 2月, 2016 1 次提交
-
-
由 Graeme Gregory 提交于
On ARM64 some devices use the AMBA device and not the platform bus for probing so add support for this. Uses a dummy clock for apb_pclk as ACPI does not have a suitable clock representation and to keep the core AMBA bus code unchanged between probing methods. Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGraeme Gregory <graeme.gregory@linaro.org> Signed-off-by: NAleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 09 12月, 2015 2 次提交
-
-
由 Lukas Wunner 提交于
There's an idiom in use by 7 Linux drivers to detect the presence of a particular ACPI HID by walking the namespace with acpi_get_devices(). The callback passed to acpi_get_devices() is mostly identical across the drivers, leading to lots of duplicate code. Add acpi_dev_present(), the ACPI equivalent to pci_dev_present(), allowing us to deduplicate all that boilerplate in the drivers. Signed-off-by: NLukas Wunner <lukas@wunner.de> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lukas Wunner 提交于
acpi_device_add() allocates and adds an element to acpi_bus_id_list (or increments the instance count if the device's HID is already present in the list), but the element is never deleted from the list nor freed. Fix it. Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 11月, 2015 1 次提交
-
-
由 Aaron Lu 提交于
Some ACPI node's _STA will touch operation region field, since the evaluation of _STA in acpi_bus_type_and_status is very early, the operation region handler is not ready yet. Instead of fail that function and not creating the acpi_device node consequently, set status to 0 so that later when the driver for that device is probing, it can find the acpi_device node and proceed normally. And at that time, the handler for the operation region is ready and its _STA evaluation will succeed, its present status can be checked there. Even there will be no driver using this node later, it doesn't seem hurt to have one more acpi_device node created with status set to 0. This happens on Microsoft Surface 3, where the SPI device node NTRG's _STA touches GPIO fields and the SPI core driver will only enumerate SPI devices from ACPI if the acpi_device node is 1: created; 2: _STA indicates it's present. Note that due to another problem in SPI driver, for NTRG to be actually enumerated, some changes have to be made in the SPI layer, which is addressed by Mika(not send out yet): https://bugzilla.kernel.org/show_bug.cgi?id=104291#c23 Link: https://bugzilla.kernel.org/show_bug.cgi?id=104291Reported-by: NBastien Nocera <bugzilla@hadess.net> Signed-off-by: NAaron Lu <aaron.lu@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 07 11月, 2015 1 次提交
-
-
由 Suthikulpanit, Suravee 提交于
Adding acpi_get_dma_attr() to query DMA attributes of ACPI devices. It returns the enum dev_dma_attr, which communicates DMA information more clearly. This API replaces the acpi_check_dma(), which will be removed in subsequent patch. This patch also provides a convenient function, acpi_dma_supported(), to check DMA support of the specified ACPI device. Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 10月, 2015 1 次提交
-
-
由 Marc Zyngier 提交于
IRQ controllers and timers are the two types of device the kernel requires before being able to use the device driver model. ACPI so far lacks a proper probing infrastructure similar to the one we have with DT, where we're able to declare IRQ chips and clocksources inside the driver code, and let the core code pick it up and call us back on a match. This leads to all kind of really ugly hacks all over the arm64 code and even in the ACPI layer. In order to allow some basic probing based on the ACPI tables, introduce "struct acpi_probe_entry" which contains just enough data and callbacks to match a table, an optional subtable, and call a probe function. A driver can, at build time, register itself and expect being called if the right entry exists in the ACPI table. A acpi_probe_device_table() is provided, taking an identifier for a set of acpi_prove_entries, and iterating over the registered entries. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org> Acked-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NHanjun Guo <hanjun.guo@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 9月, 2015 2 次提交
-
-
由 Rasmus Villemoes 提交于
Empirically, acpi_add_id is mostly called with string literals, so using kstrdup_const for initializing struct acpi_hardware_id::id saves a little run-time memory and a string copy. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rasmus Villemoes 提交于
This is preparation for using kstrdup_const to initialize that member. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-