aboutsummaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)AuthorFilesLines
2017-08-17ACPI: EC: Fix regression related to wrong ECDT initialization orderLv Zheng3-12/+7
Commit 2a5708409e4e (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 c712bb58d827 (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: 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events) Fixes: c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe) Reported-by: Wang Wendy <wendy.wang@intel.com> Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-16ACPI: SPCR: work around clock issue on xgene UARTGraeme Gregory1-3/+11
xgene v1/v2 8250 UARTs don't run at the standard clock rate expected by the driver and there is no information on clocking available from the SPCR table. As there has been no progress on relevant vendors updating DBG2/SPCR specifications to fix this work around this using the previous xgene quirk handling to avoid setting a baud rate and therefore using the UART as configured by firmware. Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Tested-by: Mark Salter <msalter@redhat.com> Reviewed-by: Mark Salter <msalter@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-15ACPI: SPCR: extend XGENE 8250 workaround to m400Graeme Gregory1-3/+10
xgene v1/v2 chips are also used on moonshot cartridges that have different table headers to the ones on Mustang. Extend the quirk so it also recognises the Moonshot M400 variant too. Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Tested-by: Mark Salter <msalter@redhat.com> Reviewed-by: Mark Salter <msalter@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-13Merge tag 'tty-4.13-rc5' of ↵Linus Torvalds1-2/+34
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are two tty serial driver fixes for 4.13-rc5. One is a revert of a -rc1 patch that turned out to not be a good idea, and the other is a fix for the pl011 serial driver. Both have been in linux-next with no reported issues" * tag 'tty-4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "serial: Delete dead code for CIR serial ports" tty: pl011: fix initialization order of QDF2400 E44
2017-08-11PM / s2idle: Rename platform operations structureRafael J. Wysocki1-14/+14
Rename struct platform_freeze_ops to platform_s2idle_ops to make it clear that the callbacks in it are used during suspend-to-idle suspend/resume transitions and rename the related functions, variables and so on accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-11PM / s2idle: Rename ->enter_freeze to ->enter_s2idleRafael J. Wysocki1-3/+3
Rename the ->enter_freeze cpuidle driver callback to ->enter_s2idle to make it clear that it is used for entering suspend-to-idle and rename the related functions, variables and so on accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-11PM / s2idle: Rename PM_SUSPEND_FREEZE to PM_SUSPEND_TO_IDLERafael J. Wysocki1-1/+1
To make it clear that the symbol in question refers to suspend-to-idle, rename it from PM_SUSPEND_FREEZE to PM_SUSPEND_TO_IDLE. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-10ACPI/IORT: Fix build regression without IOMMUArnd Bergmann1-1/+1
A recent change reintroduced a bug that had previously been fixed by commit d49f2dedf33b ("ACPI/IORT: Fix CONFIG_IOMMU_API dependency"): drivers/acpi/arm64/iort.c: In function 'iort_iommu_configure': drivers/acpi/arm64/iort.c:829:26: error: 'struct iommu_fwspec' has no member named 'ops' Replace a direct reference to iommu_fwspec->ops with a helper function call to fix the issue. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-08-10ACPI / LPSS: Don't abort ACPI scan on missing mem resourceRonald Tschalär1-1/+2
The keyboard and touchpad on MacBook's from 2015 onwards are connected via an SPI bus. On MacBook8's (2015) the ACPI device for the SPI master for this bus has _CID "INT33C1", and hence the acpi-lpss handler here is triggered for it. However, the DSDT lists no memory resources for this device, resulting in an error being returned by the attach callback and therefore the SPI master device being ignored. This prevents us from being able to register the keyboard and touchpad driver. Furthermore, the controller (a Wildcat Point-LP controller) does not appear to need the functionality provided by the apci-lpss handler. Therefore we now just skip the handler if no memory resources are found and let the ACPI scan complete successfully for this device. All of this is not an issue on later MacBook(Pro)'s because their ACPI SPI devices don't have any _CID and therefore no attempt is made to attach this handler. Returning an error was introduced in commit d3e13ff3c1aa - this restores the original behaviour. Link: https://github.com/cb22/macbook12-spi-driver Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-08ACPI/IORT: numa: Add numa node mapping for smmuv3 devicesGanapatrao Kulkarni1-1/+28
ARM IORT specification(rev. C) has added provision to define proximity domain in SMMUv3 IORT table. Adding required code to parse Proximity domain and set numa_node of smmv3 platform devices. Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com> [lorenzo.pieralisi@arm.com: update pr_info()/commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2017-08-08ACPI/IORT: Handle PCI aliases properly for IOMMUsRobin Murphy1-52/+59
When a PCI device has DMA quirks, we need to ensure that an upstream IOMMU knows about all possible aliases, since the presence of a DMA quirk does not preclude the device still also emitting transactions (e.g. MSIs) on its 'real' RID. Similarly, the rules for bridge aliasing are relatively complex, and some bridges may only take ownership of transactions under particular transient circumstances, leading again to multiple RIDs potentially being seen at the IOMMU for the given device. Take all this into account in iort_iommu_configure() by mapping every RID produced by the alias walk, not just whichever one comes out last. Since adding any more internal PTR_ERR() juggling would have confused me no end, a bit of refactoring happens in the process - we know where to find the ops if everything succeeded, so we're free to just pass regular error codes around up until then. CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> CC: Hanjun Guo <hanjun.guo@linaro.org> CC: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [lorenzo.pieralisi@arm.com: tagged __get_pci_rid __maybe_unused] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2017-08-07nfit: cleanup long de-reference chains in acpi_nfit_init_interleave_setDan Williams1-12/+11
Use a local 'struct acpi_nfit_control_region *' variable to shorten the pointer chasing chains. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2017-08-07ACPI/IORT: Add IORT named component memory address limitsLorenzo Pieralisi1-17/+37
IORT named components provide firmware configuration describing how many address bits a given device is capable of generating to address memory. Add code to the kernel to retrieve memory address limits configuration for IORT named components and configure DMA masks accordingly. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Nate Watterson <nwatters@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-07ACPI: Make acpi_dma_configure() DMA regions awareLorenzo Pieralisi2-10/+39
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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Nate Watterson <nwatters@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-07ACPI: Introduce DMA ranges parsingLorenzo Pieralisi2-0/+114
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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Nate Watterson <nwatters@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-04nfit, libnvdimm, region: export 'position' in mapping infoDan Williams1-0/+24
It is useful to be able to know the position of a DIMM in an interleave-set. Consider the case where the order of the DIMMs changes causing a namespace to be invalidated because the interleave-set cookie no longer matches. If the before and after state of each DIMM position is known this state debugged by the system owner. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2017-08-05ACPI / PM: Prefer suspend-to-idle over S3 on some systemsRafael J. Wysocki1-0/+6
Modify the ACPI system sleep support setup code to select suspend-to-idle as the default system sleep state if (1) the ACPI_FADT_LOW_POWER_S0 flag is set in the FADT and (2) the Low Power Idle S0 _DSM interface has been discovered and (3) the default sleep state was not selected from the kernel command line. The main motivation for this change is that systems where the (1) and (2) conditions are met typically ship with OSes that don't exercise the S3 path in the platform firmware which remains untested and turns out to be non-functional at least in some cases. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
2017-08-04ACPI: Make acpi_dev_get_resources() method agnosticLorenzo Pieralisi1-22/+31
The function acpi_dev_get_resources() is completely generic and can be used to parse resource objects that are not necessarily coming from the _CRS method but also from other objects eg _DMA that have the same _CRS resource format. Create an acpi_dev_get_resources() helper, internal to the ACPI resources parsing compilation unit, __acpi_dev_get_resources(), that takes a const char* parameter to detect which ACPI method should be called to retrieve the resources list and make acpi_dev_get_resources() call it with a method name _CRS leaving the API behaviour unchanged. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Nate Watterson <nwatters@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-04Merge branch 'acpica' into acpi-dmaRafael J. Wysocki42-620/+1338
2017-08-03ACPICA: Revert "Update resource descriptor handling"Erik Schmauss1-9/+5
ACPICA commit f3300640c63df138d133740b54e2c0a1befa4086 This reverts commit c8eac10178b387f9eb1935694e509d4518da77bb. Link: https://github.com/acpica/acpica/commit/f3300640 Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Resources: Allow _DMA method in walk resourcesBob Moore1-3/+4
ACPICA commit af661c00afac7aa481a961fa48c6540a99ad64a6 The _DMA object contains a resource template, this change adds support for the walk resources function so that ACPI devices containing a _DMA object can actually parse it to detect DMA ranges for the respective bus. Link: https://github.com/acpica/acpica/commit/af661c00 Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Ensure all instances of AE_AML_INTERNAL have error messagesBob Moore5-0/+18
ACPICA commit ea9152daaec30760fa4c25285998f58233ec0db5 This exception is only meaningful with an associated error message. Link: https://github.com/acpica/acpica/commit/ea9152da Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Implement deferred resolution of reference package elementsBob Moore16-345/+661
ACPICA commit 0c08790c56fdf0dc081ae869495a09d8c4230854 This change defers the resolution of package elements that are named references until after the entire namespace has been loaded from the definition block. This allows such references to be in fact forward references for both module level code and control methods. Link: https://github.com/acpica/acpica/commit/0c08790c Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Debugger: Improve support for Alias objectsBob Moore2-13/+58
ACPICA commit 916993dbcd45b46e01f6c9b8337a01513f5d8dcc Properly resolve alias objects for display. General cleanup of related output. Link: https://github.com/acpica/acpica/commit/916993db Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Interpreter: Update handling for Alias operatorBob Moore1-47/+14
ACPICA commit 719d0bdd48e3e8e7a62a86c04922b9f41da6def0 Provide common creation code for the Alias operator. All objects are now handled the same, with the only exception being the Method() operator. It has a special internal Alias type. Link: https://github.com/acpica/acpica/commit/719d0bdd Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: EFI/EDK2: Cleanup to enable /WX for MSVC buildsLv Zheng1-3/+3
ACPICA commit a7c6d65a5dab20b1e191c197e09af337fc54b341 /WX turns warning into fatal erros for MSVC builds. We need /WX- during EDK2 porting to allow agile development. Now it is time to enable /WX and some explicit type conversion cleanups are required for enabling /WX. Lv Zheng. Link: https://github.com/acpica/acpica/commit/a7c6d65a Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: CLib: Add short multiply/shift supportLv Zheng5-16/+228
ACPICA commit 01b8f5a2350b9cc329cd8402ac8faec36fc501f5 In order to build ACPICA EFI tools with EDK-II on Windows, 64-bit multiply/shift supports are also required to be implemented. Otherwise, MSVC complains: acpidump.lib(utstrtoul64.obj) : error LNK2001: unresolved external symbol __allmul acpidump.lib(uthex.obj) : error LNK2001: unresolved external symbol __aullshr Note: 1. This patch also splits _EDK2_EFI from _GNU_EFI as they might have different math64 supports. 2. Support of gcc math64 is not included in this patch. 3. Support of EDK2 arch independent math64 is done via linking to base_lib. This patch fixes this issue. Reported by Shao Ming, fixed by Lv Zheng. For Linux kernel, this patch is a functional no-op. Link: https://github.com/acpica/acpica/commit/01b8f5a2 Tested-by: "Shao, Ming" <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Add a comment, no functional changeBob Moore1-0/+7
ACPICA commit d586c29a026a6172c1113df4d75fd6d764196e77 Describe 2nd byte of the end_tag resource descriptor. Link: https://github.com/acpica/acpica/commit/d586c29a Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Namespace: Update/fix an error messageBob Moore1-6/+16
ACPICA commit 8b7fa979ef81469e70f501f582466a265d6f595b Was emitting an internal namestring without converting it to the external format. Link: https://github.com/acpica/acpica/commit/8b7fa979 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPICA: Divergences: reduce access size definitionsLv Zheng2-5/+6
ACPICA commit cf27b3c98883d2a15d932016792fcb8272ace96d The following commit introduces definition of access width to ACPICA. Commit: 2bece49394872d36bbc5767fd643deac05920c55 Subject: ACPI: SPCR: Use access width to determine mmio usage Actually the access bit width can be calculated via access width. It would be better to define a macro calculating bit width rather than defining fixed values. This patch thus cleans up the definitions to reduce divergences. Link: https://github.com/acpica/acpica/commit/cf27b3c9 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPI / dock: constify attribute_group structureAmitoj Kaur Chawla1-1/+1
Functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 7902 3528 64 11494 2ce6 drivers/acpi/dock.o File size after: text data bss dec hex filename 7998 3432 64 11494 2ce6 drivers/acpi/dock.o This change was made with the help of Coccinelle. Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPI / scan: Recognize Apple SPI and I2C slavesLukas Wunner1-0/+7
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: Ronald Tschalär <ronald@innovation.ch> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPI / property: Support Apple _DSM propertiesLukas Wunner4-0/+151
While the rest of the world has standardized on _DSD as the way to store device properties in AML (introduced with ACPI 5.1 in 2014), Apple has been using a custom _DSM to achieve the same for much longer (ever since they switched from DeviceTree-based PowerPC to Intel in 2005, verified with MacOS X 10.4.11). The theory of operation on macOS is as follows: AppleACPIPlatform.kext invokes mergeEFIproperties() and mergeDSMproperties() for each device to merge properties conveyed by EFI drivers as well as properties stored in AML into the I/O Kit registry from which they can be retrieved by drivers. We've been supporting EFI properties since commit 58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties"). The present commit adds support for _DSM properties, thereby completing our support for Apple device properties. The _DSM properties are made available under the primary fwnode, the EFI properties under the secondary fwnode. So for devices which possess both property types, they can all be elegantly accessed with the uniform API in <linux/property.h>. Until recently we had no need to support _DSM properties, they contained only uninteresting garbage. The situation has changed with MacBooks and MacBook Pros introduced since 2015: Their keyboard is attached with SPI instead of USB and the _CRS data which is necessary to initialize the spi driver only contains valid information if OSPM responds "false" to _OSI("Darwin"). If OSPM responds "true", _CRS is empty and the spi driver fails to initialize. The rationale is very simple, Apple only cares about macOS and Windows: On Windows, _CRS contains valid data, whereas on macOS it is empty. Instead, macOS gleans the necessary data from the _DSM properties. Since Linux deliberately defaults to responding "true" to _OSI("Darwin"), we need to emulate macOS' behaviour by initializing the spi driver with data returned by the _DSM. An out-of-tree driver for the SPI keyboard exists which currently binds to the ACPI device, invokes the _DSM, parses the returned package and instantiates an SPI device with the data gleaned from the _DSM: https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4 https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1 By adding support for Apple's _DSM properties in generic ACPI code, the out-of-tree driver will be able to register as a regular SPI driver, significantly reducing its amount of code and improving its chances to be mainlined. The SPI keyboard will not be the only user of this commit: E.g. on the MacBook8,1, the UART-attached Bluetooth device likewise returns empty _CRS data if OSPM returns "true" to _OSI("Darwin"). The _DSM returns a Package whose format unfortunately deviates slightly from the _DSD spec: The properties are marshalled up in a single Package as alternating key/value elements, unlike _DSD which stores them as a Package of 2-element Packages. The present commit therefore converts the Package to _DSD format and the ACPI core can then treat the data as if Apple would follow the standard. Well, except for one small annoyance: The properties returned by the _DSM only ever have one of two types, Integer or Buffer. The former is retrievable as usual with device_property_read_u64(), but the latter is not part of the _DSD spec and it is not possible to retrieve Buffer properties with the device_property_read_*() functions due to the type checking performed in drivers/acpi/property.c. It is however possible to retrieve them with acpi_dev_get_property(). Apple is using the Buffer type somewhat sloppily to store null-terminated strings but also integers. The real data type is not distinguishable by the ACPI core and the onus is on the caller to use the contents of the Buffer in an appropriate way. In case Apple moves to _DSD in the future, this commit first checks for _DSD and falls back to _DSM only if _DSD is not found. Tested-by: Ronald Tschalär <ronald@innovation.ch> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPI / property: Don't evaluate objects for devices w/o handleLukas Wunner1-0/+3
Fabricated devices such as LNXPWRBN lack a handle, causing evaluation of _CCA and _DSD to always fail with AE_BAD_PARAMETER. While that is merely a (negligible) waste of processing power, evaluating a _DSM for them (such as Apple's device properties _DSM which we're about to add) results in an ugly error: ACPI: \: failed to evaluate _DSM (0x1001) Avoid by not evaluating _DSD and the upcoming _DSM for devices without handle. Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03treewide: Consolidate Apple DMI checksLukas Wunner3-54/+12
We're about to amend ACPI bus scan with DMI checks whether we're running on a Mac to support Apple device properties in AML. The DMI checks are performed for every single device, adding overhead for everything x86 that isn't Apple, which is the majority. Rafael and Andy therefore request to perform the DMI match only once and cache the result. Outside of ACPI various other Apple DMI checks exist and it seems reasonable to use the cached value there as well. Rafael, Andy and Darren suggest performing the DMI check in arch code and making it available with a header in include/linux/platform_data/x86/. To this end, add early_platform_quirks() to arch/x86/kernel/quirks.c to perform the DMI check and invoke it from setup_arch(). Switch over all existing Apple DMI checks, thereby fixing two deficiencies: * They are now #defined to false on non-x86 arches and can thus be optimized away if they're located in cross-arch code. * Some of them only match "Apple Inc." but not "Apple Computer, Inc.", which is used by BIOSes released between January 2006 (when the first x86 Macs started shipping) and January 2007 (when the company name changed upon introduction of the iPhone). Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Suggested-by: Darren Hart <dvhart@infradead.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03Merge branches 'acpi-soc', 'acpi-wdat' and 'acpi-cppc'Rafael J. Wysocki3-3/+22
* acpi-soc: ACPI: APD: Fix HID for Hisilicon Hip07/08 ACPI / LPSS: Only call pwm_add_table() for the first PWM controller * acpi-wdat: ACPI / watchdog: Fix init failure with overlapping register regions * acpi-cppc: mailbox: pcc: Fix crash when request PCC channel 0
2017-08-01ACPI / sleep: Make acpi_sleep_syscore_init() staticJean Delvare1-1/+1
Function acpi_sleep_syscore_init has no external user so it should be static. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-01ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()Rafael J. Wysocki1-22/+50
The acpi_pci_propagate_wakeup() routine is there to handle cases in which PCI bridges (or PCIe ports) are expected to signal wakeup for devices below them, but currently it doesn't do that correctly. The problem is that acpi_pci_propagate_wakeup() uses acpi_pm_set_device_wakeup() for bridges and if that routine is called for multiple times to disable wakeup for the same device, it will disable it on the first invocation and the next calls will have no effect (it works analogously when called to enable wakeup, but that is not a problem). Now, say acpi_pci_propagate_wakeup() has been called for two different devices under the same bridge and it has called acpi_pm_set_device_wakeup() for that bridge each time. The bridge is now enabled to generate wakeup signals. Next, suppose that one of the devices below it resumes and acpi_pci_propagate_wakeup() is called to disable wakeup for that device. It will then call acpi_pm_set_device_wakeup() for the bridge and that will effectively disable remote wakeup for all devices under it even though some of them may still be suspended and remote wakeup may be expected to work for them. To address this (arguably theoretical) issue, allow wakeup.enable_count under struct acpi_device to grow beyond 1 in certain situations. In particular, allow that to happen in acpi_pci_propagate_wakeup() when wakeup is enabled or disabled for PCI bridges, so that wakeup is actually disabled for the bridge when all devices under it resume and not when just one of them does that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2017-08-01ACPI / PM: Split acpi_device_wakeup()Rafael J. Wysocki1-42/+79
To prepare for a subsequent change and make the code somewhat easier to follow, do the following in the ACPI device wakeup handling code: * Replace wakeup.flags.enabled under struct acpi_device with wakeup.enable_count as that will be necessary going forward. For now, wakeup.enable_count is not allowed to grow beyond 1, so the current behavior is retained. * Split acpi_device_wakeup() into acpi_device_wakeup_enable() and acpi_device_wakeup_disable() and modify the callers of it accordingly. * Introduce a new acpi_wakeup_lock mutex to protect the wakeup enabling/disabling code from races in case it is executed more than once in parallel for the same device (which may happen for bridges theoretically). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2017-07-31ACPI: APEI: Enable APEI multiple GHES source to share a single external IRQLoc Ho1-1/+2
X-Gene platforms describe multiple GHES error sources with the same hardware error notification type (external interrupt) and interrupt number. Change the GHES interrupt request to support sharing the same IRQ. This change includs contributions from Tuan Phan <tphan@apm.com>. Signed-off-by: Loc Ho <lho@apm.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-30tty: pl011: fix initialization order of QDF2400 E44Timur Tabi1-2/+34
The work-around for Qualcomm Technologies QDF2400 Erratum 44 hinges on a global variable defined in the pl011 driver. The ACPI SPCR parsing code determines whether the work-around is needed, and if so, it changes the console name from "pl011" to "qdf2400_e44". The expectation is that the pl011 driver will implement the work-around when it sees the console name. The global variable qdf2400_e44_present is set when that happens. The problem is that work-around needs to be enabled when the pl011 driver probes, not when the console name is queried. However, sbsa_probe() is called before pl011_console_match(). The work-around appeared to work previously because the default console on QDF2400 platforms was always ttyAMA1. The first time sbsa_probe() is called (for ttyAMA0), qdf2400_e44_present is still false. Then pl011_console_match() is called, and it sets qdf2400_e44_present to true. All subsequent calls to sbsa_probe() enable the work-around. The solution is to move the global variable into spcr.c and let the pl011 driver query it during probe time. This works because all QDF2400 platforms require SPCR, so parse_spcr() will always be called. pl011_console_match still checks for the "qdf2400_e44" console name, but it doesn't do anything else special. Fixes: 5a0722b898f8 ("tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44") Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-30ACPI: APD: Fix HID for Hisilicon Hip07/08Hanjun Guo1-2/+2
ACPI HID for Hisilicon Hip07/08 should be HISI02A1/2, not HISI0A21/2, HISI02A1/2 was tested ok but was modified by the stupid typo when upstream the patches (by me), correct them to the right IDs (matching the IDs in drivers/i2c/busses/i2c-designware-platdrv.c). Fixes: 6e14cf361a0c (ACPI / APD: Add clock frequency for Hisilicon Hip07/08 I2C controller) Reported-by: Tao Tian <tiantao6@huawei.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-27Merge branches 'acpi-pm' and 'acpi-numa'Rafael J. Wysocki2-2/+10
* acpi-pm: ACPI / PM / EC: Flush all EC work in acpi_freeze_sync() ACPI / EC: Add parameter to force disable the GPE on suspend * acpi-numa: ACPI: NUMA: Fix typo in the full name of SRAT ACPI: NUMA: add missing include in acpi_numa.h
2017-07-27ACPI: processor: use dev_dbg() instead of dev_warn() when CPPC probe failedHanjun Guo1-1/+1
_CPC is a optinal object for processor device so it's fine for processor devices in DSDT without CPPC data, but when booting the system with CPPC enabled in the kernel but without its support in the firmware, I got lots of warnings on a 64 core system: [ 6.346016] acpi ACPI0007:00: CPPC data invalid or not present [ 6.346028] acpi ACPI0007:01: CPPC data invalid or not present [ 6.346039] acpi ACPI0007:02: CPPC data invalid or not present [ 6.346050] acpi ACPI0007:03: CPPC data invalid or not present [ 6.346063] acpi ACPI0007:04: CPPC data invalid or not present ... [ 6.346737] acpi ACPI0007:3f: CPPC data invalid or not present This isn't much useful and a little bit noise, so switch the dev_warn() to dev_dbg(). Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-26ACPI: device property: Switch to use new generic UUID APIAndy Shevchenko1-25/+25
There are new types and helpers that are supposed to be used in new code. As a preparation to get rid of legacy types and API functions do the conversion here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-26ACPI / watchdog: Fix init failure with overlapping register regionsRyan Kennedy1-1/+6
Partially overlapping regions cause platform device creation to fail. The latter of two overlapping resources will fail to be reserved. Fix this by merging overlapping resource ranges while enumerating WDAT table entries. Signed-off-by: Ryan Kennedy <ryan5544@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-24ACPI / lpat: Fix typos in comments and kerneldoc styleSumeet Pawnikar1-3/+3
This patch fix the typos in function header of acpi_lpat_raw_to_temp and acpi_lpat_temp_to_raw. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-24ACPI / PMIC: xpower: Do pinswitch magic when reading GPADCHans de Goede1-3/+18
Testing has shown that the TS-pin's bias-current needs to be disabled when reading the GPIO0 pin in GPADC mode. It seems that there is only 1 bias current source and to be able to use it for the GPIO0 pin in GPADC mode it must be temporarily turned off for the TS pin, but the datasheet does not mention this. This commit adds the necessary writes to turn the TS pin BIAS current off before and back on after reading the GPADC. This fixes the GPADC always returning a reading of 0. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-24ACPI: NUMA: Fix typo in the full name of SRATRoss Zwisler1-1/+1
To save someone the time of searching the ACPI spec for "Static Resource Affinity Table". Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-22device property: Introduce fwnode_property_get_reference_argsSakari Ailus1-0/+27
The new fwnode_property_get_reference_args() interface amends the fwnode property API with the functionality of both of_parse_phandle_with_args() and __acpi_node_get_property_reference(). The semantics is slightly different: the cells property is ignored on ACPI as the number of arguments can be explicitly obtained from the firmware interface. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Powered by cgit, Gruvboxed by Blaster4385.