kernel/linux.git/drivers/acpi/scan.c, branch v4.11.5

ACPI / scan: Set the visited flag for all enumerated devices

2017-04-13T02:42:18+00:00

Commit 10c7e20b2ff3 (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: 10c7e20b2ff3 (ACPI / scan: fix enumeration (visited) flags for bus rescans) Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885 Reported-and-tested-by: Kevin Locke Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Cc: 4.8+ # 4.8+

ACPI / sysfs: Provide quirk mechanism to prevent GPE flooding

2016-12-26T22:16:39+00:00

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/887793 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

Merge tag 'acpi-extra-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2016-12-22T18:19:32+00:00

Pull more ACPI updates from Rafael Wysocki: "Here are new versions of two ACPICA changes that were deferred previously due to a problem they had introduced, two cleanups on top of them and the removal of a useless warning message from the ACPI core. Specifics: - Move some Linux-specific functionality to upstream ACPICA and update the in-kernel users of it accordingly (Lv Zheng) - Drop a useless warning (triggered by the lack of an optional object) from the ACPI namespace scanning code (Zhang Rui)" * tag 'acpi-extra-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / osl: Remove deprecated acpi_get_table_with_size()/early_acpi_os_unmap_memory() ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users ACPICA: Tables: Allow FADT to be customized with virtual address ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel ACPI: do not warn if _BQC does not exist

ACPI/IORT: Make dma masks set-up IORT specific

2016-12-06T15:57:33+00:00

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: Lorenzo Pieralisi Acked-by: Will Deacon Acked-by: Rafael J. Wysocki Reviewed-by: Hanjun Guo Tested-by: Hanjun Guo Cc: Will Deacon Cc: Hanjun Guo Cc: Bjorn Helgaas Cc: Robin Murphy Cc: Tomasz Nowicki Cc: Joerg Roedel Cc: "Rafael J. Wysocki" Cc: Sricharan R Signed-off-by: Joerg Roedel

ACPI: do not warn if _BQC does not exist

2016-11-29T22:19:46+00:00

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: Zhang Rui Signed-off-by: Rafael J. Wysocki

ACPI/IORT: Introduce iort_iommu_configure

2016-11-29T15:57:48+00:00

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: Lorenzo Pieralisi Acked-by: Rafael J. Wysocki [ACPI core] Reviewed-by: Tomasz Nowicki Tested-by: Hanjun Guo Tested-by: Tomasz Nowicki Cc: Hanjun Guo Cc: Tomasz Nowicki Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon

ACPI: Implement acpi_dma_configure

2016-11-29T15:57:44+00:00

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: Lorenzo Pieralisi Acked-by: Bjorn Helgaas [pci] Acked-by: Rafael J. Wysocki Reviewed-by: Tomasz Nowicki Tested-by: Hanjun Guo Tested-by: Tomasz Nowicki Cc: Bjorn Helgaas Cc: Robin Murphy Cc: Tomasz Nowicki Cc: Joerg Roedel Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon

Merge branch 'device-properties'

2016-11-11T22:23:02+00:00

* device-properties: ACPI / platform: Add support for build-in properties

ACPI / platform: Add support for build-in properties

2016-11-09T23:30:29+00:00

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: 20a875e2e86e (serial: 8250_dw: Add quirk for APM X-Gene SoC) Signed-off-by: Heikki Krogerus Tested-by: Yazen Ghannam Tested-by: Jérôme de Bretagne Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-wdat' and 'acpi-ec'

2016-10-01T23:40:07+00:00

* acpi-wdat: watchdog: wdat_wdt: Fix warning for using 0 as NULL watchdog: wdat_wdt: fix return value check in wdat_wdt_probe() platform/x86: intel_pmc_ipc: Do not create iTCO watchdog when WDAT table exists i2c: i801: Do not create iTCO watchdog when WDAT table exists mfd: lpc_ich: Do not create iTCO watchdog when WDAT table exists ACPI / watchdog: Add support for WDAT hardware watchdog * acpi-ec: ACPI / EC: Fix issues related to boot_ec ACPI / EC: Fix a gap that ECDT EC cannot handle EC events ACPI / EC: Fix a memory leakage issue in acpi_ec_add() ACPI / EC: Cleanup first_ec/boot_ec code ACPI / EC: Enable event freeze mode to improve event handling for suspend process ACPI / EC: Add PM operations to improve event handling for suspend process ACPI / EC: Add PM operations to improve event handling for resume process ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled ACPI / EC: Add EC_FLAGS_QUERY_ENABLED to reveal a hidden logic ACPI / EC: Add PM operations for suspend/resume noirq stage