summaryrefslogtreecommitdiff
path: root/drivers/acpi/scan.c
AgeCommit message (Collapse)AuthorFilesLines
2016-10-02Merge branches 'acpi-wdat' and 'acpi-ec'Rafael J. Wysocki1-0/+2
* 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
2016-09-24ACPI / watchdog: Add support for WDAT hardware watchdogMika Westerberg1-0/+1
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: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10ACPI / EC: Fix a gap that ECDT EC cannot handle EC eventsLv Zheng1-0/+1
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=115021 Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org> Tested-by: Jonh Henderson <jw.hendy@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-02ACPI / drivers: replace acpi_probe_lock spinlock with mutexLorenzo Pieralisi1-3/+3
Commit e647b532275b ("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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Fixes: e647b532275b (ACPI: Add early device probing infrastructure) Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-27Merge tag 'for-linus-4.8-rc0-tag' of ↵Linus Torvalds1-0/+74
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen updates from David Vrabel: "Features and fixes for 4.8-rc0: - ACPI support for guests on ARM platforms. - Generic steal time support for arm and x86. - Support cases where kernel cpu is not Xen VCPU number (e.g., if in-guest kexec is used). - Use the system workqueue instead of a custom workqueue in various places" * tag 'for-linus-4.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: (47 commits) xen: add static initialization of steal_clock op to xen_time_ops xen/pvhvm: run xen_vcpu_setup() for the boot CPU xen/evtchn: use xen_vcpu_id mapping xen/events: fifo: use xen_vcpu_id mapping xen/events: use xen_vcpu_id mapping in events_base x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to shared_info x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op xen: introduce xen_vcpu_id mapping x86/acpi: store ACPI ids from MADT for future usage x86/xen: update cpuid.h from Xen-4.7 xen/evtchn: add IOCTL_EVTCHN_RESTRICT xen-blkback: really don't leak mode property xen-blkback: constify instance of "struct attribute_group" xen-blkfront: prefer xenbus_scanf() over xenbus_gather() xen-blkback: prefer xenbus_scanf() over xenbus_gather() xen: support runqueue steal time on xen arm/xen: add support for vm_assist hypercall xen: update xen headers xen-pciback: drop superfluous variables xen-pciback: short-circuit read path used for merging write values ...
2016-07-08ACPI: add support for ACPI reconfiguration notifiersOctavian Purdila1-1/+67
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: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-08ACPI / scan: fix enumeration (visited) flags for bus rescansOctavian Purdila1-6/+7
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: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-06Xen: ACPI: Hide UART used by XenShannon Zhao1-0/+74
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: Shannon Zhao <shannon.zhao@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-16ACPI / scan: AMBA bus probing supportGraeme Gregory1-0/+1
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: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-09ACPI / utils: Add acpi_dev_present()Lukas Wunner1-7/+1
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: Lukas Wunner <lukas@wunner.de> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-09ACPI / scan: Fix acpi_bus_id_list bookkeepingLukas Wunner1-0/+14
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: Lukas Wunner <lukas@wunner.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-30ACPI / scan: set status to 0 if _STA failedAaron Lu1-1/+1
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=104291 Reported-by: Bastien Nocera <bugzilla@hadess.net> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-07Merge branch 'acpi-pci'Rafael J. Wysocki1-0/+42
* acpi-pci: PCI: ACPI: Add support for PCI device DMA coherency PCI: OF: Move of_pci_dma_configure() to pci_dma_configure() of/pci: Fix pci_get_host_bridge_device leak device property: ACPI: Remove unused DMA APIs device property: ACPI: Make use of the new DMA Attribute APIs device property: Adding DMA Attribute APIs for Generic Devices ACPI: Adding DMA Attribute APIs for ACPI Device device property: Introducing enum dev_dma_attr ACPI: Honor ACPI _CCA attribute setting Conflicts: drivers/crypto/ccp/ccp-platform.c
2015-11-07ACPI: Adding DMA Attribute APIs for ACPI DeviceSuthikulpanit, Suravee1-0/+42
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: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-25Merge branch 'acpi-init'Rafael J. Wysocki1-0/+39
* acpi-init: clocksource: cosmetic: Drop OF 'dependency' from symbols clocksource / arm_arch_timer: Convert to ACPI probing clocksource: Add new CLKSRC_{PROBE,ACPI} config symbols clocksource / ACPI: Add probing infrastructure for ACPI-based clocksources irqchip / GIC: Convert the GIC driver to ACPI probing irqchip / ACPI: Add probing infrastructure for ACPI-based irqchips ACPI: Add early device probing infrastructure
2015-10-25Merge branches 'acpi-scan', 'acpi-tables', 'acpi-ec' and 'acpi-assorted'Rafael J. Wysocki1-4/+4
* acpi-scan: ACPI / scan: use kstrdup_const() in acpi_add_id() ACPI / scan: constify struct acpi_hardware_id::id ACPI / scan: constify first argument of struct acpi_scan_handler::match * acpi-tables: ACPI / tables: test the correct variable x86, ACPI: Handle apic/x2apic entries in MADT in correct order ACPI / tables: Add acpi_subtable_proc to ACPI table parsers * acpi-ec: ACPI / EC: Fix a race issue in acpi_ec_guard_event() ACPI / EC: Fix query handler related issues * acpi-assorted: ACPI: change acpi_sleep_proc_init() to return void ACPI: change init_acpi_device_notify() to return void
2015-10-01ACPI: Add early device probing infrastructureMarc Zyngier1-0/+39
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: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-15ACPI / scan: use kstrdup_const() in acpi_add_id()Rasmus Villemoes1-2/+2
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: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-15ACPI / scan: constify struct acpi_hardware_id::idRasmus Villemoes1-2/+2
This is preparation for using kstrdup_const to initialize that member. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-15ACPI / property: Extend device_get_next_child_node() to data-only nodesRafael J. Wysocki1-20/+0
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-29Merge branch 'acpi-scan' into acpi-pmRafael J. Wysocki1-874/+0
Conflicts: drivers/acpi/scan.c The conflict is resolved by moving the just introduced acpi_device_is_first_physical_node() to bus.c and using the existing acpi_companion_match() from there. There will be an additional commit to combine the two.
2015-07-28ACPI / PM: Attach ACPI power domain only onceMika Westerberg1-16/+30
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-07-17ACPI / bus: Move ACPI bus type registrationRafael J. Wysocki1-6/+0
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-17ACPI / scan: Move bus operations and notification routines to bus.cRafael J. Wysocki1-183/+0
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-17ACPI / scan: Move device matching code to bus.cRafael J. Wysocki1-189/+0
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-17ACPI / scan: Move sysfs-related device code to a separate fileRafael J. Wysocki1-482/+1
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07ACPI / scan: Add support for ACPI _CLS device matchingSuthikulpanit, Suravee1-2/+30
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: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-19Merge branch 'acpi-cca'Rafael J. Wysocki1-0/+35
* acpi-cca: ufs: fix TRUE and FALSE re-define build error megaraid_sas: fix TRUE and FALSE re-define build error amd-xgbe: Unify coherency checking logic with device_dma_is_coherent() crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() device property: Introduces device_dma_is_coherent() arm64 : Introduce support for ACPI _CCA object ACPI / scan: Parse _CCA and setup device coherency
2015-06-19Merge branch 'acpi-video'Rafael J. Wysocki1-0/+56
* acpi-video: (38 commits) ACPI / video: Make acpi_video_unregister_backlight() private acpi-video-detect: Remove old API toshiba-acpi: Port to new backlight interface selection API thinkpad-acpi: Port to new backlight interface selection API sony-laptop: Port to new backlight interface selection API samsung-laptop: Port to new backlight interface selection API msi-wmi: Port to new backlight interface selection API msi-laptop: Port to new backlight interface selection API intel-oaktrail: Port to new backlight interface selection API ideapad-laptop: Port to new backlight interface selection API fujitsu-laptop: Port to new backlight interface selection API eeepc-laptop: Port to new backlight interface selection API dell-wmi: Port to new backlight interface selection API dell-laptop: Port to new backlight interface selection API compal-laptop: Port to new backlight interface selection API asus-wmi: Port to new backlight interface selection API asus-laptop: Port to new backlight interface selection API apple-gmux: Port to new backlight interface selection API acer-wmi: Port to new backlight interface selection API ACPI / video: Fix acpi_video _register vs _unregister_backlight race ...
2015-06-19Merge branches 'acpi-pm', 'acpi-apei', 'acpi-osl' and 'acpi-pci'Rafael J. Wysocki1-20/+6
* acpi-pm: ACPI / PM: Add missing pm_generic_complete() invocation ACPI / PM: Turn power resources on and off in the right order during resume ACPI / PM: Rework device power management to follow ACPI 6 ACPI / PM: Drop stale comment from acpi_power_transition() * acpi-apei: GHES: Make NMI handler have a single reader GHES: Elliminate double-loop in the NMI handler GHES: Panic right after detection GHES: Carve out the panic functionality GHES: Carve out error queueing in a separate function * acpi-osl: ACPI / osl: use same type for acpi_predefined_names values as in definition * acpi-pci: ACPI / PCI: remove stale list_head in struct acpi_prt_entry
2015-06-19acpi-video-detect: Move acpi_is_video_device() to acpi/scan.cHans de Goede1-0/+56
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: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15ACPI / scan: Parse _CCA and setup device coherencySuthikulpanit, Suravee1-0/+35
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: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15ACPI / scan: constify ACPI device idsMathias Krause1-1/+1
Make the button ACPI device ID array static const. Safes us a little bit of code. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-22ACPI / property: Define a symbol for PRP0001Rafael J. Wysocki1-13/+15
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001 string. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
2015-05-16ACPI / PM: Rework device power management to follow ACPI 6Rafael J. Wysocki1-20/+6
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-24ACPI / scan: Add a scan handler for PRP0001Rafael J. Wysocki1-5/+28
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Darren Hart <dvhart@linux.intel.com>
2015-04-24ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()Rafael J. Wysocki1-1/+5
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: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a special way) Reported-and-tested-by: Xie XiuQi <xiexiuqi@huawei.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-13ACPI / scan: Fix NULL pointer dereference in acpi_companion_match()Rafael J. Wysocki1-2/+4
Commit e1acdeb0e770 "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: e1acdeb0e770 "ACPI / scan: Simplify acpi_match_device()" Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-13ACPI / scan: Rework modalias creation when "compatible" is presentRafael J. Wysocki1-94/+155
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10ACPI / scan: Take the PRP0001 position in the list of IDs into accountRafael J. Wysocki1-50/+65
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10ACPI / scan: Simplify acpi_match_device()Rafael J. Wysocki1-19/+11
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-10ACPI / scan: Generalize of_compatible matchingRafael J. Wysocki1-6/+14
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-03-18ACPI / scan: fix fixed event handler return valueAaron Lu1-2/+2
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: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI: add AMD ACPI2Platform device support for x86 systemKen Xue1-0/+1
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: Ken Xue <Ken.Xue@amd.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-05ACPI / PM: Fix PM initialization for devices that are not presentRafael J. Wysocki1-5/+8
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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
2014-12-18Merge branches 'acpi-scan', 'acpi-utils' and 'acpi-pm'Rafael J. Wysocki1-2/+2
* acpi-scan: ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUG * acpi-utils: ACPI / utils: Drop error messages from acpi_evaluate_reference() * acpi-pm: ACPI / PM: Do not disable wakeup GPEs that have not been enabled
2014-12-12ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUGRafael J. Wysocki1-2/+2
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: 40e7fcb19293 (ACPI: Add _DEP support to fix battery issue on Asus T100TA) Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-12-08Merge branches 'acpi-scan', 'acpi-pm', 'acpi-lpss' and 'acpi-processor'Rafael J. Wysocki1-0/+85
* acpi-scan: ACPI: Add _DEP support to fix battery issue on Asus T100TA * acpi-pm: ACPI / sleep: Drain outstanding events after disabling multiple GPEs ACPI / PM: Fixed a typo in a comment * acpi-lpss: dmaengine: dw: enable runtime PM ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA ACPI / LPSS: allow to use specific PM domain during ->probe() ACPI / LPSS: add all LPSS devices to the specific power domain * acpi-processor: ACPI / cpuidle: avoid assigning signed errno to acpi_status ACPI / processor: remove unused variabled from acpi_processor_power structure ACPI / processor: Update the comments in processor.h
2014-11-24ACPI: Add _DEP support to fix battery issue on Asus T100TALan Tianyu1-0/+85
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=69011 Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org> Tested-by: Adam Williamson <adamw@happyassassin.net> Tested-by: Michael Shigorin <shigorin@gmail.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04Driver core: Unified interface for firmware node propertiesRafael J. Wysocki1-0/+21
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: Grant Likely <grant.likely@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>